GosWebSocketBundle是Symfony中实现WebSocket实时通信最成熟方案；它封装Ratchet为Symfony服务，通过Topic和Pusher实现发布/订阅，需配置端口、白名单及安全鉴权，前端用gos/web-socket-client订阅/topic/chat路径。
直接上结论：在 Symfony 项目中实现 WebSocket 实时通信，GosWebSocketBundle 是当前最成熟、集成度最高、维护活跃的方案；纯手写 Ratchet 控制器适合学习或极简场景，但连接管理、广播、订阅/发布、安全鉴权等都要自己补全，线上项目不推荐。
为什么不用原生 Ratchet + EventDispatcher 组合？
很多人看到 symfony/event-dispatcher 和 Ratchet 都是松耦合、事件驱动的，就想手动桥接二者——比如在 onMessage 里触发 EventDispatcher->dispatch()。这确实可行，但会快速暴露三个硬伤：
- 事件对象无法携带
ConnectionInterface实例，监听器拿不到当前连接，也就无法$conn->send() -
EventDispatcher默认是同步执行，而 WebSocket 消息处理需低延迟；若监听器里有耗时操作（如 DB 查询、HTTP 调用），会阻塞整个连接循环 - 没有内置的连接生命周期管理（如认证、心跳、超时踢出），所有逻辑都得堆在
onOpen/onClose里，代码迅速失控
GosWebSocketBundle 的关键配置点
它把 Ratchet 封装成 Symfony 服务，并通过 Topic（主题）和 Pusher 抽象出发布/订阅模型，真正解耦业务与连接层。核心配置注意以下几处：
-
gos_web_socket.server.port必须设为非 80/443 端口（如8080），因为 Symfony HTTP 内核和 WebSocket 服务不能共用同一个端口 -
gos_web_socket.client_origin_whitelist必须显式配置允许的前端域名，否则Origin校验失败，连接直接被拒绝（错误信息：WebSocket connection to 'ws://...' failed: Error during WebSocket handshake: Unexpected response code: 403） - 如果要用 Symfony 的
Security组件做连接鉴权，必须在config/packages/gos_web_socket.yaml中启用firewall_login_route并配置对应路由，否则$this->getUser()在 Topic 中始终为null
前端连接与 Topic 订阅的典型写法
不要直接用原生 new WebSocket()，GosWebSocketBundle 提供了配套的 JavaScript 客户端 gos/web-socket-client，它自动处理重连、心跳、topic 订阅封装：
import { Client, IMessage } from 'gos/web-socket-client';
const client = new Client('ws://localhost:8080');
client.onOpen(() => {
// 订阅名为 'chat' 的 topic
client.subscribe('/topic/chat', (message: IMessage) => {
console.log('收到消息:', message.body);
});
});
client.connect();
后端推送时，只需调用 $pusher->push($data, '/topic/chat')，Bundle 会自动广播给所有已订阅该 topic 的客户端连接。注意：路径前缀 /topic/ 是硬编码约定，不可省略或改成 /chat 等其他形式，否则前端收不到。
真正容易被忽略的是连接上下文隔离——每个 Topic 实例默认是单例，如果你在 Topic 类里存了 private $lastMessage 这类状态，它会被所有连接共享。需要状态隔离时，必须用 ConnectionInterface 作为 key 存到外部容器（如 ArrayObject 或 Symfony 的 Cache），而不是存在 Topic 实例属性里。
