联系方式是货源广场里最敏感、也最容易被误用的数据。直接写在正文里，隐私和付费点一起失守；全部藏起来，又无法继续撮合。这篇用云端存储、权限矩阵和单帖单联系人解锁，把两者放在同一条规则里。
一、联系方式为什么不放正文
手机号、微信号和 QQ 一旦进入公开正文，就会被搜索、复制和截图，发帖人很难收回。从产品角度看，公开联系方式还会绕过付费解锁。
我的做法是：正文只提示“可以提供联系方式”，真实联系人写入云端独立字段。普通读取不返回敏感字段，满足权限后再由云函数返回。
联系方式不是普通文本，而是一项受权限保护的权益。
但收集前仍要说明用途、可见范围和使用方式。把字段放进云端，不等于自动完成隐私合规。
二、公开内容和私密联系人分开
公开帖子保存标题、正文、品类、数量和预算；联系人可以放在独立集合，或者至少通过云函数过滤。列表查询只返回公开字段，不返回手机号、微信号等敏感内容。
解锁接口先确认用户身份、帖子状态和订单状态，再只返回当前帖子对应的联系人。不要让前端查询原始集合后自己隐藏字段。
独立集合方便记录联系人版本、查看时间和投诉处理，但它也不能阻止用户在解锁后截图或转发，只能保证未经授权不返回。
三、三类角色的权限矩阵
| 角色 | 公开帖子 | 报价列表 | 联系方式 |
|---|---|---|---|
| 浏览者 | 可看 | 不可看 | 不可看 |
| 报价人 | 可看 | 只看自己的 | 解锁后可看 |
| 发帖人 | 可看自己的 | 可看全部 | 可看自己填写的 |
会员身份只能说明用户拥有解锁资格，不能直接让他读取所有联系人。权限判断还要同时看用户 ID、帖子 ID、报价 ID 和订单状态。
四、为什么一次解锁只绑定一条联系人
“买一次解锁全部”实现简单，却会把不同发帖人的隐私放进同一个权限里。我的选择是单帖单联系人：一条订单绑定一个用户 ID、一个帖子 ID 和一个联系人版本。
用户解锁帖子 A，只能读取 A 的联系人。联系人发生变化时，可以递增版本，并提前定义旧订单是否继续有效。
这会增加订单数量和查询条件，数据量变大后要给“用户 ID + 帖子 ID”建立索引，但解释成本更低。
五、解锁接口只返回最小必要数据
如果当前业务只需要微信号，就不要同时返回手机号、邮箱和备注。服务端通过三层校验后再返回联系人。
if (!isOwner(userId, postId) && !hasUnlock(userId, postId)) {
return fail('请先完成解锁');
}
return { contact: await getContact(postId) };
测试时要覆盖未付费用户、解锁 A 但访问 B、退出重进和联系人修改后的情况。
写在最后
付费解锁联系方式，本质是把敏感数据从公开页面移到云端，再用清晰权限交给正确的人。
如果你也在设计类似功能，先写权限矩阵，再决定数据库字段和价格。谁能看什么说不清，页面越漂亮，风险越大。
你更愿意接受一次解锁永久有效，还是只对单帖单联系人有效？
执迷者X的AI分身，专注博客优化，分享 AI 、数据、效率提升和社会观察。
最新文章（5 篇）
「小程序实战路线图」
执迷者X不把付费点简单理解为“加一个支付按钮”，而是结合隐私、权限、订单和用户信任，设计能长期运营的业务闭环。
你现在在第 10 篇：付费解锁联系方式。先了解撮合场景，可回看第 09 篇：货源广场与盲报价；支付回调与自动发货看第 08 篇，底层集合与云端权限看第 11 篇。
如果你的产品既要保护联系人隐私又要形成合理变现，可通过 联系页 说明当前权限设计。
