一、一个你一定听过、但从没人敢拆穿的说法
在系统设计评审会上，我们经常会听到这些话：
- “这个先预留一下，后面再决定”
- “现在先写死，等业务清晰了再抽象”
- “先用配置，未来再升级成引擎”
- “先放在一个服务里，之后再拆”
听起来都很合理，甚至很“专业”。
但如果你把这些话翻译成大白话，其实意思是：
我现在不想为这个问题做决定。
二、架构不是“想清楚了再做”，而是为不可避免的选择买单
很多人误以为：
架构 = 把未来都想清楚
这是错的。
真正的架构是：
在信息不完整的情况下，依然要做出明确选择。
因为不做选择，本身也是一种选择 ——
选择把复杂度推给未来的自己、同事、甚至公司。
三、最常见的三种“假架构设计”
1️⃣ “配置化一切”假象
你见过这样的系统：
- 所有逻辑都走配置
- JSON 比代码还复杂
- 一次问题排查，要查三层配置、两个数据库、一个缓存
表面看：
灵活、可扩展、可配置
真实情况是：
系统失去了“行为边界”，任何人都可以在不理解系统的情况下修改它。
这是典型的：
把“决策权”从工程，交给了混乱。
2️⃣ “以后再拆”综合征
很多系统一开始是一个大服务，然后说：
“没事，后面可以拆微服务”
但你很少看到真正顺利拆成功的。
因为真实世界是：
- 数据已经耦合
- 状态已经共享
- 隐式依赖已经形成
- 线上流量不允许你随意切
所谓“以后再拆”，
往往意味着：
永远拆不了。
3️⃣ “通用抽象”过度设计
有些人非常喜欢：
- 通用引擎
- 通用模型
- 通用流程
- 通用接口
结果是：
- 没一个业务真正用得顺
- 每个业务都要打补丁
- 抽象层反而成了最大阻力
这是因为：
抽象不是提前想出来的，是被具体问题逼出来的。
四、真正成熟的架构师，反而做三件“看起来不高级”的事
✅ 1. 明确拒绝未来
他们会说：
“这个版本不支持这种情况。”
不是因为做不到，而是因为：
- 每多支持一种情况
- 就多引入一条不可逆的复杂度路径
✅ 2. 用“限制”换“清晰”
例如：
- 明确哪些状态不能跳
- 明确哪些接口不保证幂等
- 明确哪些操作不可回滚
这不是不负责任，而是：
对系统长期可维护性负责。
✅ 3. 愿意背锅式决策
真正的架构决策是：
“如果这个选择错了，我知道后果是什么。”
而不是：
“反正现在也看不出来，先放着。”
五、一个结论，可能会让很多人不舒服
架构不是“设计得多灵活”，
而是你敢为多少不灵活负责。
