一、先分清两种问题是「过度封装」还是「同事不熟悉你的设计」1. 真・过度封装常见特征简单一行逻辑拆了 3 层以上函数 / 类跳转看业务要不停跳转文件为了封装而封装没有复用价值只是强行分层命名抽象空洞HandleData()、ProcessCore()看不出做什么中间层只做转发A 调用 BB 只转发给 C无任何加工逻辑基础判断、简单计算单独抽成类调用成本远大于阅读成本2. 只是习惯差异不算封装问题分层规范统一只是同事习惯平铺代码封装是为了复用、解耦、隔离第三方依赖每层职责清晰注释 / 函数名能一眼看懂流程二、快速自查优化方案1. 干掉无意义中转层如果中间函数只有一行调用下级直接内联删除多余封装 反面示例// 多余中转纯浪费跳转 void UserService::calcMoney() { m_calc-run(); }优化直接调用m_calc-run()删掉一层接口2. 分层遵循「单一职责 控制层数」通用经验业务主流程最多2~3 层调用超过就要合并 / 简化表层接口 / 控制器接收参数、参数校验中层业务逻辑核心计算、流程编排底层工具 / 数据库 / 第三方原子能力 禁止套娃控制器→A 服务→B 服务→C 工具→D 工具3. 命名杜绝模糊降低阅读成本差execTask()、doBiz()、dealInfo()好calculateUserRechargeAmount()、queryOrderUnpaidList()函数名直接说明做什么不用点进去猜逻辑4. 长流程增加「扁平聚合入口」多层拆分后别人读起来绕可以对外提供一个聚合接口把完整流程收拢// 对外统一入口同事只看这一个方法就能看懂完整流程 Result UserManager::createRechargeOrder(Req req) { checkParam(req); auto money calcAmount(req); auto order saveOrder(money); sendNotify(order); return order; }内部细节拆分对外入口扁平兼顾封装和可读性。