Workerman 实现帧同步需自建16ms定时器统一处理输入、模拟与广播，状态带帧号、按房间过滤连接，避免阻塞操作与高频序列化，用心跳和ACK保障关键帧送达。
Workerman 里怎么实现帧同步的最小可行逻辑
帧同步不是靠 Workerman 自带功能，而是靠你控制每帧的「时间切片」和「状态广播节奏」。Workerman 本身是异步 IO 框架，不提供固定 tick 或帧时钟，得自己搭一个轻量调度器。
常见错误现象：onMessage 回调一来就立刻处理并广播，导致不同客户端收到状态更新的时间差大、帧率飘忽、操作延迟不可控。
- 用
Timer::add启动一个固定间隔（比如16ms对应 60FPS）的全局帧计时器，所有逻辑（输入采集、模拟计算、状态打包）都在这个回调里统一触发 - 客户端发来的操作指令先存进队列（如
$clientInput[$clientId] = $data），帧回调里统一消费，避免边收边算导致顺序错乱 - 关键：帧回调里不做阻塞操作（如 MySQL 查询、文件读写），否则整个帧周期被拖长，后续帧堆积
- 帧号必须随广播一起下发（如
{"frame": 128, "state": {...}}），客户端靠它做插值或丢帧判断，不能只靠时间戳
广播给“部分玩家”而不是全连接，该怎么过滤
游戏里绝大多数时候不需要全服广播，比如 MOBA 小地图视野、FPS 房间内局部物理，直接遍历 $worker->connections 并 if 判断是最常用也最可控的方式。
性能影响明显：1000 连接里每次广播都扫一遍，如果过滤条件写成 if ($conn->room == $targetRoom) 却没给 $conn 预设好 room 属性，就会漏播或误播。
- 连接建立后立刻绑定上下文字段，例如在
onConnect里写$connection->playerId = $uid; $connection->roomId = $roomId; - 广播前先查房间在线列表（可用
static $rooms = [];维护），比遍历全部连接快一个数量级 - 避免在广播循环里调用函数做判断（如
if (in_room($conn, $roomId))），把逻辑平铺，减少函数调用开销 - 注意
$worker->connections是引用集合，遍历时不要 unset 或 close 其他连接，可能引发Connection is closed报错
为什么 send() 调用后客户端收不到，但又没报错
Workerman 的 send() 是异步写入 socket 缓冲区，返回 true 只代表“放进缓冲区成功”，不代表对方已收到。网络抖动、客户端卡顿、TCP 粘包/半包都会让数据滞留在中间。
典型表现：本地调试一切正常，上线后部分手机用户状态延迟 2～3 秒，onClose 里也看不到异常断连日志。
- 加心跳保活：用
Timer::add(30, function() { foreach ($worker->connections as $conn) $conn->send('{"ping":1}'); });，客户端超时未回则主动断连 - 对关键帧（如技能释放、死亡事件）做简易确认机制：服务端发完记
$pendingAcks[$clientId][$frameId] = time()，客户端收到后回{"ack":128}，超时未回可重发一次 - 别依赖
send()返回值判断业务逻辑分支，它只反映底层写入状态 - 用
tcpdump或Wireshark抓包看实际发出的数据，比日志更准——有时是前端 WebSocket 库吞了错误，不是 Workerman 的问题
PHP 做帧同步服务器，哪些地方最容易翻车
PHP 不是为长连接高频率计算设计的语言，Workerman 弥补了 IO 层，但掩盖不了语言层的硬伤：没有真正的多线程、GC 不可控、数组复制开销大。
容易被忽略的点藏在细节里：比如用 json_encode() 打包每帧状态，100 个玩家每人 5KB 数据，每帧就是 500KB 内存临时分配，GC 一跑就卡帧；又比如把所有玩家坐标存在一个大数组里每次 array_filter，O(n) 成为瓶颈。
- 状态序列化优先用
pack()+ 二进制协议，或至少缓存json_encode结果（$cache[$frameId][$roomId]），别每帧重编 - 玩家位置等高频读写数据，用
SplFixedArray或直接维护索引数组（$players[123]['x'] = 100.5），避开关联数组哈希查找 - Worker 进程数别盲目设成 CPU 核心数——IO 密集型场景下，4～8 个足够，再多反而因进程切换损耗性能
- 单个 Worker 里不要存大量静态状态（如
static $worldState = [];），重启时不清，debug 时以为是逻辑 bug，其实是内存残留
