高内聚低耦合是降低维护成本最直接有效的实践路径：内聚高指模块职责单一、修改影响可控；耦合低指依赖抽象、替换实现不伤核心。它提升新人上手、问题定位与迭代响应效率，缩短Bug修复和需求响应周期。
高内聚低耦合不是设计教条，而是降低维护成本最直接有效的实践路径。它让修改局部逻辑时，影响范围可控、测试边界清晰、协作沟通成本下降。
内聚高：功能职责收得紧，改起来不“牵一发而动全身”
一个类或模块只做一件事，且把这件事做到底——比如“订单支付”模块只处理支付流程（校验、调用网关、更新状态），不掺杂日志记录、库存扣减或通知发送。这样当支付策略变更（如新增微信分账），只需动这个模块，其他部分几乎不用碰。
- 判断标准：方法是否都围绕同一业务目标？字段是否都被多数方法共同使用？
- 重构提示：若发现某个类里有“导出Excel”“发短信”“写数据库”三类完全无关的方法，大概率该拆分。
- 常见反例：把用户注册、登录、密码重置、头像上传全塞进一个UserManager类，表面方便，实则每次加字段或改校验规则都要小心别破坏其他功能。
耦合低：依赖关系理得清，换实现不“伤筋动骨”
模块之间通过抽象（接口/协议）交互，而非硬编码依赖具体类。比如“通知服务”不直接调用EmailSender，而是依赖NotificationService接口；后续要接入企业微信或短信平台，只需新增实现类，原有业务代码零修改。
- 关键做法：用构造函数注入替代new关键字创建依赖；对第三方SDK或外部API封装薄层适配器。
- 信号识别：如果改一个类必须同步改五六个其他类的构造参数或方法签名，耦合已经过紧。
- 实际收益：上线后发现邮件服务商超时率高，切换成异步队列+钉钉通知，两天内完成，没动订单或用户核心逻辑。
维护场景中，它直接缩短三个关键周期
新人上手快：看一个高内聚类，5分钟能理解它干什么；查问题定位准：报错堆栈落在某模块，基本不用跨10个文件追踪；迭代响应快：加新渠道、适配新协议、调整合规逻辑，改动集中在边界处，回归测试范围明确。
- 线上Bug修复：原本平均2.7小时（含排查依赖链），推行模块职责梳理后降至1.1小时。
- 需求变更响应：接入银联新接口，仅新增UnionPayAdapter和配置项，主流程代码无变更。
- 技术债清理：将混杂的“数据工具类”按用途拆为CsvReader、JsonValidator、DbConnectionPool，单元测试覆盖率从43%升至89%。
不复杂但容易忽略：内聚和耦合不是靠工具检测出来的，是每次写方法前问一句“这事该不该归它管”，每次引入依赖时想一下“我能不能只认一个接口”。长期坚持，维护就从救火变成浇水。
