Workerman仅负责低延迟、高并发推送行情数据，前端渲染K线；须用定时器而非onMessage死循环推送，配合异步IO、差分更新、分组广播及前端增量渲染，确保实时性。
Workerman 本身不画图、不渲染 K 线，它只负责「把最新行情数据，低延迟、高并发地推给前端」。真正画 K 线的是前端（比如 chart.js、ECharts 或 Lightweight Charts），Workerman 的角色是稳稳托住 WebSocket 连接、扛住千级并发、不丢帧、不卡顿。
WebSocket 服务必须用 onMessage + send() 主动推送，不能靠前端轮询
轮询（setInterval + fetch）在行情场景下会快速暴露问题：请求堆积、重复响应、时间戳错乱、服务器压力陡增。而 Workerman 的 onMessage 是连接建立后仅触发一次的握手回调；真正要发数据，得靠定时器或外部事件驱动 $connection->send()。
- 错误做法：在
onMessage里写一个死循环while(true) { $connection->send(...); sleep(1); }—— 会阻塞整个进程，其他连接全卡住 - 正确做法：用
Worker\Timer::add()启动全局定时任务，遍历所有在线连接批量推送 - 注意：推送前最好做简单差分，比如只发价格变动 > 0.01 元的股票，避免无意义流量
行情数据源不能堵在主线程里，要用异步 HTTP 或消息队列解耦
如果你在定时器里直接用 file_get_contents() 或 cURL 同步拉取聚宽/Tushare/自建行情接口，整个 Worker 进程会等网络 IO 完成才继续——并发一上来，延迟立刻飙升到秒级。
- 推荐方案：用
Workerman\Connection\AsyncTcpConnection或GuzzleHttp\Client的异步模式发起行情请求，回调中解析并广播 - 更稳方案：把行情拉取单独拆成一个 Worker（如
tcp://0.0.0.0:5566），用内部 TCP 协议通知主 WebSocket Worker 更新数据，避免 IO 互相干扰 - 警惕点：某些免费行情 API 有调用频次限制，同步拉取容易触发 429，异步+限流（如每秒最多 5 次）必须加
前端接收数据后，K 线图更新不能直接全量重绘
每次收到新 tick 数据就 chart.clear(); chart.addSeries(...)，会导致 canvas 频繁销毁重建，CPU 暴涨、动画撕裂。尤其当推送频率达 100ms/条时，浏览器根本来不及渲染。
- 轻量方案：用
Lightweight Charts的update方法追加单根 K 线，或用timeScale.fitContent()自动缩放，不重绘历史 - 增量逻辑：前端维护一个本地
Map<symbol array>></symbol>，只对当前 symbol 的 K 线数组做push()或replaceLast() - 关键细节：WebSocket 收到的 JSON 必须带精确毫秒时间戳（如
"time": 1747762140123），不能依赖Date.now()，否则多客户端时间不同步，K 线错位
连接数上去之后，$connections 数组遍历会变慢，必须用连接池或分组广播
当在线连接超 2000，foreach ($ws_worker->connections as $conn) 推送一次行情，耗时可能突破 50ms，导致推送节奏失准，K 线出现“跳帧”。
- 简单优化：按股票代码哈希分组，比如
SH600519→ group_1，只向订阅该标的的连接发，减少 80% 无效遍历 - 进阶做法：用
Redis pub/sub做广播中枢，每个 Worker 订阅对应 channel，由 Redis 负责分发，Worker 只管收和推 - 容易忽略的坑：
$connection->send()不是线程安全的，如果多个定时器或回调同时调用，可能触发 warning 或丢包，务必加锁或串行化发送队列
真实行情系统里，最常崩的不是算法，而是连接管理没兜住、时间戳没对齐、前端渲染没节流。这些地方松一扣，K 线图就从“实时”变成“看起来实时”。
