php无原生@decorator语法，需通过接口契约与类组合手动实现装饰器模式：装饰器与被装饰者实现同一接口，持引用委托调用，支持链式叠加与单一职责增强。
PHP 里没有 @decorator 语法，得靠类组合和接口契约
PHP 原生不支持 Python 那种 @decorator 语法，所谓“装饰器模式”在 PHP 中本质是**手动构造包装对象**，靠接口统一行为、用组合代替继承。关键不是语法糖，而是结构是否可叠加、职责是否单一。
典型错误是直接在原类里加新方法，或者用 trait 模糊了“装饰”的边界——trait 是水平复用，装饰器是运行时动态增强，两者目的不同。
- 必须定义一个与被装饰类相同的接口（比如
ProcessorInterface） - 装饰器类实现该接口，并持有一个该接口类型的实例（
$wrapped） - 每个装饰器只负责一件事：日志、缓存、权限校验等，不能堆逻辑
- 创建时按需链式包裹：
new CacheDecorator(new AuthDecorator(new RealProcessor()))
用 __call() 实现通用装饰器基类容易踩内存和性能坑
有人用魔术方法 __call() 写泛型装饰器，看起来省代码，但实际隐患多：反射调用慢、IDE 无法跳转、类型推导失效、错误堆栈变深。除非你明确需要高度动态的代理（比如 ORM 查询构建器），否则不推荐。
更稳的做法是让每个装饰器显式委托方法：
class LoggingDecorator implements ProcessorInterface
{
public function __construct(private ProcessorInterface $wrapped) {}
public function handle(string $data): string
{
error_log("Processing: {$data}");
return $this->wrapped->handle($data);
}
}
-
__call()会绕过 PHP 的类型检查和 opcache 优化 - 如果被装饰类方法签名变更，泛型装饰器不会报错，直到运行时才崩
- 调试时看不到真实调用链，
debug_backtrace()里全是__call
装饰器链顺序错了会导致逻辑覆盖或失效
顺序不是随便写的。比如 AuthDecorator 必须在 CacheDecorator 外层，否则未授权用户也能命中缓存；又比如 RetryDecorator 要包在最外层，不然重试逻辑可能被内层提前终止。
- 缓存装饰器通常放最内层（靠近真实业务逻辑），避免缓存中间状态
- 日志、监控类装饰器适合放最外层，能看到完整流程耗时
- 如果用了依赖注入容器（如 Symfony DI 或 Laravel Container），别把装饰器注册成单例并循环引用
$this->decorated - 注意构造时传参：不要在装饰器里 new 实例，应由容器统一 resolve
Laravel 和 Symfony 生态里装饰器常被中间件/事件替代
在 Laravel 中，HTTP 请求的“装饰”逻辑（鉴权、CSRF、日志）基本由中间件完成；命令总线（Bus::dispatch()）也自带装饰器链支持。硬套经典装饰器模式反而增加理解成本。
Symfony 的 kernel.request 事件、Messenger 组件的 MiddlewareStack，底层就是装饰器思想，但封装得更贴近场景。
- 不要为了模式而模式：Laravel 的
app()->make(MyService::class)返回的已经是装饰后的实例 - 查
config/cache.php里的stores.redis.decorator配置项，那是框架级缓存装饰器开关 - 自定义装饰器前，先看
vendor/symfony/messenger/下的StackedMiddleware实现
真正难的不是写一个装饰器，而是判断某段逻辑该不该抽成装饰器——它得能独立开关、可替换、不改变原始接口语义。一旦开始给装饰器加配置参数或条件分支，就该停下来想想：这还是装饰器，还是已经变成策略+工厂了？
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
