webman本身不提供物流追踪能力，但可作为高性能追踪后端底座：状态变更需异步写入+redis缓存，避免同步阻塞；轨迹数据应分层存储（header/detail），支持时间线回溯与分段聚合；查询优先走redis，未命中再查mysql并回填；禁用sleep轮询，推荐websocket/sse或长轮询+brpop实现低延迟推送。
Webman 本身不提供物流追踪能力，但它是构建高性能追踪后端的理想底座——关键在于如何设计状态更新模型、避免轮询压垮服务、以及让轨迹数据真正可查可溯。
物流状态变更必须走异步写入 + 内存缓存
直接在 HTTP 请求里同步写数据库+发通知，高并发下单/揽收/派送时会拖慢整个链路。MPAY V2 的支付单状态流转思路可以复用：所有状态变更统一走 Event::fire() 触发事件，由 Redis Queue 或 Webman 自定义进程消费。
- 状态变更请求只校验合法性（如“已签收”不能跳过“派送中”），立即返回
{"code":0,"msg":"已接收"} - 真实写库、更新 Redis 缓存、推送 WebSocket 通知、触发下游清算等动作，全部异步执行
- 轨迹查询接口（如
/track/{order_no}）优先查redis:h:track:{order_no}，未命中再查 MySQL 并回填缓存
轨迹数据结构要支持时间线回溯和分段聚合
单纯存一堆“时间+状态+操作人”日志，查起来慢、前端渲染卡、统计分析难。参考 MPAY 的资金流水设计，轨迹应拆成两层：
Webman 2.2.0
下载
Webman 2.2.0版本强化了 TCP/UDP 服务支持，优化路由组管理，并增强异步任务处理能力。结合协程与连接池技术，Webman 能轻松应对高并发场景，适用于网站、接口服务、即时通讯、物联网及游戏开发，兼具高性能、灵活扩展与稳定可靠，是多场景 PHP 服务开发的理想选择。
-
track_header表存主键、运单号、当前状态、首次/末次更新时间、是否完结 -
track_detail表按时间倒序存每条记录，加segment_id字段用于标识同一段状态（比如“运输中”可能持续 3 天，中间有 5 次 GPS 上报，但对外只显示 1 条“运输中（7月25日 14:30 - 7月28日 09:15）”） - 查询时用
SELECT * FROM track_detail WHERE order_no = ? ORDER BY created_at DESC LIMIT 50，避免全表扫描
不要用 sleep() 或 while(true) 实现轮询
很多新手在“实时追踪”上第一反应是让客户端每 2 秒轮询一次 API，后端再用 sleep(2) 等新数据——这在 Webman 常驻内存模型下等于主动制造阻塞，且极易触发超时或连接堆积。
- 正确做法是用 WebSocket 或 Server-Sent Events（SSE）推状态。Webman 官方支持
Webman\WebSocket\Server，开一个独立进程监听 Redis Pub/Sub 通道即可 - 若必须兼容老浏览器，改用长轮询（Long Polling）：客户端发起请求后，后端用
Redis::brpop()阻塞等待，有新轨迹才返回，而不是自己sleep - 所有轮询接口必须带
If-None-Match和 ETag，利用客户端缓存减少无效请求
真正的难点不在“怎么把状态存进去”，而在于“怎么让下游系统（快递员 App、网点看板、客户小程序）以最低成本拿到最新状态”。Webman 的优势是能扛住每秒数千次的轨迹查询，但如果你的 Redis key 设计成 track:{order_no}:all 存整条 JSON，缓存失效时就会击穿 DB——这个细节，90% 的物流系统上线半年后才暴露。
