symfony 4 的服务装饰器不支持 priority 属性，其执行顺序由容器编译时依赖图决定，本质是“替换+委托”，多个装饰器按 services.yaml 定义顺序自上而下套娃叠加。
在 Symfony 4 中，服务装饰器（Decorator）本身不支持 priority 属性，它和事件监听器、Normalizer、Twig Loader 等组件的优先级机制有本质区别。装饰器的执行顺序由容器编译时的依赖图决定，而非通过 priority 数值控制。
装饰器的本质是“替换+委托”，不是“排队执行”
装饰器的作用是：用一个包装类（decorator）替代原始服务，并在调用前后插入逻辑（如日志、缓存、权限检查）。它不参与“多个同类服务谁先被选中”的竞争，因此不需要 priority。
- 装饰器通过
decorates配置绑定到目标服务，例如：App\Service\LoggingMailer: decorates: 'mailer' - 被装饰的服务会自动重命名为
.inner（如mailer.inner），装饰器构造函数中注入它即可完成委托 - 整个过程只涉及一对一替换，不存在多个装饰器同时作用于同一服务时的排序问题
多个装饰器叠加时，顺序由定义先后决定
如果你为同一个服务配置了多个装饰器（比如 A → B → mailer），Symfony 会按 services.yaml 中定义的顺序从上到下依次套娃：
- 先定义的装饰器包在外层（最先执行）
- 后定义的装饰器更靠近原始服务（最后执行）
- 没有 priority 字段，也不建议手动干预这个链式结构
示例（合法但需谨慎）：
App\Service\CacheMailer:
decorates: 'mailer'
App\Service\LoggingMailer:
decorates: 'mailer'
→ 实际生效的是 CacheMailer → LoggingMailer → mailer.inner，因为 CacheMailer 先被解析，它装饰的是当前的 mailer（此时已是 LoggingMailer）
想控制逻辑执行顺序？改用事件或中间件模式
如果业务需要“多个拦截逻辑按明确优先级执行”，装饰器不是合适选择。应转向：
-
事件系统：监听
mailer.pre_send等自定义事件，用 priority 控制监听器顺序 - Messenger 中间件：对消息处理链设置 priority，适合异步/命令场景
-
自定义接口+服务链：定义
MailProcessorInterface，用 tagged iterator + priority 排序后手动调用
常见误区提醒
以下写法无效且会被忽略：
App\Service\MyDecorator:
decorates: 'some_service'
tags:
- { name: 'container.decorator', priority: 10 }
Symfony 容器不识别 container.decorator 标签，也无 priority 处理逻辑。强行添加只会增加配置噪音。
