架构不是画给别人看的图，是决定你明年还改不改得动。
这个系列解决什么问题
一个人做产品，架构的约束不是「如何让十个工程师并行开发」，而是「只有你一个人，且你每周只有四十小时」。这两件事推出来的答案几乎相反：团队要拆分、要解耦、要平台化；一个人要合并、要直白、要少一层。
这个系列把一个人能扛住的架构写下来：先用八个判据做排除法选型，再解释为什么第一版应该是单体、九个模块的依赖方向怎么定；然后把数据迁移做成一次只动一件事，把四十一个直接依赖压进四个升级窗口；接着给技术债记利息、给抽象定时机，用三张判据表回答「重构还是重写」；再给七个外部服务各加一层适配，把后台任务的幂等与补偿写死；最后用十二项检查、四维评分与一次演进复盘收口。
它服务的是一个人。 你没有架构评审会、没有 SRE、没有第二位代码评审人；你能投入的是每周三小时的架构预算，和一条能自己跑起来的边界检查。
核心主张：五条口径
- 选型是排除题，不是评分题。 先把硬约束不满足的候选划掉，再比较剩下的两个；打分只用来摊开理由。
- 单体优先，边界靠方向不靠拆分。 一个人拆服务，拆出去的是部署与排查成本，不是复杂度。
- 迁移一次只动一件事。 结构、数据与约束分三次走，任何一次都能单独回滚。
- 债务要记利息，不记情绪。 「这段代码很丑」不是债务，「每次改它多花二十四分钟」才是。
- 可替换性只给会换的东西付钱。 不会换的供应商直接调用，套一层适配只是多一层要维护的代码。
10 篇速览
| # | 文章 | 核心内容 | 阶段 |
|---|---|---|---|
| 01 | 技术选型是排除题：八个判据、三个候选与一次返工账 | 八个判据、二十四格打分、八小时换一百零八小时 | 选型 |
| 02 | 单体优先：九个模块、一条依赖方向与一次边界检查 | 九个模块、四层方向、一百二十行检查脚本 | 结构 |
| 03 | 数据模型与迁移：三十四张表与一次只能动一处的改动 | 三步迁移、十八个破坏性改动、回滚脚本 | 数据 |
| 04 | 依赖管理：四十一个直接依赖与四个升级窗口 | 三百五十九个包、PR 分级、积压两年的一次升级 | 依赖 |
| 05 | 技术债预算：十八条债、二十四分钟与 7.5% 的工程时间 | 债务登记六字段、利息复算、按比值还债 | 债务 |
| 06 | 抽象与复用：第三次重复才抽，一次抽错的代价 | 三次规则、三十五行的账、第一年负收益 | 抽象 |
| 07 | 重构还是重写：三张判据表与 160 小时对 48 小时 | 三个判据、渐进重构、重写的三个前提 | 演进 |
| 08 | 可替换性：七个外部服务与一层适配 | 四百二十行适配层、十二小时对四十小时 | 退出 |
| 09 | 后台任务与一致性：六个定时任务、幂等键与一次补偿 | 一百八十次执行、零点四个百分点、日终对账 | 异步 |
| 10 | 架构验收：十二项检查、四维评分与一次演进复盘 | 十二项检查、四维加权、3.75 与季度排序 | 验收 |
三条阅读路径
路径 A：还没写多少代码。 从 01 的八个判据开始，把三个候选按硬约束先划掉一个；再用 02 定下单体与依赖方向，用 03 把第一次迁移的规矩立好。这条路径的重点是「别在第一周就把明年的路堵死」。
路径 B：写到一半，改不动了。 先用 05 给技术债记利息，判断该不该停功能；再用 06 检查有没有抽早的抽象，用 07 的三张表判断是重构还是重写。这条路径的重点是「先算账，再动刀」。
路径 C：上线一年多，依赖和债务堆着。 先用 04 把依赖压进四个窗口，再用 08 给会换的外部服务补适配层，用 09 把定时任务的幂等与补偿写死，最后用 10 做一次季度验收。这条路径的重点是「让系统能再撑一年」。
与其它专题的边界
站内已有系统架构、运维与交付内容，但都在团队或基础设施语境。下表说明本组不重复什么。
| 既有内容 | 它讲什么 | 本组边界 |
|---|---|---|
| 系统架构设计专题 | 单体与微服务、DDD、C4、ADR、技术债治理、适应度函数 | 它面向团队与系统规模；本组只回答一个人、四十小时、六万行时该怎么选 |
| 独立开发者生存指南（四）：工程与技术策略 | 为什么「技术先进」是失败信号、选型三原则、最小工程模板 | 它讲为什么要克制；本组讲克制到什么程度、什么时候该不克制 |
| 独立游戏开发的工程策略：一个人如何控制复杂度 | 游戏项目的模块划分、状态管理与内容管线 | 它针对游戏运行时与内容生产；本组针对 Web 产品的数据与发布 |
| 共享底座：账号、计费、邮件与部署的复用边界 | 多产品之间哪六层能共享、哪三层不能 | 它解决「多个产品共用一套」；本组解决「单个产品内部怎么分」 |
| 维护负债账本：依赖、证书与平台政策的季度巡检 | 组合视角的维护清单与季度巡检节奏 | 它按产品盘点；本组按依赖包与升级窗口排队 |
| 第三方依赖运维：供应商挂了，你怎么办 | 九个依赖的 SLA 读数、三层降级与演练 | 它管运行时故障；本组管代码层的适配边界与迁移成本 |
| 发布后的 24 小时：观察窗口、回滚判据与冻结期 | 四个观察窗口、五条阈值与回滚时机 | 它决定发布后怎么盯；本组决定代码写成什么样才敢发 |
| 跨平台构建矩阵：三系统两架构的 CI 成本 | 构建矩阵、CI 分钟数与发布前置时间 | 它算构建成本；本组算依赖升级与锁文件策略 |
| 组织、工作区、成员：三层模型与一次数据迁移 | 一次具体的数据模型改造与不停机迁移 | 它给案例；本组给迁移的三步纪律与回滚清单 |
| API 规范：OpenAPI 契约、统一错误模型与分页约定 | 对外接口的契约、错误码与分页 | 它管对外承诺；本组管内部模块之间的调用方向 |
| 数据与备份：3-2-1、加密、离线副本与恢复演练 | 备份策略与恢复演练 | 它保证数据不丢；本组保证结构变更可回退 |
| 开发外包与代码交接：接得住、改得动、走得掉 | 外包代码的验收、文档与交接 | 它解决别人写的代码怎么接；本组解决自己写的代码怎么演进 |
| 一个人的计费系统：订阅状态机、按比例计费与失败重试（10 篇） | 订阅状态机、五个时点、按比例计费、按量计量、催收、退款拒付、发票税务、对账漏损、自建决策、十二项验收 | 那组讲计费模块的状态机；本组讲技术选型、模块边界与演进 |
| 一个人的隐私工程：数据地图、最小化与删除权（10 篇） | 数据地图、最小化、合法性依据与同意、政策一致性、数据主体请求、删除、保留期、跨境与供应商、泄露响应、十二项验收 | 那组讲表结构里哪些字段是个人信息；本组讲技术选型、模块边界与演进 |
| 一个人的数据搬家：导入、去重、迁移与退出（10 篇） | 迁移漏斗、导入契约、字段映射、去重合并、幂等重跑、人工代导入、窗口与回滚、附件限额、导出退出、十项验收 | 那组讲外部数据与内部表结构；本组讲技术选型、模块边界与演进 |
| 一个人的质量守门：验证预算、回归清单与发布门禁（10 篇） | 47 缺陷与三条红线、12 条关键路径、三层配比、38→26 回归、六项门禁、四级缺陷、测试数据、不可逆保护、测试债、十项验收 | 那组讲行为正确性的证据；本组讲技术选型、模块边界与演进 |
| 一个人的安全基线：十四个入口、十七个密钥与一次 72 小时响应 | 14 个攻击面、认证与枚举、会话撤销、17 个密钥三档、四条边界、41 个依赖与 186 条告警、四类限流、9 类审计日志、72 小时三段响应、20 项验收 | 那组讲依赖里的已知漏洞；本组讲技术选型、模块边界与演进 |
| 一个人的性能与账单：4.2 秒的首屏、一千二百次查询与每月 210 美元 | 4 项预算与 20 格、RUM 与慢查询、412→168 KB、1,200→3 次查询、0→86% 缓存、34 秒导出、7→4 个第三方、210→118 美元、3 次回归告警、10 项验收 | 那组管选型之后的预算与实测；本组管技术选型、模块边界与演进 |
| 一个人的企业客户：九家询价、一百四十八道问卷与 134 天的第一单 | 9 家询价与 130 h、96 天采购、148 题问卷、7 个子处理者、SLA 43.2/216 分钟、26 h SSO、4 周试点、38 天到账、8 h 实施、10 项验收 | 那组讲企业能力该自建还是外购；本组讲技术选型、模块边界与演进 |
| 一个人的开源产品：4,200 个 star、一百八十个付费与一年 612 小时的维护 | 4,200 star 与 1,949 美元、612 h 维护、214 依赖、48,600 行 78/22、1,180 个 issue、214 条告警、23 个赞助者、9 家双许可、17 位贡献者、10 项验收 | 那组讲 Open Core 的代码分层；本组讲技术选型、模块边界与演进 |
这十篇不承诺「按这套做就不会腐化」，也不提供任何框架、云服务或工具的选型推荐。可复算的部分全部用四则运算给出算式；不可复算的部分（框架优劣、社区活跃度、许可风险）明确指向对应专题与官方文档。所有数字都是教学假设，代入前请换成自己的代码量与改动频率。
本组统一口径
全组共用一组教学假设，各篇引用时不换分母：
产品：一人 SaaS，与既有组同一产品（120 付费 / 344 账号），团队 1 人
代码库：14 个月、62,400 行 = 业务 54,400 + 生成 8,000
模块 9 个：最大 12,800 行、最小 1,600 行、平均 6,044 行
直接依赖 41 个；传递依赖 318 个；合计 359 个包
数据库 34 张表；迁移文件 62 个（其中破坏性 18 个）
提交：累计 1,240 次；近 90 天 186 次 = 每周 14.3 次
发布：每周 2 次 = 每月 8 次；近 90 天 24 次
近 90 天功能改动 38 次：跨模块 22 次（57.9%）、单模块 16 次
改动耗时：跨模块 6 小时、单模块 1.5 小时 → 合计 156 小时/季度
技术债 18 条 = 高 4 + 中 9 + 低 5；利息 24 分钟/次改动
工程时间 40 小时/周 × 52 = 2,080 小时/年
架构预算 3 小时/周 = 156 小时/年 = 7.5%
外部服务 7 个：支付、邮件、对象存储、模型、分析、搜索、鉴权
定时任务 6 个 × 每天 1 次 = 180 次/月；失败率 0.4% = 0.72 次/月
代码量按行算，不按文件数算。 62,400 行是 git ls-files 里业务代码的去空行统计，含生成的 8,000 行；用文件数或提交数比较会失真。
改动次数是近九十天的，不是历史平均。 14 个月累计 1,240 次提交里，前半段是搭架子，后半段才是真正的改动；拿累计值算利息会高估。
工程时间只有四十小时。 2,080 小时是上限，不是产能；营销、支持、财务都从这里扣，所以架构预算只给 3 小时/周。
所有成本都是教学假设。 六小时、十八小时、四十小时这些数字只用来展示数量级关系；真实估算请用自己最近三次同类改动的记录。
使用说明
先读 01，不要先看框架榜单。 你的分发形态、团队规模与退出成本决定了候选范围，别人的技术栈榜单不含这三项。
每篇都可以单独使用。 文章之间共享基线，但不依赖前后文；你可以只拿 03 的迁移三步或 05 的债务登记表回去用。
先做零成本的动作。 依赖方向、命名规则、迁移三步、债务登记、幂等键，这些都不花钱，只花一次决定。
架构预算要写进日历。 每周三小时不写进日历，就会被功能需求吃掉；连续四周被吃掉，利息就开始复利。
本组的证据与使用方法
证据类型。 本组用的是「代码库统计 + 改动记录 + 迁移台账 + 依赖清单 + 债务登记」：模块行数与依赖方向、近九十天的跨模块改动次数、六十二个迁移文件的回滚情况、三百五十九个包的升级窗口、十八条债的利息与修复估价。没有「最佳实践」式的断言。
如何使用。 先把 01 的八个判据对照自己的候选，再用 02 的依赖方向画一张自己的模块图，用 05 的公式把债务利息算出来，最后用 10 的十二项检查做季度体检。
如何复核。 取最近一个季度，任选一次跨模块改动，记录实际耗时，与 1.5 小时和 6 小时两个基线比；再取最近十个迁移，数一下有几个写了回滚。两项都对得上，基线才适用。