从零做微信小程序(10)：付费解锁联系方式，隐私与变现的平衡

执迷者X，持续分享值得阅读的内容。关注

联系方式是货源广场里最敏感、也最容易被误用的数据。直接写在正文里，隐私和付费点一起失守；全部藏起来，又无法继续撮合。这篇用云端存储、权限矩阵和单帖单联系人解锁，把两者放在同一条规则里。

手机号、微信号和 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 篇。

如果你的产品既要保护联系人隐私又要形成合理变现，可通过联系页说明当前权限设计。

添加评论

点踩

参与讨论