后端圈子里，有一类设计特别容易获得掌声：
- 架构图画得很漂亮
- 抽象层次分得很清
- 接口命名非常“规范”
- 模块边界看起来很干净
但奇怪的是：
这些设计一旦进入真实业务环境，往往活得并不好。
一、一个残酷事实：真实业务不是“理想模型”
在设计阶段，我们总是假设：
- 数据是干净的
- 状态是可控的
- 调用顺序是正确的
- 异常是少数情况
但真实世界是：
- 数据有历史包袱
- 状态可能被异步修改
- 顺序可能被打乱
- 异常才是常态
于是，很多“理论上很优雅”的设计，一落地就开始打补丁。
二、三种最容易“纸上谈兵”的后端设计
1️⃣ 过度理想化的状态模型
状态机画得非常漂亮，但前提是：
- 所有状态转换都严格发生
- 没有外部系统插手
- 没有人工干预
- 没有历史数据污染
现实是：
状态机画得越干净，
补丁写得越多。
2️⃣ 假设调用者“足够理性”的 API 设计
很多 API 的前提是：
- 调用者理解业务语义
- 调用者知道什么顺序是合法的
- 调用者不会乱试
但现实是：
API 一旦开放，就一定会被“误用”。
设计如果没有强制约束，
那就等于把风险交给了运气。
3️⃣ 为了“通用性”牺牲业务表达力
有些系统为了“通用”，会：
- 把业务语义抽象成 type、code、flag
- 用配置驱动所有行为
- 用一套模型硬套所有场景
结果是：
每个业务都需要大量注释才能说明“这里到底是什么意思”。
通用性并没有减少复杂度，
只是把复杂度藏起来了。
三、为什么顶级工程师反而“设计得不优雅”？
你会发现一个现象：
真正长期跑得住的系统，
很少在设计文档里显得特别漂亮。
但它们有几个共同点：
- 行为非常明确
- 非法路径直接失败
- 边界写得很死
- 很少“兜底式成功”
它们不是为了好看而设计，
而是为了在真实世界中少出意外。
四、一个容易被忽略的真相：复杂性不能消除，只能转移
当你在设计时：
- 把复杂性从代码里拿走
- 把它放进配置
- 放进文档
- 放进“约定”
它并不会消失，
只会在某个更糟糕的时刻，以更难排查的方式出现。
五、判断一个设计是否“经得起真实业务”的方法
你可以问三个问题：
- 如果调用顺序错了，会发生什么？
- 如果数据处于异常状态，系统是失败还是“勉强成功”？
- 如果一个新人误用接口，错误会不会立刻暴露？
如果这三个问题都没有清晰答案，
那这个设计大概率只能活在 PPT 里。
