2.2 KiB
2.2 KiB
团队共享 经验记录 - 2026-03-12
密钥/token 设计：关联小程序与 @ 人物
背景
- 关联小程序：添加时生成 32 位英文+数字密钥，链接标签存 key，小程序点击 # 时用 key 查 appId 再跳转
- @ 人物：添加时生成 32 位 token，文章 @ 时存 token，小程序点击 @ 时用 token 兑换真实 ckb_api_key 后加好友
设计原则
- 不暴露真实密钥：管理端配置的真实密钥（appId、ckb_api_key）不写入文章内容，仅存可对外传递的 token/key
- 服务端兑换：小程序端只传 token/key，后端用其查表得到真实密钥再调用第三方
- 不兼容旧数据：项目未上架，无需兼容 person_id、appId 等旧格式
数据流
| 场景 | 添加时 | 内容存储 | 小程序点击 | 后端兑换 |
|---|---|---|---|---|
| 关联小程序 | 生成 key | data-mp-key | 传 mpKey | 查 linked_miniprograms 得 appId |
| @ 人物 | 生成 token | data-id | 传 targetUserId | 查 persons 得 ckb_api_key |
适用角色
- 后端：persons.token、linked_miniprograms.key、CKBLead 兑换逻辑
- 管理端：链接标签选 key、@ 人物 id=token、列表展示
- 小程序：contentParser 解析 mpKey、onLinkTagTap/onMentionTap 传 key/token
9.9 买断与团队级约定
结论
- 「9.9 买断全书」在三端的唯一来源是后端的
hasFullBook/has_full_book信号：- 小程序：只看
/user/purchase-status的hasFullBook和/user/check-purchased的reason = "has_full_book"。 - 后端：可以通过订单或用户资料开关（如
manual_fullbook）计算该状态。 - 管理端：如需赠送 9.9 买断，应只改后端用户资料中的开关，不直接改前端逻辑。
- 小程序：只看
约定
- 任意「免 9.9」或「赠送全书」能力都必须：
- 由后端在 purchase-status/check-purchased 中折叠为统一的
hasFullBook/has_full_book。 - 不允许在小程序或管理端各自新增本地开关绕过后端逻辑。
- 由后端在 purchase-status/check-purchased 中折叠为统一的
- VIP 与 9.9 买断继续分离：
hasFullBook→ 只代表书的权限；isVip→ 代表会员权益（案例库、增值版等），两者可以独立打开。