摘要：新增适配层如果不同时收口旧入口，工程里就会长期并存两套调用路径，文档规则只能暂时兜底，架构本身并没有真正收敛。

这篇短文讨论一种很常见的“改得看起来对、实际上没收口”的修法：为了加新能力，新建一层包装，但老入口继续保留。短期能交付，长期会让规则靠文档而不是靠代码结构维持。

加一层包装却不删旧入口，补丁很快就会变成第二套架构

很多项目的“重构”其实只是包了一层，没有真正收口。

比如系统后来需要加功率限制，于是新增一个统一入口去做检查；但原始的启动函数还保留着，谁都能直接调。表面上新架构已经有了，实际上旧路径仍然活着。

这会带来什么后果

最直接的问题就是调用路径分叉：

• 一部分代码走新入口
• 另一部分代码还在绕过限制直接调用旧接口

这时候团队只能在文档里不断强调：

• 某类动作必须走新入口
• 某个函数不要再直接调
• 某条旧路径仅供历史兼容

听起来像规范，实际上是在用文档补架构漏洞。

为什么这种模式会一再重复

因为它很适合赶工：

• 新需求能快速落地
• 旧代码不用大改
• 回归风险看起来更低

但代价会递延到后面：

• 新人不知道该走哪条路径
• 评审时很难一眼看出是否绕过了新约束
• 旧入口迟迟不删，最终变成隐性后门

真正有效的收口方式

如果新层已经是权威入口，就应该尽早：

1. 让旧入口变成私有实现
2. 限制外部直接引用
3. 把调用点逐步迁到新路径

只有这样，规则才是由代码结构保证的，而不是靠协作记忆保证的。

一句话总结

“加一层”不等于“改好了”。如果旧入口还在公开可用，新层很可能只是工程里的第二套真相。