webman仅负责低延迟推送，不执行行情分析；分析逻辑须由前端或独立服务完成，其核心是构建“推送管道+数据处理边界”，并避免onmessage阻塞、同步拉取、全量重绘等常见误用。
Webman 本身不直接“分析”股票行情，它只负责把实时数据高效、稳定地推给前端；真正的分析逻辑（比如计算MACD、判断金叉死叉、生成K线）必须由前端或独立服务完成。想靠 Webman 写个“分析平台”，核心其实是搭好「低延迟推送管道 + 可扩展的数据处理边界」。
Webman 启动 WebSocket 服务时，onMessage 不能用来发行情
很多新手一上来就在 onMessage 回调里写循环推送：
php
$ws_worker->onMessage = function($connection, $data) {
while (true) {
$connection->send(json_encode(['price' => rand(10, 15)]));
sleep(1);
}
};
这会彻底阻塞当前 Worker 进程，所有其他连接卡死。正确做法是用定时器驱动广播：
-
Worker\Timer::add()设置全局定时任务（如每 100ms 执行一次） - 在回调中遍历
$ws_worker->connections，对每个活跃$connection调用send() - 推送前加简单过滤：只发价格变动 ≥ 0.01 的 tick，避免无意义流量
行情数据源不能堵在主线程里，要用异步拉取或解耦进程
如果在定时器里直接用 file_get_contents('https://api.xxx/quote?code=sh600519')，整个 Worker 会等网络响应完才继续——并发稍高，延迟立刻上秒级。
Webman 2.2.0
下载
Webman 2.2.0版本强化了 TCP/UDP 服务支持，优化路由组管理，并增强异步任务处理能力。结合协程与连接池技术，Webman 能轻松应对高并发场景，适用于网站、接口服务、即时通讯、物联网及游戏开发，兼具高性能、灵活扩展与稳定可靠，是多场景 PHP 服务开发的理想选择。
- 推荐用
Workerman\Connection\AsyncTcpConnection或 Guzzle 异步客户端发起请求 - 更稳方案：单独起一个 Worker 进程（如监听
tcp://127.0.0.1:5566）专职拉行情，主 WebSocket Worker 通过AsyncTcpConnection订阅它发来的更新 - 免费 API 通常限流，务必加
Worker\Timer::add()限频（例如每秒最多 3 次请求）
前端接收行情后，K线图不能每次全量重绘
收到新 tick 就 chart.clear(); chart.addSeries()，Canvas 频繁销毁重建，浏览器 CPU 暴涨、动画撕裂，尤其当推送间隔 ≤ 200ms 时根本来不及渲染。
- 用
lightweight-charts或ECharts的增量更新 API（如updateData、appendData） - 后端推送的应是结构化 K 线片段（含时间戳、open/high/low/close/vol），不是原始 tick 流
- K 线合成逻辑建议放在前端或独立计算服务里，Webman 只做「转发+轻量差分」
Webman 的 app/process/ 目录适合放哪些实时组件？
这个目录专为长期运行、不处理 HTTP/WebSocket 请求的后台任务设计，正好匹配行情系统里的非交互模块：
- 自定义行情采集 Worker：从聚宽/Tushare 拉数据，解析后通过内部 TCP 推给主服务
- 内存级行情缓存同步器：监听 Redis Pub/Sub，更新本地
static::$quotes全局变量 - 简单策略模拟器：定时扫描缓存中的股票列表，触发预设条件并广播信号（如“sh600519 出现 5 分钟 MACD 金叉”）
这些进程与 Webman 主流程完全隔离，挂了不影响 WebSocket 连接，重启也不丢用户状态——这才是真正可运维的实时架构起点。
