站内消息必须自建message实体+数据库表，因addflash()仅支持单次跳转提示，无法实现历史记录、未读计数、多端同步；仅需操作反馈时才用addflash()。
站内消息用 Flash Bag 还是自建 Message 实体？
站内消息不是通知系统（Notifier）的职责，它属于用户会话或持久化数据范畴。用 addFlash() 只能支撑「跳转后显示一次」的轻量提示，比如表单成功提交；但若要支持历史记录、未读计数、多端同步、消息分类（系统/私信/审批），就必须自建 Message 实体 + 数据库表 + 控制器逻辑。
常见错误是把 addFlash() 当成站内信系统来用——它不落库、不关联用户ID、无法查询、不能标记已读。一旦用户刷新页面或从其他入口进入，消息就彻底丢失。
- 需要「存下来、可查、可读/未读管理」→ 必须建实体，字段至少含
user_id、title、content、is_read、created_at - 仅需「当前操作结果反馈」→ 用
$this->addFlash('success', '保存成功')，并在模板中写{{ app.flashes('success')|first }} - 别在 Flash 中塞 HTML 或大量文本——它设计为短提示，过长内容会被截断或破坏布局
推送通知该走 Notifier 还是 Messenger？
推送通知（如 Web Push、iOS APNs、Android FCM）必须用 symfony/notifier，而不是 messenger。Messenger 是消息总线，负责任务调度和解耦；Notifier 才是专为「向终端用户投递消息」设计的组件，它内置 PushChannel 和对应 transport（如 symfony/web-notifier）。
直接错配的后果：用 Messenger 发送 SendPushNotification 消息，却没写处理器去调 NotifierInterface->send()，结果消息进了队列就停住，前端永远收不到。
- Web Push 需额外安装
symfony/web-notifier，并配置 VAPID 密钥对（VAPID_PUBLIC_KEY/VAPID_PRIVATE_KEY） - FCM 要配
firebase://DSN，且服务账号 JSON 文件路径必须通过FIREBASE_CREDENTIALS环境变量传入 - 推送前务必检查
Recipient是否实现了getDeviceToken()方法——Notifier 会自动调这个方法取 token，返回 null 就跳过
如何让站内消息和推送通知联动？
典型场景：用户提交订单后，既要存一条站内消息（供用户在「我的消息」页查看），又要发一条 Web Push 提醒（即使他没开着网页）。这不是两个独立动作，而应由一个业务事件触发两者，推荐用 Messenger 做协调者。
错误做法：在控制器里硬编码两段逻辑 —— 先 $messageRepository->save(...)，再 $notifier->send(...)。这样耦合重、难测试、失败时无法回滚。
- 定义一个消息类，如
OrderPlacedEvent，只携带必要上下文（$orderId,$userId） - 注册两个处理器：
StoreInboxMessageHandler（存数据库）和SendPushNotificationHandler（调NotifierInterface） - 在
messenger.yaml中路由：App\Event\OrderPlacedEvent: ['async', 'notify']，确保两者异步执行 - 避免在处理器里做耗时操作（如渲染 Twig 模板）——推送内容应提前生成或惰性加载，否则拖慢队列消费
为什么 Web Push 在本地开发环境总失败？
Web Push 协议强制要求 HTTPS，而 Symfony 的 php -S 内置服务器只支持 HTTP。浏览器拒绝注册 service worker，getDeviceToken() 返回空，整个链路静默中断。
这不是代码 bug，是协议限制。你看到控制台报 Failed to register a ServiceWorker 或 Registration failed - no active service worker，基本可以确定是这原因。
- 开发阶段必须用反向代理（如 Nginx + mkcert 生成本地 HTTPS）或使用
symfony server:start --no-tls的降级方案（仅限调试，部分浏览器仍会拦截） - VAPID 公钥必须 Base64URL 编码，且不能带换行符——复制时容易多出空白，导致
DOMException: InvalidCharacterError - 前端注册 service worker 后，要主动调
navigator.serviceWorker.ready再获取 subscription，否则可能拿到 null
实际落地时最易被忽略的是「渠道与接收者的契约一致性」：Notifier 不会校验你传的 Recipient 对象是否真有 getDeviceToken()，也不会提醒你漏配 webpush transport。它只是安静地跳过——没有错误，也没有日志，只有空白的推送记录。
