刘总需求（09-14 00:2x 澄清）：「一套放到每个旅游目的地都能拉起来就用的小程序，且客户信息互通互相引流」——目的地连锁模式。
输入：gpt6 深度研究（7352 字符，high effort）——微信身份硬约束/数据分层/引流机制/迁移路径/部署形态/福钥分销跨目的地/路线图。全文：docs/reports/gpt6-评审-2026-09-13/05-目的地连锁架构研究.md
硬约束：openid 按小程序 appid 隔离（不同小程序的同一微信用户 openid 不同）——不能直接用 openid 认人。
正解：独立连锁账户中心：
微信身份
├─ appid_A + openid_A ─┐
├─ appid_B + openid_B ─┼─> identity_binding ─> global_user_id
└─ unionid（可用时强关联辅助）
global_user_id ─> 统一客户资料/足迹/偏好/会员/引流关系
目的地 token ─> 当前目的地业务权限和会话账户中心职责：openid/unionid/手机号绑定去重、global_user_id 签发、账户合并/解绑/人工处理、目的地 token 签发（限定 audience+scope+有效期）、token 交换/撤销/审计/风控。
跨目的地跳转：当前小程序登录→账户中心识别或绑定→签发目的地访问凭证。unionid 不可用时用手机号授权/用户主动确认/订单关系补充绑定。
| 层 | 数据 | 库 |
|---|---|---|
| 共享域（账户中心） | global_user_id/openid 绑定/unionid/手机号/客户资料/足迹/偏好/会员等级/引流关系 | 集中（一套） |
| 目的地隔离域 | 订单/商品/商户/核销/福钥发放/内容/评价 | 各目的地独立 DB（或单库 destination_id 分区——初期单库分区务实） |
原则：用户身份跨目的地唯一；业务数据按目的地隔离；引流数据单独链路（referral_id 全程可追踪）。
| 实例 | 新角色 |
|---|---|
| kailash | 第一个接入连锁账户中心的目的地（架构新、规模小、已生产上线——先行验证） |
| YOS | 第二个目的地+AI 能力输出方（brain 域 158 模块的 AI 分析/推荐/评分能力是连锁中枢的候选引擎——但按能力逐个迁移，不一次性并入） |
| 账户中心 | 新建独立服务（或先寄生在 kailash 后端，P1 独立部署） |
独立业务实例+集中公共服务：
| 阶段 | 内容 |
|---|---|
| P0 架构冻结与核验 | ①核验两 appid 是否绑同一微信开放平台（unionid 可得性）②盘点两套用户表规模 ③定义 global_user_id/目的地 ID/绑定合并规则 ④共享数据目录+隐私授权+保留范围 ⑤福钥通用范围+分销跨地清分规则 |
| P1 统一身份旁路上线 | 账户中心（绑定/token 交换/审计）+两实例加全局映射+新用户走统一登录+老用户渐进绑定+回滚开关保留 |
| P2 客户事件与单场景引流闭环 | 事件规范+事件总线+最小事件（到访/完成订单/浏览/点击/下单/核销）+一个推荐场景闭环（长岛→冈仁波齐）+referral_id 全程追踪+规则推荐先跑 |
| P3 跨目的地内容/会员/福钥试点 | 授权的攻略/评价/足迹摘要跨地展示+会员互通试点+福钥跨地规则试点 |
| P4 白标化初始化流水线 | 租户脚本（校验→生成→验证→交付）——第 4 个目的地起「10 分钟拉起」 |