workerman白板同步核心是精准消息路由与广播，需绑定room_id、过滤同房间连接、标准化坐标、清理断连用户，并避免多进程导致的顺序混乱。
Workerman 实现白板同步，核心不是“画什么”，而是“谁在什么时候画了什么、怎么广播给谁”。只要消息结构清晰、连接稳定、广播逻辑不漏人，Canvas 绘图本身完全由前端控制。
onMessage 中必须做消息路由和广播过滤
白板是多房间场景，不能所有客户端都收到所有笔迹。直接 $connection->send($data) 会把 A 房间的涂鸦发给 B 房间的人。
- 每个连接需绑定唯一
room_id（例如从 URL 参数或首次 handshake 消息中提取） - 用 PHP 数组或
Swoole\Table（若已集成）维护room_id → [connection1, connection2, ...]映射 -
onMessage收到数据后，先解析 JSON，检查type字段（如"stroke"、"clear"、"cursor"），再只广播给同room_id的其他连接 - 务必跳过发送者自身：
if ($conn !== $connection) { $conn->send($data); }
客户端发来的坐标必须标准化再转发
Canvas 坐标依赖视口尺寸、缩放、偏移，不同设备渲染结果会错位。服务器不做归一化，就会出现“A 画了一条线，B 看到的是斜线或断点”。
MiniMax 媒体生成
下载
一款AI音频处理工具，主要用于MiniMax统一媒体生成技能，用于TokenPlan工作流。当用户要求生成音频、语音、TTS、旁白、图片、插图、姿势等媒体内容时使用，适合需要提升相关任务效率的用户。
- 前端发送时，不要传原始
clientX/clientY，而应传 canvas 内部坐标（canvas.getBoundingClientRect()计算后归一到 0–1 范围，或转为相对 canvas 左上角的整数像素值） - 服务端不做坐标计算，但必须原样透传——别用
json_encode($data, JSON_UNESCAPED_UNICODE)以外的方式处理，避免浮点精度丢失或 key 重排 - 如果支持缩放/平移，建议把 view state（scale、offsetX、offsetY）也作为独立消息类型同步，而不是混在笔迹里
连接断开时需清理房间成员，否则产生 ghost 用户
用户刷新页面、切后台、网络抖动都会触发 onClose，但默认 Workerman 不自动从房间列表中移除该连接，导致后续广播仍尝试向已失效的 $connection 发送数据，触发 warning 甚至 crash。
- 在
onClose回调里，根据该$connection存储的room_id和user_id，从房间映射表中 unset 对应项 - 推荐给每个
$connection手动挂属性：$connection->room_id = $roomId;、$connection->user_id = $uid;（注意：这些属性仅进程内有效） - 不要依赖
$connection->getRemoteIp()做去重——NAT 或代理下 IP 不唯一；也不要靠心跳超时自动清理，延迟高且逻辑复杂
并发编辑冲突靠前端防，后端只保证顺序送达
Workerman 是单线程事件循环，同一进程内 onMessage 是串行执行的，但多个 worker 进程之间无共享内存。如果你启用了 $worker->count = 4，而没做进程间消息路由，就可能出现 A 在进程1发的 stroke、B 在进程2发的 clear，最终客户端收包顺序混乱。
- 简单方案：只用 1 个 worker 进程（
$worker->count = 1），适合中小规模白板（ - 进阶方案：引入 Redis Pub/Sub，在
onMessage中publish到room:xxx频道，所有 worker 订阅该频道并本地广播——这样能水平扩展，但增加延迟和运维成本 - 无论如何，前端必须实现操作队列 + 服务端时间戳回传（例如服务端收到后加
"server_ts": 1747836305123），用于本地排序和冲突提示
真正难的不是画线，是让几十人同时动笔时不互相覆盖、不丢动作、不卡顿。Workerman 提供了可靠的连接层，但同步语义（谁该看到什么、按什么顺序）必须由你定义清楚，不能交给框架猜。
