过度封装导致调试、测试和协作成本指数级上升，表现为调用链过长、各层仅转发无实质逻辑、新增功能需多处修改且理解成本高。
会，而且复杂度不是线性增长，是指数级上升——尤其在调试、测试和协作时，你根本找不到逻辑在哪一层被改过。
过度封装让调用链变长，连 var_dump 都不敢乱加
常见现象：点开一个 uploadFile()，发现它调用了 FileService::handle()，后者又委托给 UploadStrategyFactory::get()->process()，最后落到 AbstractUploader::doActualUpload()。中间还夹着两层 trait 和一个接口实现。
问题本质不是“分层”，而是每层都只做一行转发，没引入新逻辑或约束：
- 没有参数校验（比如没检查
$filePath是否为空） - 没做状态转换（比如没记录上传开始时间）
- 没统一错误处理（各层各自
throw new Exception）
结果就是：你想加个日志，得在 4 个地方补 error_log()；想改超时，得确认哪一层真正读取了配置；连单元测试都要 mock 5 个对象才能跑通一个方法。
立即学习“PHP免费学习笔记（深入）”；
PHP 中的典型过度封装模式：trait + interface + abstract class 套娃
场景：一个简单的用户通知功能，本可用一个 sendNotification($user, $message) 解决，却拆成：
-
NotificationInterface（只定义一个send()） -
BaseNotificationTrait（含空的beforeSend()和afterSend()） -
AbstractNotification（构造函数注入一堆未使用的依赖） EmailNotification extends AbstractNotification implements NotificationInterface
后果：
- 新增短信通知？得再写一套几乎一样的类，复制粘贴 80% 代码
- 想临时禁用所有通知？得改 interface、改 trait、改 abstract class、再改所有子类
- 新人看代码第一反应是：“这通知到底发没发？我该 mock 哪个？”
什么时候该停手？看这三条硬指标
判断是否过度，不靠感觉，看实际约束：
- 如果一个方法/类只被调用 1 次，且逻辑不超过 5 行 → 直接内联，别封装
- 如果封装后，调用方要传 3 个以上参数，其中 2 个是“为了传给下一层”而存在的 → 拆得太碎
- 如果改一个业务规则（比如“通知失败重试 2 次”），要动超过 2 个文件 → 封装边界错了
PHP 是弱类型、动态执行的语言，它的优势在于快速表达意图。强行套 Java 式分层，反而把 if ($status === 'active') 这种简单判断，塞进 StatusValidatorStrategy 里，就真不是工程，是自缚手脚。
最常被忽略的一点：PHP 的 autoloader 和 opcode 缓存对深度嵌套类的加载开销不敏感，但人脑对调用栈的理解成本是刚性的。你写的每一层抽象，都在增加别人读懂它所需的时间，而这个时间不会被 opcache 优化掉。
