微服务拆到后期，最头疼的往往不是技术选型，而是防腐层形同虚设和契约漂移（Schema Drift）。尤其是业务迭代快了之后，Wiki 里的架构图和接口文档基本上过两周就成了“历史文物”。
聊聊我们目前在做的两点治理尝试与踩坑：
- 架构约束代码化：光靠 Code Review 靠不住，目前在 CI 阶段引入了 ArchUnit（建议至少升到 1.2.x / 1.3.x 版本，旧版本对一些新语法字节码支持有边缘 Bug），写单元测试强行约束包引用与调用链，比如禁止 Infrastructure 反向依赖 Domain，禁止跨服务模块的“偷渡”调用。
- 契约即代码与防腐：内部 RPC 走 Protobuf 强制 Schema 版本管理相对规范；痛点集中在 HTTP / REST 接口上。在 Spring Boot 3.x 下我们切到了 SpringDoc OpenAPI 2.x（之前 Springfox 停更在 Boot 3 上的坑应该不少人踩过）。最近在折腾 GraalVM Native Image，顺便发现很多基于动态代理或反射的契约 Mock 工具在 AOT 编译阶段非常容易暴毙，需要额外补齐
reflect-config.json 相关的 Reachability Metadata。
想请教下各位老师，你们团队是如何维护跨服务调用契约与防腐层的？
- 破坏性变更（Breaking Changes）靠什么机制兜底？是依赖契约测试（如 Pact / Spring Cloud Contract）在流水线上硬卡，还是接入了 Central Schema Registry？
- 面对快速交付的业务压力，架构治理规则卡得太死经常被吐槽影响研发体验，大家是怎么做平衡的？
