一次邀请，对发送者只是一个按钮，对接收者却是一次注意力消耗。如果增长系统只优化“谁更容易被邀请”，请求就可能不断集中到最活跃、最受欢迎的人身上。
可持续的社交增长，需要同时回答三个问题：此刻适合邀请谁，用户授权了什么，对方是否还有意愿和精力接收。
一、互动排序：把合适的人放到前面
分享前的好友排序，帮助用户从已有关系中选择互动对象。它既要考虑关系，也要考虑当前任务：适合一起玩游戏的人，未必适合接收工作资料。
左图展示聊天选择入口，右图把邀请放进游戏活动。重点是不同任务需要不同的候选顺序。产品可在自己可控的界面中结合近期互动、共同参与记录等信号排序；截图不能证明具体算法，也不能推断第三方应用可以修改微信内置联系人列表。
两图的快捷分享对象及顺序有所不同，说明用户看到的是一个经过选择的入口。重点应放在“前排对象是否适合当前内容”。在线状态可以作为实时互动场景的候选信号，但仅凭截图不能认定它决定排序；在线也不等于愿意被打扰。
实施时，先过滤已屏蔽、明确拒绝和不适合接收该类邀请的对象，再按场景相关性排序，并保留搜索与手动选择。不要默认勾选多人，把推荐悄悄变成群发。
评估也要从“选中了谁”继续看到“对方是否接受、是否完成有效互动”。只提高发送率，可能只是把选择成本转嫁给接收者。
二、通讯录授权：读取、匹配、发送分开设计
通讯录能帮助用户找回熟人，却也包含未使用产品的第三方信息。用户允许读取联系人，不代表平台可以自动向所有号码发送短信。
图中的弹窗说明寻找通讯录好友的用途，并强调授权后的活动收益。重点是收益之外，还应让用户看清读取范围、用途、是否上传和如何撤回。产品内说明不能代替系统权限，也不能以奖励暗示用户必须交出完整通讯录。
合理流程是：说明用途 → 用户选择访问范围 → 匹配候选 → 确认对象、内容与渠道 → 发送邀请。匹配结果可以区分站内账号与未匹配联系人，但“未匹配”不能直接等同于可以营销的新用户。
图中展示通讯录好友候选、添加入口和其他邀请方式。重点是匹配之后仍有选择环节。产品应允许逐个调整对象，并为拒绝通讯录权限的人保留手动邀请路径；截图不能证明实际读取范围或短信发送逻辑。
在支持的系统上，可以使用有限联系人访问或联系人选择器。Apple的官方文档介绍了iOS 18的有限访问机制，用户可以选择允许应用访问哪些联系人；具体实现仍需适配系统版本。
图中要求填写个人介绍，让接收者认出邀请人，并提示信息会保留在个人资料中。重点是帮助对方识别身份，同时交代信息去向。若介绍会长期展示，就应提供修改入口；不要把一次申请中的备注默认扩散成公开资料。
数据管理应落实到具体对象：原始联系人、匹配结果和同步关系分别为何保留、保留多久、如何删除。依据《个人信息保护法》的最小必要和最短必要保存期限原则设计，不能把“所有场景发送后立即删除”写成统一法条。撤回授权后，应停止后续同步，并按适用要求处理已保存数据；只关闭手机权限，不会自动清除服务器副本。
三、接收方体验：把控频和拒收放进主流程
图中一侧轻松操作，另一侧被大量消息包围。重点是单次发送的便利，可能累积成另一端的负担。它适合提醒团队同时评估两端体验，但属于示意画面，不能当作用户研究或增长效果证据。
接收控制应覆盖三个层次：
| 层次 | 可执行的设计 |
|---|---|
| 总量 | 按接收者汇总不同活动、发送者和渠道的邀请，设置滚动窗口上限与重复邀请冷却期 |
| 时机 | 尊重用户时区和免打扰设置；对非即时邀请延迟投递或合并提醒 |
| 意愿 | 提供单次忽略、屏蔽某类活动、屏蔽某人和统一消息设置，清楚说明各自作用 |
只限制“每位发送者一天发几次”不够：同一个人仍可能收到几十位好友的请求。产品应在可控渠道内做统一去重和控频；跨平台无法完整观测时，要说明覆盖范围，不能声称已控制全部打扰。
拒收应成为硬约束。用户屏蔽某类邀请后，不应换成短信或其他账号继续触达。未回复则应与明确拒绝区分：它可能意味着没看见或暂时没空，可以减少重复推荐，不能擅自认定用户永远不感兴趣。
四、LinkedIn案例：把接收负担纳入推荐排序
图中邀请列表显示多条待处理请求及接受、忽略入口。重点是请求会积压。产品应观察接收负担的分布，而不只看平均邀请量；页面数量也不等于用户实际阅读或处理的次数。
图中呈现联系人容量提示，字幕将其与公众人物求助联系起来。它提示关系管理存在容量问题，可作为讨论入口；截图无法证实事件因果或当前平台上限，也不能把好友总量与短期邀请过载混为一谈。
LinkedIn在2021年的工程文章中介绍：对已收到过多邀请的候选人，在基础连接分数上乘以衰减因子，再重新排序：
图中A原本排第一，右上角15表示已收到的邀请数量。重点是它与卡片下方的共同联系人数不同。排序需要同时看相关性与接收负担；收到邀请多，不意味着这个人不值得推荐。
图中A被降到B、C、D之后，展示了负担衰减如何调整曝光。原文用“过去一周超过10次邀请”举例，并介绍当时使用分段线性函数；该阈值不是公开的统一限制，也不能直接照搬到其他产品。
原文报告过载接收者数量下降50%。这是特定系统中的实验结果，不能作为采用同一公式后的效果承诺。
实际应用可先定义接收窗口和负担指标，再验证重排序。明确拒收仍应直接过滤，不宜只乘一个较小系数继续推荐；必要的总量限制也不能由降权代替。
最终同时检查：发送者是否找到了合适对象，接收者是否愿意接受并继续互动，以及高负担人群的忽略、屏蔽和投诉是否改善。同一接收者可能收到不同实验组的邀请，评估时还需考虑组间影响，避免只凭发送端数据下结论。