Symfony实时通知系统是分层架构，由Notifier、Transport、Channel及推送协议共同构成；NotifierInterface::send()仅负责分发至Channel，实时性取决于Transport实现，如MercureChannel基于SSE实现准实时推送。
Symfony实时通知系统不是单一组件，而是由Notifier + Transport + Channel + 事件/消息队列/推送协议共同构成的分层架构。它不内置“长连接”能力，而是通过适配不同传输协议来实现不同粒度的实时性——关键在于选对Transport和Channel组合。
NotifierInterface如何串联实时链路
所有通知最终都流向NotifierInterface::send()，但它本身不处理“实时”。它的职责是：校验收件人、遍历可用Channel、调用对应Channel::notify()。真正的实时性由Channel背后的Transport决定。比如MercureChannel会把通知转成HTTP POST发往Mercure Hub；而WebhookChannel只是简单发起一次请求，是否实时取决于目标服务的响应速度。
- 不要假设
send()返回就代表用户已收到——它只表示“已提交给Transport” -
Notification对象必须实现getRecipientId()，否则Mercure等需要订阅ID的Channel无法路由 - 若需失败重试，得在Transport层配置（如
retry_strategy），Notifier层不提供通用重试逻辑
MercureChannel为什么是“准实时”的首选
它基于Server-Sent Events（SSE），比WebSocket轻量，浏览器原生支持，且能天然穿透代理和CDN。但要注意：SSE是单向（服务器→客户端），且连接默认有超时（通常30–120秒），客户端需自动重连。
- Mercure Hub必须公开可访问（不能只跑在
localhost），否则前端JS无法建立EventSource连接 - 前端必须用
new EventSource('/.well-known/mercure?topic=...')，路径要和MERCURE_DSN中hub部分严格匹配 - Topic命名需带命名空间（如
notifications/{userId}），避免不同用户消息混播
为什么不能直接用Process或EventDispatcher替代实时通知
symfony/process是进程管理工具，EventDispatcher是内存内事件总线——它们都不解决“从服务端到浏览器”的网络投递问题。试图用Process起一个长期运行的PHP脚本去轮询数据库，或用dispatch()触发前端轮询，本质仍是伪实时，且极易因超时、内存泄漏、并发失控导致崩溃。
- Process的观察者回调只在CLI生命周期内有效，HTTP请求结束即销毁，无法维持长连接
- EventDispatcher发出的事件不会跨PHP进程传播，更不会自动同步到前端
- 真正需要的是Transport层与外部推送基础设施（Mercure、WebSocket网关、Firebase Cloud Messaging）的集成，而不是在应用层模拟
最容易被忽略的一点：实时性瓶颈往往不在Symfony代码里，而在Mercure Hub的部署拓扑和Topic权限控制上。Hub如果单点部署，整个通知链路就不可用；Topic没做JWT签名验证，任意客户端都能订阅他人通知——这些配置错误比写错一个notify()调用影响更大。
