代码腐烂的元凶:不是技术债务,是耦合
Site Owner
发布于 2026-05-27
为什么你的系统改完就崩?不是代码烂,是模块之间的关系乱了。七个耦合类型,从非直接耦合到内容耦合,看看你的代码在哪个级别。

代码腐烂的元凶:不是技术债务,是耦合
你以为系统崩是因为代码烂?错了。问题在模块之间的关系——而这个关系,有个听起来很无害的名字:耦合。
很多程序员以为代码质量差是"写的问题"。其实大部分系统死掉,不是因为某个人写了烂代码,而是因为模块之间的关系乱成了一团毛线。你改一个模块,另一模块莫名其妙挂了。再改,再崩。最后没人敢动。
这就是耦合在作祟。
七种耦合,从"完全不熟"到"直接私奔"
耦合听起来抽象,其实就是问:两个模块之间,谁知道谁多少?
按严重程度,从低到高排是这样的:
1. 非直接耦合:最理想,但基本做不到
两个模块完全不直接通信,必须通过主模块转发。比如A模块和B模块完全不直接说话,都找C协调。
这种情况独立性强,但实际系统里几乎不存在。因为完全解耦意味着没有直接调用,这在真实业务里是不可能的。
2. 数据耦合:正常、健康、可接受
A调用B,只传参数。比如getUserName(userId),只传一个ID,返回名字。
简单数据往来,不牵扯复杂结构。这种耦合是工程实践中应该追求的日常状态。
3. 标记耦合:危险边缘,开始埋雷
A调用B,传递的不是简单参数,而是一个数据结构或对象本身。
比如传一个User对象,而不是userId。表面看是"一次传完省事",但这意味着A需要知道B期待什么格式。一旦B改了User结构,A也得改。
你以为自己是在传数据,其实你是在传一个定时炸弹。
4. 控制耦合:已经开始互相影响了
一个模块直接告诉另一个模块"你应该怎么做"。比如传一个控制标志isAdmin=true,B看到这标志就知道该做什么逻辑。
这时候两个模块不是"我给你数据、你处理",而是"我在指挥你"。
5. 外部耦合:全局变量的诱惑
所有模块都访问同一个全局变量。比如大家都在读CONFIG.settings。
这事儿太常见了——CONFIG对象到处扔,到处改,到最后没人知道谁改的、为什么改。
6. 公共耦合:共享一个大澡堂
几个模块共享一个全局数据结构,比如同一个共享内存区域或全局数据库表。
一个模块写了,另一模块立刻能读到。听起来爽,但只要有一个模块修改了数据格式,其他全部中枪。