php无原生装饰器语法，装饰器模式需手动实现：所有装饰器与被装饰对象实现同一接口，装饰器内部持有被装饰对象实例，通过组合扩展功能。
PHP 本身没有原生装饰器语法（如 Python 的 @decorator 或 TypeScript 的 @Decorator），所谓“PHP 装饰器模式”是手动实现的 GoF 设计模式，不是语言特性，不能直接写 @Cacheable 或 @Log 这类注解。
装饰器模式在 PHP 中的本质是组合 + 接口一致
核心就两点：所有被装饰对象和装饰器都实现同一接口；装饰器内部持有被装饰对象实例。不是加个注解就自动生效，必须显式构造和调用。
- 常见错误现象：
Call to undefined method CacheDecorator::handle()—— 忘记让装饰器实现与目标类相同的接口 - 典型使用场景：给已有
PaymentService动态添加日志、重试、缓存、权限校验，又不想改原始类或大量继承 - 接口定义必须严格一致，包括方法名、参数数量、返回类型（PHP 8+ 启用严格类型时尤其关键）
- 示例接口：
interface PaymentProcessor { public function process(float $amount): bool; }
手动实现一个带缓存的装饰器（PHP 8.0+）
以缓存支付结果为例，重点看如何保持接口契约、避免耦合、控制装饰顺序。
- 装饰器必须实现
PaymentProcessor，并在构造中接收真实处理器：class CacheDecorator implements PaymentProcessor { private PaymentProcessor $processor; private array $cache = []; public function __construct(PaymentProcessor $processor) { $this->processor = $processor; } public function process(float $amount): bool { $key = 'payment_' . $amount; if (isset($this->cache[$key])) { return $this->cache[$key]; } $result = $this->processor->process($amount); $this->cache[$key] = $result; return $result; } } - 链式装饰必须按需组装：
$decorated = new CacheDecorator(new LogDecorator(new StripeProcessor())) - 注意性能陷阱：缓存键若未标准化（比如浮点精度、单位混用），会导致缓存失效或误命中
- 不推荐用反射自动扫描注解模拟装饰器——运行时开销大、IDE 不识别、调试困难
为什么不用 Doctrine Annotations + AOP 模拟？
有人尝试用 @Cache 注解配合 Doctrine\Common\Annotations 和自定义代理生成器来“模拟”装饰器，但实际落地问题多。
- 错误现象：
Target of annotation is not allowed on method—— 注解目标未正确声明，或解析器未启用 - 兼容性差：PHP 8.2+ 对反射 API 有调整，部分旧 AOP 库已停止维护
- 调试极其困难：方法调用被代理层拦截，堆栈里看不到原始逻辑，
xdebug步进容易迷失 - 无法静态分析：IDE 无法跳转到被装饰后的真实行为，
phpstan和psalm会报错或漏检 - 真正需要动态切面的场景（如统一事务、审计），应优先考虑框架层支持（如 Laravel 的中间件、Symfony 的 EventSubscriber），而非手写 AOP
最易被忽略的一点：装饰器不是万能胶。当被装饰对象的方法签名频繁变动，或装饰逻辑强依赖私有属性/方法时，装饰器会迅速变得脆弱——这时候该重构接口，而不是堆更多层包装。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
