php装饰器模式需严格遵循接口统一、显式委托、职责单一、禁止魔术方法四条规范，否则易引发类型错误、调用失效或调试困难。
PHP 的装饰器模式不是语言特性，而是手动实现的设计模式，必须遵循几条关键规范才能真正发挥“动态扩展、解耦复用”的作用。不守规范容易导致类型错误、调用失效、链式断裂或调试困难。
接口契约必须严格统一
装饰器与被装饰对象必须实现完全相同的接口（或继承同一抽象类），包括方法名、参数数量、类型声明、返回类型。PHP 8+ 启用严格类型后，这点尤为关键——哪怕一个参数缺少类型提示，或返回值写成 void 而接口要求 bool，都会在运行时抛出致命错误或静默失败。
- 接口定义需覆盖所有待增强的方法，不能只写部分
- 避免使用 mixed 或宽松类型，优先用具体类型（如 float、string）提升可维护性
- 装饰器类的构造函数参数类型也必须是该接口，而非具体实现类，否则无法嵌套
组合关系需显式持有并委托调用
装饰器必须通过构造函数接收被装饰对象，并以私有属性保存其引用；所有方法内部必须显式调用 $this->wrapped->method()，不能遗漏、不能跳过、不能条件性省略。这是装饰器“包装”语义的核心体现。
- 漏掉委托调用会导致功能静默丢失，且无任何报错提示
- 禁止在装饰器中 new 具体实现类（如 new StripeProcessor()），否则破坏依赖注入和测试隔离
- 前置/后置逻辑应围绕委托调用组织，而非重写整个业务流程
职责单一且可安全嵌套
每个装饰器只负责一项横切关注点（如日志、缓存、重试、权限校验），不混杂多个逻辑。同时要确保装饰器之间能按需叠加，且顺序敏感的功能（如 Auth → Cache → Retry）必须在外层构造时明确表达。
- AuthDecorator 必须包在 CacheDecorator 外层，否则未授权请求可能命中缓存
- RetryDecorator 通常放在最外层，保证重试逻辑覆盖全部内层异常
- 避免在装饰器内部做类型判断或分支路由——那是策略模式的职责
禁止用魔术方法替代显式委托
虽然可用 __call() 实现泛型代理，但会牺牲类型安全、IDE 支持、opcache 效率和调试体验。面试和生产环境均不推荐。
- __call() 绕过 PHP 类型检查，方法签名变更时无法提前发现
- 堆栈信息被污染，debug_backtrace() 中全是 __call，难以定位真实调用点
- 反射调用带来性能开销，尤其在高频路径（如 API 网关）中不可忽视
- 除非构建高度动态的 DSL（如 Query Builder），否则坚持为每个方法写显式委托
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
