多品牌电商：复用又保留差异

多品牌项目的难点不是换颜色和 Logo，而是共用商品、购物车、结算等核心链路，同时保留内容、视觉、营销规则、渠道能力和发布节奏的差异。

分层而不是复制

品牌应用层
  ├─ 主题 token / 内容配置
  ├─ 品牌能力矩阵
  └─ 页面编排与受控插槽

共享领域层
  ├─ 商品 / 库存 / 价格
  ├─ 购物车 / 促销 / 结算 / 订单
  └─ 登录 / 用户 / 地址

渠道适配层
  ├─ Web
  └─ 微信小程序（授权、订阅消息、平台 API）

共享领域模型和 API client，品牌差异通过 design tokens、配置和明确扩展点注入。不要在核心流程到处写 if (brand === 'x')。

什么时候应该 fork

如果差异已经改变领域流程、由不同团队独立演进、必须采用不同发布节奏，强行配置化会形成条件地狱。此时可拆出独立应用，同时让共享包保持稳定 public API 和契约测试。

小程序公共能力

Web 逻辑和领域模型可以复用，但 UI、生命周期、包体、权限和平台 API 不能假设一致。授权和订阅消息适合封装为 service/composable：

• 能力检测与平台版本判断。
• 权限状态、用户触发时机和请求结果码映射。
• 用户拒绝后的解释、设置入口和不授权降级。
• 统一日志字段和品牌/平台版本关联。

发布隔离

品牌差异进入能力矩阵和构建/运行配置，契约测试保证核心链路不被破坏。高风险变更按品牌灰度，错误与性能数据也需要带品牌、渠道和 release 维度。

我关注的验收点

• PLP → PDP → 加购 → 结算 → 订单的主链路。
• 登录过期、库存变化、价格变化和促销失效。
• 品牌内容插槽没有破坏可访问性和核心交互。
• 小程序包体、setData 更新粒度与平台能力降级。
• 品牌 A 的改动不会改变品牌 B 的产物或运行配置。