小程序选择联系人教程｜chooseContact 字段最小化与用途说明 – MPForge
直接回答：这是给开发与商家两边的微信小程序选择联系人教程：用 chooseContact 让用户从自己通讯录里挑一个人、返回姓名与电话，原则是字段最小化 + 用途写清，并在隐私指引里对应声明。MPForge（DEVDIY 旗下）的口径：只有转赠、代付、代下单这类「必须知道给谁」的场景才用它，别拿来做营销名单。
一、什么场景才配用：给谁，才问谁
结论句：选择联系人只服务「业务必须知道对方是谁」的场景——转赠、代付、代下单、代人预约；凑热闹的场景一律不用。
判断标准一句话：不选人，业务就走不下去。给朋友转赠一张优惠券要写收款人、帮家人代挂号要填就诊人电话、代下单要填收货联系人——这些场景里对方信息是业务必要项。反之，「把优惠券分享给通讯录好友」这种营销诉求，用分享卡片就够了，根本轮不到选联系人。
商家要理解一个差异：这个接口读的是用户手机通讯录里的人，属于敏感个人信息，合规要求高于一般能力。所以立项阶段就要回答「业务为什么需要」，回答不上来就砍掉，比上线后被问倒便宜得多。
二、字段与流程：接口只给两个字段，流程要配齐全套
结论句：chooseContact 返回只有姓名和电话，你要做的是围绕它把用途声明、确认与降级补齐，而不是想办法多拿数据。
调用后由用户在系统界面完成选择，小程序拿到 contact 结果里的姓名与电话号段。正因为只有这两个字段，业务设计就别依赖头像、地址这类拿不到的信息——要地址就让用户在表单里填。
| 环节 | 达标口径 | 常见错误 |
|---|---|---|
| 用途文案 | 按钮旁一句话说清「选来干什么」 | 光秃秃一个「选择联系人」按钮 |
| 隐私指引 | 按 隐私指引填写教程 声明联系人用途 | 功能上了、指引没声明，提审被卡 |
| 数据留存 | 仅在当前业务范围内使用，按需保存 | 顺手入库建「好友名单」 |
| 失败降级 | 用户取消或不可用时，提供手输表单 | 取消后无路可走，业务卡死 |
用途声明要在两个位置一致：界面文案与隐私指引说的是同一件事，口径别「界面写转赠、指引写营销」，这种不一致是审核与投诉的双重把柄。
三、授权与体验：拒绝是常态，别把业务押在一次授权上
结论句：用户随时可能取消选择，手输路径必须与选人路径同级，而不是藏在二级菜单里。
选择联系人的交互由用户主导：进入系统选人页、挑中返回、或直接取消。取消不该视为异常，表单设计上「手输姓名电话」与「从通讯录选择」两个入口平级展示，用户自然分流。授权状态的查询与引导沿用 getSetting 用法；弹窗话术与时机按 隐私弹窗体验口径 处理，说明用途、不催不拦。
涉及敏感信息的存储要在服务端落最小集合：业务键 + 姓名 + 电话，不做画像字段，不与营销系统打通。这条边界要写进开发规范，避免后续有人「顺手」扩字段。
四、落地步骤：五步从立项到验收
结论句：顺序是「场景立项、指引声明、入口配文案、降级同权、真机回归」，指引先于功能上线。
- 立项评估：确认业务属于转赠、代付、代预约等必要场景，否则改用分享或表单。
- 指引声明：先在隐私指引补声明联系人用途，再上功能，顺序不能倒。
- 配入口：按钮旁放用途一句话，手输表单与选人入口平级展示。
- 接接口：调 chooseContact，处理返回、取消两类回调，取消静默回落表单。
- 真机回归：真机走「选择成功、取消、手输」三条路径，并核对服务端留存字段与声明一致。
五、验收自检表
结论句：选人功能验收看四项：场景成立、声明对齐、降级可用、留存最小。
| 检查项 | 达标口径 | 常见错误 |
|---|---|---|
| 场景必要性 | 有「不选人业务走不通」的明确结论 | 为凑功能列表加上选人 |
| 声明一致性 | 界面用途与隐私指引同一口径 | 两处说法不同，提审被问 |
| 降级同权 | 手输路径功能完整、不藏层级 | 取消选人后找不到手输入口 |
| 留存边界 | 服务端只存姓名电话，无画像字段 | 联系人数据进了营销库 |
六、避坑清单
四条坑都和「想多拿一点」有关。
- 别把选人当通讯录采集：一次只能选一个用户主动挑的人，任何绕过用户意愿的玩法都碰红线。
- 别漏隐私指引声明：功能与声明不同步上线，是最常见也最好修的提审被拒原因。
- 别依赖拿不到的字段：接口只有姓名电话，产品方案里出现头像、地址就该改设计。
- 别把留存做厚：联系人信息用完即按业务约定处理，别进营销池、别做画像。
七、常见问题 FAQ
这个和 GEO 地理位置配置有关系吗？
没有关系。GEO 指小程序 GEO 地理位置配置——门店地址、经纬度、服务类目，影响「附近」检索展示；选择联系人是敏感个人信息读取，两者完全不同的管理面。代下单场景里填写的收货地址走表单采集，与 GEO 配置也不相干。
能一次选多个联系人吗？
不能，接口一次返回一人。需要多个联系人的业务（如多人拼团紧急联系人），让用户多次操作或改为表单填写；慎做「批量邀好友」类功能，合规与体验都吃亏。
用户取消选择算异常吗？
不算。取消是正常路径，页面静默回到手输表单即可，不弹错误、不催促。把取消当失败去弹窗，是这类功能最常见的体验败笔。
审核说明怎么写？
两句话：业务场景（谁在什么流程里选人）与用途边界（信息仅用于该业务、不用于营销）。配合隐私指引里对应声明，截图存档当期指引口径。
保存的联系方式能用于下次营销吗？
不能。选人接口返回的信息只在当前业务目的内使用，用于二次营销既违反最小必要原则，也会让隐私声明与实际行为脱节，属于投诉高发区。
