01-架构Top5风险.md

🕐 时效标注（2026-09-13 文档治理）：近期设计件，口径以 TASKS 现行与契约 v1.3 为准。

结论：Top 5 结构性风险

1. 图片资源“双源候选链 + 开关切换”可能造成数据一致性与环境漂移

依据：

• 图片解析采用 COS → 本地 draft → placeholder 候选链。
• 通过 COS_MIGRATION_LIVE 开关控制迁移行为。
• 组件还通过 binderror 触发降级。

风险机制：

同一个图片标识在不同环境、不同开关状态或不同网络条件下，可能解析到不同实际资源。由此会产生：

1. staging 与生产展示结果不一致；
2. COS 中存在资源但内容版本与本地 draft 不一致；
3. 首次加载失败时降级到 placeholder，但后续没有明确的恢复、告警或一致性校验；
4. 业务数据若只保存逻辑路径，而不保存资源版本或校验信息，可能无法准确追溯用户实际看到的内容。

审计判断：

这不是单纯的“图片加载容错”问题，而是资源寻址、迁移状态和内容版本耦合在客户端运行时决策中。材料未说明是否存在资源迁移清单、版本校验、失败监控和最终一致性校验，因此该风险较高。

2. 订单状态机依赖定时任务，存在状态延迟、重复处理与任务失效风险

依据：

• 存在 backend/scripts/order_housekeeping.py。
• 该脚本负责订单域 T1-T5 状态机。
• 材料说明“幂等已验”。

风险机制：

即使单次处理具备幂等性，定时任务架构仍然可能出现：

1. 任务未启动、异常退出或容器重启导致状态长期不推进；
2. 多实例或重复调度时产生并发抢占；
3. 订单状态实际变化依赖下一次 cron，导致业务状态存在天然延迟；
4. T1-T5 多阶段状态迁移若缺乏统一状态转移约束，可能出现跨阶段跳转、逆向更新或部分成功；
5. 任务执行结果若没有持久化游标、失败队列或告警，单纯“幂等”无法保证最终完成。

审计判断：

“幂等已验”只能降低重复执行造成的数据破坏风险，不能覆盖调度可靠性、任务可观测性、并发协调和最终完成性。材料未涉及 cron 的部署方式、锁机制、重试策略、失败告警和任务监控，因此该风险置信度高。

3. 后端路由规模较大且采用新旧架构并存，存在领域边界和数据契约不一致风险

依据：

• 后端有 40+ 路由模块。
• miniapp_* 被描述为 C 端新架构。
• 项目同时包含 FastAPI、PostgreSQL、管理后台和小程序端。
• 后端统计显示 54 个文件、约 15,986 行代码，但材料没有给出明确的领域拆分或 API 版本治理机制。

风险机制：

“旧路由 + miniapp_* 新路由”并存，容易形成：

1. 相同业务存在两套接口和两套参数/响应模型；
2. 小程序端与管理后台对订单、用户、资源等实体的状态定义不一致；
3. 公共逻辑被复制到不同路由模块，修复或规则变更不能同步；
4. 路由数量增长后，权限、事务边界、异常码和分页规则出现不一致；
5. 新旧接口迁移缺乏明确的下线条件，长期形成架构债务。

审计判断：

材料没有证明存在明确的 bounded context、统一 DTO/schema、API 版本策略或旧接口淘汰计划。因此不能断言已经发生数据错误，但可以从“新旧路由并存 + 40+ 模块”推断出契约分裂和边界失控的结构性风险。

4. 鉴权验证证据主要集中在 admin staging，生产环境与 C 端授权闭环覆盖不足

依据：

• 鉴权流程为“微信 code2session → token”。
• admin 端点存在 401 鉴权，且在 staging 验证。
• 材料未明确说明生产环境鉴权验证、token 生命周期、权限模型和 C 端接口授权覆盖。

风险机制：

当前材料只能确认部分鉴权能力存在，不能确认完整安全闭环，包括：

1. admin 鉴权是否已在生产环境验证；
2. admin 是否只有“登录态校验”，还是进一步实施角色/资源级权限控制；
3. C 端 token 是否绑定微信身份、设备或会话，是否支持失效和撤销；
4. 40+ 路由是否全部接入统一鉴权依赖；
5. 管理接口和小程序接口是否存在路由级授权遗漏。

审计判断：

风险重点不是“没有鉴权”，而是鉴权覆盖范围和环境一致性证据不足。由于材料明确提到的是“admin staging 验证”，无法将该结论外推为生产环境和全部 C 端路由均已验证，因此置信度中高。

5. 小程序页面数量大、主包与模块规模不完全匹配，存在发布体积、维护复杂度和回归测试风险

依据：

• 小程序端约 118 页，统计中显示 120 个文件、约 16,813 行代码。
• 使用 4 个 tabBar。
• 主包大小为 1.1MB。
• 项目仍处于包含 C 端新架构、COS 迁移和管理后台建设的状态。

风险机制：

页面数量较多而主包当前仍较小，可能意味着大量页面通过分包、动态资源或其他拆分方式组织；但材料未提供分包清单、页面到分包的映射或构建约束。因此存在：

1. 后续功能增长触及微信小程序包体限制；
2. 页面之间公共组件、请求层和业务状态耦合，改动影响面难以控制；
3. 4 个 tabBar 作为主入口承载大量页面，信息架构可能出现入口堆叠；
4. 图片迁移、请求封装、鉴权和页面逻辑同时变化时，端到端回归成本上升；
5. 若缺乏页面级自动化测试，118 页规模下手工验证容易遗漏。

审计判断：

不能仅凭页面数断言当前已经超过包体限制，也不能断言信息架构一定不合理。但可以确认：在页面规模较大的前提下，若没有明确的分包策略、公共能力边界和自动化回归体系，维护与发布风险会显著上升。材料未涉及这些治理措施，因此置信度为中。