1. 耦合概念基础：什么是耦合、耦合的度量标准、为什么选型时要关注耦合
1.1 到底什么是耦合？
耦合这个词，说白了就是「两个模块之间的依赖关系」。
我习惯这样理解：如果修改模块A，模块B也得跟着改，那它们就是耦合的。改得越多，耦合越紧。
举个例子。你写了一个函数，直接调用了另一个函数的内部变量。这就是紧耦合。如果改成通过接口传参，那就是松耦合。
核心定义：耦合度衡量的是模块之间相互依赖的强弱程度。依赖越强，耦合越紧；依赖越弱，耦合越松。
我在项目中遇到过最典型的紧耦合案例：一个支付模块直接读取了订单模块的数据库表结构。后来订单表加了个字段，支付模块就崩了。嗯，这种问题其实很常见。
1.2 耦合的度量标准
耦合不是玄学，它是有量化指标的。我个人习惯从以下几个维度来评估：
| 度量维度 | 说明 | 紧耦合表现 | 松耦合表现 |
|---|---|---|---|
| 数据耦合 | 模块间传递的数据量 | 传递整个对象或内部结构 | 只传递必要的基本类型 |
| 控制耦合 | 一个模块控制另一个模块的逻辑流程 | 传递标志位控制分支 | 通过策略模式解耦 |
| 外部耦合 | 模块依赖外部环境（文件、数据库） | 直接读写共享文件 | 通过抽象接口访问 |
| 公共耦合 | 多个模块共享全局数据 | 使用全局变量 | 使用依赖注入 |
| 内容耦合 | 一个模块直接访问另一个模块的内部 | 直接修改对方私有属性 | 通过公开方法访问 |
我的经验：实际项目中，数据耦合和控制耦合是最常见的。公共耦合和内容耦合一旦出现，基本就是技术债的源头。我曾经接手过一个遗留系统，全局变量满天飞，改一个功能要排查十几个文件——那感觉，你想想看。
1.3 为什么选型时要关注耦合？
这个问题其实很实在。你选一个框架、一个中间件、一个架构模式，本质上就是在选择耦合方式。
为什么会这样？因为耦合决定了三件事：
- 可维护性：紧耦合的系统，改一处动全身。我见过一个团队，每次上线都要拉上全组人，因为不知道改了这个模块会影响谁。
- 可测试性：紧耦合的模块很难单独测试。你得把整个系统跑起来才能测一个功能。说白了，单元测试写不了。
- 可扩展性：紧耦合的系统，加新功能就像在积木塔上再加一块——随时可能塌。
避坑指南：我曾经在选型时选了一个「功能强大但耦合紧密」的框架。当时觉得省事，结果半年后想替换其中一个模块，发现它和框架深度绑定，根本拆不下来。嗯，那次的教训很深刻。
所以，选型时我建议你问自己三个问题：
- 这个组件替换起来方便吗？
- 它和现有系统的依赖关系清晰吗？
- 如果它出了问题，影响范围能控制住吗？
这三个问题，其实就是耦合度在选型中的实际体现。
1.4 耦合与内聚的关系
聊耦合，就绕不开内聚。我习惯把这两个概念放在一起看：
- 高内聚：模块内部的功能紧密相关，职责单一。
- 低耦合：模块之间的依赖尽可能少。
你想想看，一个模块内部乱七八糟什么功能都有，它必然要和外部很多模块打交道。这就是低内聚导致高耦合。反过来，高内聚的模块，对外暴露的接口少，自然耦合就低。
一句话总结：高内聚是低耦合的前提。选型时，优先选那些职责清晰、接口简洁的组件。
1.5 知识体系图
下面这张图，是我梳理的耦合概念知识体系。你可以把它当作本章的思维导图：
这张图把本章的核心内容串起来了。从定义出发，到度量标准，再到选型时的实际考量，最后落到内聚关系和选型三问。你可以在后续章节中反复对照这张图来理解。
一个小建议：刚开始接触耦合概念时，不用死记硬背那些度量维度。你先记住一条原则——「改一处，不影响别处」。能做到这个，耦合度就不会太差。
公众号:蓝海资料掘金营，微信deep3321