每天一条软件法则：意外后果定律

第 13/56 条 Law of Unintended Consequences（意外后果定律）

只要你改变一个复杂系统，就要预期会出现原本没有计划到的结果；很多改动带来的影响，不会只停留在你当初设想的那一层。

它解决的是“只改这一处，别的地方应该没事”的错觉。软件系统、团队流程和业务规则彼此耦合，任何优化、限制、自动化或治理措施，都可能在别的环节触发连锁反应。越是复杂系统，越不能只看局部收益而忽略整体影响。

一个团队为了降低数据库压力，给热门接口加了 aggressive cache，短期看 QPS 降下来了。但新问题很快出现：缓存失效策略不当，用户刚修改的数据看不到；为了补救又加主动刷新，结果写路径变复杂，故障时还出现缓存雪崩。最初的目标只是“减轻数据库压力”，真正落地后却牵出了数据一致性、失效策略、运维和故障恢复一整串问题。

今天做任何架构或流程改动前，先补一张“副作用清单”：这个改动会影响谁、哪些指标可能变好、哪些指标可能变差、回滚路径是什么。先小范围灰度，再观察真实反馈，而不是一次全量上线。边界也要清楚：这条法则不是让你因为害怕副作用而不敢改，而是要求你把“预期之外”视为常态，提前为观察、回滚和修正留空间。