内聚与耦合
§1摘要与结论
衡量模块划分质量的两个互补维度：内聚是模块内部元素隶属同一目标的程度，耦合是模块之间相互依赖的程度。目标是高内聚、低耦合，但二者只是启发式方向，并非有普适阈值的绝对指标。它衡量的是结构对变更的承载能力。
别名：cohesion、coupling、connascence | 英文：Cohesion and Coupling | 类型：方法原则 / concept
§2局部关系图
§3原理 · 为什么
内聚越高，模块越能独立理解、测试与复用，因为它的元素都服务于同一目标；耦合越低，一个模块的改动就越少波及别的模块，缺陷也不易沿依赖链传播。二者共同决定变更成本与缺陷传播范围，是各种模块化度量与重构手法的共同根基。Constantine 及其合作者把内聚与耦合提炼为可分类的概念，使「好设计」第一次具有可讨论、可度量的特征。需要注意的是：内聚与耦合属性独立但常相关，低耦合往往伴随高内聚，却不能说成同一件事；一个模块可以既低耦合又低内聚，也可以局部高内聚却在整体上强耦合。真正决定改动代价的，是依赖的数量、强度与方向，而不仅是模块的粒度大小。因此，内聚与耦合的讨论应落到「哪一类改动会牵动哪些模块」这一可观察问题上，而不停留在结构外观的相似与否；度量的意义在于指向问题，而非替代判断。换言之，内聚与耦合是同一枚硬币的两面，二者都服务于同一目的：让变更的影响范围可预测、可控制，让缺陷不至于沿依赖关系蔓延到整个系统。
§4机制 · 如何运作
耦合有强弱谱系：从直接访问对方内部表示的强耦合，到共享全局数据、经控制参数传递、以记录或结构传参，再到只交换必要数据的最弱形式；内聚则按元素关联程度排序，从偶然凑在一起、仅在时间或逻辑上相关，逐步上升到顺序、通信，直至所有元素共同完成单一功能。更细的框架用「共生」描述耦合，按改动强度、影响范围与受影响组件数量三个维度评估，并区分编译期可见的静态共生与运行期才显现的动态共生。面向对象度量把这一思路量化：以对象间耦合、类响应集度量耦合，以方法间内聚缺失反向度量内聚。理解这些谱系的价值不在给模块贴标签，而在提供判断「哪一端更贵」的语言，使讨论从主观口味转向可比较的结构性质。这些谱系并非要精确归类每个模块，而是提供一种共同语言，让团队能比较不同划分在改动代价上的差异，并在评审中把口味之争转化为结构性质的讨论。因此，度量的正确用法是先观察改动如何传播，再回看结构指标是否印证；若二者矛盾，应以真实改动历史为准，而不是以静态数值推翻事实。
§5工程 · 怎么落地
工程上以变更影响面与测试隔离度作为第一判据：一处需求变化应当只落在少数模块，一个模块应能在不牵动全系统的前提下被测试。可用依赖图观察扇入扇出，用内聚/耦合度量做巡诊，把「同一职责被拆散到多模块」或「多变化原因挤进同一模块」当作坏味道信号。重构手法——搬移、抽取、内联、封装——都是为调整边界服务：把因同一原因变化的元素聚拢，把仅因偶然而相邻的元素分开。诊断时还要区分「结构性耦合」与「叙述性耦合」：前者由真实依赖驱动，后者只是命名或注释上的相似，不应仅凭表面相似就建立依赖。跨模块修改的爆炸半径，往往比静态数值更能说明划分质量。长期看，最可靠的证据是版本历史：反复被同一需求一起修改的模块，往往本应内聚；而频繁需要同步改动的多个模块，往往暗示耦合过强或边界划错。对继承、回调与共享状态等强依赖来源应重点审查，它们往往在结构图上不显眼，却在实际变更中制造最广的连锁修改，是耦合治理的高价值目标。
§6权衡卡
追求极低耦合会引入过多转发、映射与分布式开销，反而提高理解与运行成本；而过度强调高内聚又可能把跨模块协作硬塞进一个庞大模块。
最终目标不是让每条度量都变好，而是让系统的变更成本随需求演进而保持可控；当度量改善但交付变慢时，就应重新审视衡量标准本身是否偏离了目标。
- 不存在普适阈值：多高算高内聚、多低算低耦合，取决于领域、变更频率与团队规模，同样的数值在有测试保障与无测试保障的代码里含义不同；标准与文献普遍只给出方向，不给出量化判据。
- 机械套用度量会诱发指标被博弈——开发者可能为降低耦合而增加无意义的间接层，或为追求高内聚而把本应共享的逻辑复制到各处。
- 合理的做法是把度量当作发现问题的探针，结合变更历史与领域知识判断，并在重构中持续微调，而非一次性追求某个数字。
- 因此，与其追求某个统一的耦合上限，不如为不同模块按变化频率设定差异化的容忍度，把严格约束留给高频变更的关键区域。
权衡原文仅按显式标记词归栏引用（收益 / 代价 / 反例），其余句子按原序列为「原文要点」；内容逐字引用未改写。
§7学习路径条
§8案例带
preset 通道耦合分析
对 harness「委派工具层→续用管理器→preset 服务→MCP 服务器」这条通道做耦合分析：识别契约、服务定位、数据契约、组合语义、路径与装配一致性六类耦合点，定位「静默丢弃特化」与「装配漂移」两处实质缝隙。
去中心化聊天架构逆向
对一个仅有 58 份设计文档、尚未实现的开源去中心化聊天项目做架构逆向：从设计文本提炼 18 个模块及其依赖关系，重建模块依赖 DAG 与三条核心数据流 DAG，并输出全景理解与深度需求分析。
网申填写扩展逆向架构
对 Chrome MV3 网申自动填写扩展的逆向架构分析：梳理 popup、content、background、options 四模块职责，解剖 12 个站点适配器、双通道消息协议与隐私脱敏机制，并评估其零依赖零构建选型。
网申 v3 多模块解耦
一套面向高可扩展性的网申信息速查扩展架构：以 schema.js 为唯一数据驱动源，把数据模型、存储、纯函数与渲染组织为严格单向依赖的共享层，供 popup 与页面浮层双容器复用，并先立跨模块接口契约。
网申 v2 深度重构
一次由「改一处漏多处」症状触发的深度重构：定位到接口定义散落 12 个文件、存在 7 种接口形态的根因后，以单一契约源、dispatch 消息表与能力注册中心重建三层契约系统，恢复可审计与可校验性。
插件 DAG 两次级联升级
在同一知识库上继续两轮上游级联升级：处理数百次提交与包的增删，暴露「依赖声明不等于运行时引用」、分层须按最长路径深度、纯外部依赖边不得入主图等差分陷阱，并以全量门控校验收口。
dsh-manager 插件深度分析
以「编译依赖、运行时注入、组合装配」三硬依据加源码行号，对第三方插件做依赖、功能、需求溯源与设计问题裁决，并复用上游 DAG 知识库节点标识，使分析结果可与主图互查。
harness 源码架构解析
对 deepseek-harness 官方源码做分层解析：镜像官方架构文档，按九个层与九十余模块建立文档集群，产出跨层联动矩阵与七条关键路径，并钉住「模型可见即已记录」、能力缝三角等设计不变量。
dsh 插件依赖增量定位
以官方插件 DAG 为蓝本，对一个官方清单之外的全新社区插件做功能定位与依赖位置增量分析，产出可下钻交互依赖图与多形态文档的源码级架构逆向案例。
Hermes 七层架构总览
对八千余文件的工业级 AI Agent 项目做七层架构总览逆向，揭示其「越用越聪明」的自进化闭环如何在层间传导的控制型架构案例。
MCP 四件套选型对比
对四个同类 MCP 服务器做源码级能力与成本对比，并以常驻 token 预算为轴给出分级接入策略的技术选型实战案例。
Claude Code 架构逆向
以社区逆向源码、系统提示词与官方文档三源交叉验证，还原一个商业 Agent 的查询引擎、子Agent、工具与权限体系的逆向分析案例。
Open Code Review 图谱
对阿里开源 AI 代码审查 CLI 做源码级解析并构建「知识 + 实践资产 + AI 索引」三合一知识图谱的工程案例。
§9信源与核验
§10原始关系清单
展开：本节点的全部原始关系边（10 条，含边 ID 与方向）
| 关系 | 方向 | 对端节点 | 说明 |
|---|---|---|---|
| 案例印证 | ← CAS-X-05 | preset 通道耦合分析 E-950 | 印证：以内聚与耦合维度逐点评估通道结构 |
| 组合 | ← ESS-H-03 | DRY 单一知识来源 E-12 | 单一知识源与高内聚同向协同 |
| 依赖关联 | ← ESS-H-06 | 组合优于继承与脆弱基类 E-109 | 继承在父子类之间引入实现层耦合 |
| 依据推导 | ← MTH-H-01 | 重构手法族 E-206 | 重构以改善内聚耦合、降低变更成本 |
| 依据推导 | ← MTH-H-04 | 代码复审与可读性治理 E-750 | 评审以高内聚低耦合作为结构判据 |
| 前置依赖 | ← ESS-G-04 | 模块化与分解 E-102 | 模块划分质量以内聚耦合衡量 |
| 前置依赖 | ← ESS-H-01 | 信息隐藏 E-02 | 理解信息隐藏是评估内聚耦合的前提 |
| 前置依赖 | → ESS-G-03 | 边界与接口隔离 E-04 | 内聚耦合度量指导边界划分 |
| 细化 | ← ESS-H-08 | SOLID 职责划分与替换性 E-742 | SOLID 以职责划分细化高内聚低耦合判据 |
| 细化 | ← ESS-H-09 | 设计模式与反模式 E-744 | 模式是被命名的内聚与解耦结构解法 |