春与秋其代序

90% 后端系统做大后最痛：耦合 代码好写，解耦难 目标：从硬耦合 → 松耦合 → EDA 强依赖的问题 服务间直接 RPC 调 → 牵一发动全身 A 改一点 B 必须跟着改 解耦路径

大型系统永远不是第一次设计最正确 数据结构会变，这件事要工程化面对 DB schema evolution 原则 前向兼容 后向兼容 additive only（add 不 break）

真正大型业务，瓶颈90%在DB，不在CPU 缓存不是简单加Redis，而是体系化能力 三大核心问题 缓存穿透 / 缓存击穿 / 缓存雪崩 每种问题在真实业务里会杀死系统

很多公司做中台失败不是因为技术 是因为「中台理解错误」：以为是公共库 + 公共服务复用 中台真正的定义 中台 = 能力供给系统 输出不是代码复用 输出是领域能力复用

为什么互联网后端真正的 hard mode 不是开发新功能 而是旧版本一堆用户仍在使用的时候，新版本如何无痛上线？ 什么叫版本兼容 API 兼容 数据结构兼容 协议兼容 前后端松耦合演进

很多人对 DDD 有误解 不是「高深」与「学术」 是为了解决复杂业务本质问题 DDD 在中国互联网业务里最贴的三领域 订单业务 审批业务 定价结算规则 战术层 vs 战略层

绝大部分后端真正成长不是写功能 是从事故里成长 成熟团队的差异：不是不出问题，而是问题出现后能「可回溯、可解释、可修复、可预防」 线上事故的典型三大来源 数据一致性问题

真正的大型后台系统，最难的不是开发 是安全上线 + 可控回滚 灰度发布是 SRE / 后端工程体系中必须具备的一环 灰度能力的演进路径 单服务灰度 多服务灰度 全链路灰度

AI 不是替代后端，是放大后端能力 Post-LLM 时代：后端角色从“数据 CRUD”变“AI 服务 orchestrator” “AI Native 后端”是什么