上周帮朋友他们团队看PR，一个很简单的需求，用户头像加载失败的兜底图调整，改动量不到20行代码，合进去之后，整个用户中心的接口响应延迟涨了40%。
查了半天才发现。
写代码的小伙子为了图方便，绕开了他们团队之前定的统一图片资源加载层，直接在业务代码里写了个新的HTTP请求逻辑。连之前统一加的缓存、超时、鉴权头都没带上。
别把架构一致性当成上线前的合规检查
很多团队现在的代码评审，就盯着代码风格、变量命名、有没有空指针，真正碰架构的部分全靠架构师有空的时候扫一眼，大部分时候只要测试能跑过，就敢合。
说白了，架构一致性检查不是要卡谁，是那些写在最初架构文档里的约束，不是给新人看的摆设——比如”所有跨服务调用必须走统一网关层，不允许业务服务直连其他服务的数据库””所有涉及用户敏感信息的日志必须经过脱敏处理，不允许直接打印明文””所有定时任务必须注册到统一调度平台，不允许在业务进程里起独立的线程跑周期任务”。
这些东西，写代码的人可能改着改着就忘了。毕竟临时写个直连的逻辑，跑测试用例的时候确实能通。快。省得去翻统一层的API文档，找对应的方法，处理异常分支。
我之前接触过一个团队，他们最开始做微服务拆分的时候，定了规则，所有服务的依赖方向只能从上层业务指向下层基础服务，不允许反向依赖，更不允许跨层依赖。最开始半年大家都遵守，后来业务迭代快了，有个开发为了少写两个接口，直接在订单服务里引用了用户服务的内部实体类。当时评审的时候大家觉得”就这一点引用，又不会出问题”，就放过去了。
结果呢？后面半年里，前前后后有7个服务都这么干了，最后整个依赖关系网缠成了一团乱麻，想把用户服务从集群里拆出来做独立扩容，光梳理依赖就花了三个多月，期间还因为漏了一个隐藏的依赖，导致线上连续出了两次核心流程故障。
别等技术债堆成山才想起补检查
很多人觉得代码评审里加架构一致性检查，就是给开发加负担。
麻烦在于，你如果在PR阶段就把这个检查做了，最多就是让开发多花十分钟，把绕开统一层的代码改回符合规范的写法。要是等代码合进去跑了半年，线上出了问题再回头找，那可能是几十上百人的团队，花几个礼拜去重构，去补漏洞，这个代价比起来，哪个划算根本不用算。
真的，别觉得这点小事无所谓。我见过太多团队，最开始都是抱着”就这一次，下次注意”的心态，放行了第一个不符合架构约束的PR，后面的口子就再也收不住了。
架构一致性检查不是要你在评审的时候逐字逐句去抠代码，是要在评审的checklist里，固定几个最容易出问题的检查点——比如有没有绕开统一的基础设施层，有没有违反之前定的依赖方向规则，有没有引入和现有技术栈不兼容的新依赖。这些点，哪怕评审的时候花30秒扫一眼，就能挡住大部分的问题。
检查的尺度从来不是死的
别搞成僵化的合规检查。
之前有个团队，为了卡架构一致性，定了死规则，所有改动只要碰了架构约束，不管什么情况都不准合。结果有次线上出了紧急故障，要临时加个逻辑快速止血，评审的时候因为这个改动绕开了统一的错误上报层，卡了快二十分钟，最后故障影响范围扩大了好几个量级。
说白了，架构一致性检查的本质，是让大家对系统的边界有共识，不是要拿规则当挡箭牌。碰到紧急情况，你该走临时流程就走，事后补个回溯，把临时改动的逻辑在一周内改回符合规范的写法就行，别拿着规则当万能卡，耽误正事。
现在很多团队搞自动化，把一部分架构检查的逻辑写成静态扫描规则，比如检测到代码里有跨服务直连的IP，就自动在PR下面评论提醒。这个东西确实好用，但不能全靠工具。毕竟很多架构上的问题，是工具扫不出来的——比如你为了实现一个小功能，在本来无状态的服务里硬塞了个本地的内存缓存，工具根本不知道你的架构是怎么设计的，也就没法判断这个改动是不是破坏了一致性。
上次和一个做基础架构的朋友聊天，他说他们团队现在的代码评审，架构师根本不会参与所有PR的评审，但是每个评审人都会被要求，看到不符合之前定的架构约束的改动，必须直接指出来，不管这个改动是谁写的。就这么个简单的规则，半年下来，他们系统里的架构类问题，比之前降了快七成。
别觉得架构一致性是很虚的东西。你每天写的每一行代码，合的每一个PR，最后拼起来就是整个系统的骨架。要是每次写代码都图方便，绕开之前定的规则，今天掏一块砖，明天拆一块瓦，再结实的房子，迟早也会塌。
代码评审里把这道检查关把好，真的比你事后花几个月重构要划算太多。对吧？