说明：反模式的价值在于识别信号——架构评审时对照检查，比事后重构便宜一个量级。本文 7 条均来自真实项目（脱敏），部分与成长体系教程互相印证。
反模式 1：微服务全家桶（为「先进」而拆分）
- 症状：5 个人的团队维护 20 个服务；一次需求改动跨 8 个服务联调；事务变成分布式噩梦。
- 代价：基础设施维护吃掉一半人力，交付速度反而下降。
- 识别信号：问「拆开的收益是什么」，回答是「架构要先进」而不是业务指标。
- 出路：模块化单体起步，服务边界画清楚（业务拆解方法），等真实的独立扩缩需求出现再拆。
反模式 2：缓存先行（数据库还没压测就上缓存）
- 症状：慢 SQL 不优化，先套一层 Redis；缓存命中率长期低于 60%。
- 代价：多了一个一致性难题，故障面扩大，根因问题还在。
- 识别信号：缓存加完 P99 没变，只是「看起来在优化」。
- 出路：先做慢查询治理与索引，缓存是放大器不是保险（缓存设计实战）。
反模式 3：分布式锁满天飞
- 症状：凡是可能并发的地方都加分布式锁，锁的粒度混乱，甚至出现死锁与超时失效。
- 代价：锁带来的复杂度远超它防的问题；锁超时后照样并发，还多了「锁没释放」的新故障。
- 识别信号：CR 里出现「这里会不会并发？加个锁吧」且没有说明防的是什么具体问题。
- 出路：先问「并发真的会发生吗」「业务能接受偶尔重复吗」——幂等与唯一约束经常比锁更便宜。
反模式 4：为「未来可能」预支复杂度
- 症状：现在的规模用不上，先上分库分表、消息队列、多机房。
- 代价：复杂度是持续税，每天都在付，收益遥遥无期。
- 识别信号：评审时问「现在不支持会死吗」，回答是「以后可能要」。
- 出路：架构要能演进，而不是一步到位（技术选型方法论：架构复杂度和业务复杂度匹配）。
反模式 5：告警疲劳（50 条告警等于没有告警）
- 症状：告警天天半夜响，值班同学已习惯性忽略；真出故障时没人发现。
- 代价：告警系统变成摆设，故障发现靠用户投诉。
- 识别信号：值班手册没人看，告警规则没有人能说清每条的意义。
- 出路：收敛到 ≤10 条可行动告警，每条带预案（排障工具链）。
反模式 6：把「我的代码」当「系统的一部分」（无文档、无监控）
- 症状：上线靠口头交接，出了故障没人知道依赖谁；系统只有一个人能修。
- 代价：个人成为单点，休假即停摆；故障时排查无抓手。
- 识别信号：「这个只有老张会」——这不是赞美，是风险。
- 出路：上线清单强制含文档/告警/回滚（参考架构评审清单）。
反模式 7：架构评审走过场（形式评审）
- 症状：评审会变成「宣讲会」，30 分钟没人提问；反模式 1–6 全部现场通过。
- 代价：评审是最后一道便宜的门，过了这道门，问题成本放大十倍。
- 识别信号：评审结论永远「通过」，从没有过「有条件通过」。
- 出路：评审前用清单自查（架构评审清单），评审只看「决策与取舍」，不看代码细节。
反模式这东西，最怕的不是没见过，是「见过了却没拿来对照自己」。上面 7 条我基本是按「学费最贵」排的——微服务全家桶和告警疲劳，我都在真实项目里交过钱。评审前把这张单子过一遍，能省下的远不止一次重构。
评审清单模板在这里：架构评审清单。