深层继承导致维护困难，因新增/删除逻辑需修改多层、方法覆盖引发隐式耦合；应改用 trait + 依赖注入实现组合，按职责拆分能力，用接口+策略替代深度继承，提升可测性与扩展性。
为什么深层继承会让类越来越难维护
当一个基类被反复继承、子类再继承子类，比如 User → MemberUser → VipMemberUser → EnterpriseVipMemberUser，问题就来了：新增一个“积分等级”逻辑，可能要改四层；删掉某个字段，得逐层检查是否被重写；getProfile() 在第三层被覆盖，但第四层又调用了父级的旧实现——这种耦合不是复用，是债务。
用 trait + 依赖注入替代多层继承
把原本靠继承传递的行为，拆成可插拔的组件。比如用户身份、权限、通知偏好这些职责，各自封装为 AuthTrait、PermissionTrait、NotificationTrait，再通过构造函数注入具体策略对象。
-
trait解决方法复用，但不带状态；真正需要差异化行为（如“VIP用户发短信，普通用户发邮件”）用接口+实现类，比如NotificationStrategy接口和SmsStrategy、EmailStrategy实现 - 类本身只保留核心身份（
$id、$email），其他能力靠use和$this->notifier组合而来 - 避免在
trait中定义同名方法；若多个trait都有logActivity()，必须用insteadof显式声明优先级
什么时候该用组合而不是继承
判断标准很直接：如果子类只是“拥有”某种能力（has a），而不是“是一种”（is a），就该切出去。比如：AdminUser 不是 User 的一种特殊类型，而是 User 拥有管理员权限——那 AdminRole 就该是属性或服务，不是父类。
- 新增角色（如
AuditUser）不需要动原有类结构，只要传入新的RoleStrategy - 测试时可轻松 mock 掉
PermissionService，不用构造一整条继承链 - PHP 不支持多继承，但可以
use AuthTrait, LogTrait, CacheTrait—— 这就是组合的实际优势
老项目改造要注意的坑
直接重写继承树风险高，建议渐进替换：先让子类同时继承旧父类 和 使用新 trait，把原方法体逐步迁移到 trait 中，等所有调用都走通了，再删掉 extends。
- 别在
trait里访问$this->privateProperty；它只能访问public或protected成员 - 老代码里如果大量用
get_class($this)做类型判断，换成接口检测更安全，比如$user instanceof Notifiable - IDE 可能无法正确跳转
trait中的方法，建议在关键use行后加 PHPDoc 注释，例如// @method void log(string $msg)
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
