技术架构需求Draft

典型场景：数据库搭建、分库分表、服务拆分、系统迁移、性能治理

标准文档技术方案文档

主导角色技术负责人

回答的核心问题现状瓶颈是什么、目标架构怎么定、风险怎么兜底

文档定位受控迁移——回答「如何把系统从现状安全地改到目标态」；六类中唯一以取舍为评审单位、生命周期跟随系统而非项目的文档

核心读者工程师（默认已懂业务上下文，不复述为什么做需求）

评审第一眼落点一页纸技术摘要（30 秒决定质询哪个决策）→ 选型矩阵 → 回滚时间线（决定能不能上线）

一页纸技术摘要

六行，让评审者 30 秒内决定质询哪个决策。别类文档没有这个构件——技术评审的时间成本最高，摘要是刚需。

问题进度矩阵存 localStorage，多人协作数据不同步、刷新即丢、无历史可比

量化目标支持 50 人并发编辑不丢数据；任意两日进度可对比；接口 P99 < 300ms

选定方案迁云数据库（Postgres），RLS 行级权限 + 每日快照表

否决方案方案 B 继续 localStorage + 导出导入：并发写必丢数据，否决；方案 C 自建实时同步：成本 3 倍且无收益，否决

最大风险双写窗口期新旧数据不一致 → 一致性校验门禁 + 可回切单写

回滚策略双写 2 周，校验通过前保留回切开关；切写后 7 天内可回退

评审主战场。被否决的方案及理由是正文而非附录；「没得选」要写明约束来源。每个决策必须标注可逆性——不可逆决策（分片键、存储引擎）要求更高评审层级。

维度	方案 A：迁云数据库（选定）	方案 B：localStorage + 导入导出	方案 C：自建实时同步
多人协作	RLS + 服务端权威数据	并发写必丢数据	支持但成本高
历史对比	快照表天然支持	需手动导出留档	支持
工作量	中（2 人周 + 迁移）	低	高（3 倍）
可逆性	可回切单写	不可逆（数据已散失）	可逆
结论	选定	否决：核心场景不成立	否决：成本无对应收益