symfony notifier 不支持优先级机制，其策略依赖渠道选择、启用状态、传输配置及业务逻辑编排；需顺序控制时应由业务代码（如 try/catch 或 messenger）实现。
Symfony 本身的通知系统（symfony/notifier）**不支持监听器式的“优先级”机制**，也就是说，它没有类似 event-dispatcher 中通过数字控制执行顺序的 $priority 参数。通知的“策略”不是靠优先级排序，而是靠渠道选择、通道启用状态、传输配置和手动编排逻辑来实现的。
通知渠道本身就是核心策略层
通知系统的设计理念是“按需分发”，而非“按序执行”。每个 Notification 实例在创建时就明确指定要投递到哪些渠道：
-
(new Notification('标题', ['email', 'sms']))→ 只走 Email 和 SMS 渠道 -
(new Notification('告警', ['push', 'slack']))→ 只触发推送和 Slack - 不声明的渠道（如
telegram）即使已配置，也不会被调用
真正影响“谁先收到、是否发送”的关键配置
所谓“策略”，实际体现在以下可配置环节：
-
渠道启用开关：在
config/packages/notifier.yaml中，每个 channel 都有enabled: true/false，可动态关闭某类通知 -
传输层限流与重试：例如 Twilio 或 SendGrid 的 transport 可配
retry_strategy和timeout，间接影响送达时效 -
接收者粒度控制：
new Recipient('user@example.com', '+1234567890')中传入多个联系方式，Notifier 会并行尝试所有匹配渠道，不保证先后 -
自定义通道逻辑：可实现自己的
ChannelInterface，在notify()方法中加入条件判断或延迟逻辑（如：高重要性通知才发短信，否则只发邮件）
需要“顺序控制”？得自己封装逻辑
如果业务上确实要求“先发邮件，成功后再发短信，失败则告警”，这不是通知系统原生能力，而应由业务代码组织：
- 用
try/catch包裹第一次通知（如 email） - 捕获
TransportException后触发备用渠道或记录日志 - 或使用 Messenger 组件将通知拆成多个消息，按队列顺序消费
别和 EventDispatcher 的优先级混淆
有人误以为 notifier 也支持监听器优先级，是因为两者都用“事件”概念。但注意：
-
event-dispatcher是通用事件总线，监听器可注册多个、需严格排序 -
notifier是专用消息投递服务，send()是一次明确的、目标导向的操作 - 它的扩展点在
Channel和Transport，不在执行顺序
