PHP可通过组合实现装饰器模式，核心是运行时动态叠加行为；trait和继承无法满足按需包装需求，装饰器需持被装饰对象引用并显式调用其方法，遵循接口类型依赖，嵌套时注意执行顺序与异常处理。
PHP 本身不支持 Python 那种 @decorator 语法糖，但装饰器模式完全可实现——关键不是语法，而是用组合代替继承，在运行时动态叠加行为。
为什么不能直接用 PHP 的 trait 或继承来替代
trait 是编译期静态复用，无法控制调用时机或包裹原方法；继承则破坏开闭原则，每加一个功能就得新建子类。装饰器要的是「运行时按需包装」，比如对某个 PaymentService 实例临时加上日志、重试、熔断逻辑，而不是改类定义。
- trait 无法拦截方法调用，只能提供方法体
- 继承导致类爆炸（
LoggingPaymentService、RetryPaymentService、LoggingRetryPaymentService…） - 装饰器对象与被装饰对象实现同一接口，客户端无感知，替换成本低
如何让装饰器正确转发并扩展方法调用
核心是装饰器类必须持有被装饰对象的引用，并在自己方法中显式调用它，同时插入前置/后置逻辑。漏掉 $this->wrapped->doSomething() 就会静默失效。
- 必须实现与被装饰类相同的接口（或继承同一抽象类），否则类型不兼容
- 构造函数参数应为接口类型（如
PaymentInterface），而非具体类，保证可嵌套装饰 - 不要在装饰器里 new 具体实现类——那会切断依赖注入链
- 示例：
class LoggingDecorator implements PaymentInterface { private PaymentInterface $wrapped; public function __construct(PaymentInterface $wrapped) { $this->wrapped = $wrapped; } public function charge(float $amount): bool { error_log("Charging {$amount}"); $result = $this->wrapped->charge($amount); error_log("Charge result: " . ($result ? 'success' : 'failed')); return $result; } }
嵌套装饰器时的执行顺序和陷阱
装饰器链是「最外层最先执行、最内层最后执行」，类似洋葱模型。如果顺序写反（比如把 new RetryDecorator(new LoggingDecorator($real)) 写成 new LoggingDecorator(new RetryDecorator($real))），日志里可能看不到重试过程中的中间失败。
立即学习“PHP免费学习笔记（深入）”；
- 初始化顺序决定执行顺序：外层装饰器的
__construct()最先被调用，但它的方法体里调用$this->wrapped->method()时，才进入下一层 - 异常处理要小心：若
RetryDecorator捕获异常并重试，LoggingDecorator可能收不到原始异常，只看到最终成功/失败结果 - 性能开销随层数线性增长，高频调用场景下建议合并逻辑（如用一个
MonitoringDecorator同时做日志+指标+告警） - 避免循环依赖：装饰器内部不得通过服务定位器又拉取自己类型的实例
真正难的不是写几个装饰器类，而是设计好接口粒度和生命周期——比如是否允许装饰器持有请求上下文（RequestContext），以及如何让 __construct() 不变成一堆难以测试的依赖堆砌。
