WebSocket不直接处理AR空间锚点，但可高效同步其结构化数据（含ID、姿态、参考系、时间戳等），通过JSON传输并校验更新，结合AR框架实现多端实时协同。
WebSocket 本身不直接处理 AR 空间锚点，但它能高效同步锚点数据——关键在于把 AR 设备（如手机、AR glasses）计算出的锚点坐标、朝向、时间戳等结构化信息，通过 WebSocket 实时广播给房间内其他客户端，再由各端在本地 AR 场景中重建对应锚点。
锚点数据的设计与序列化
空间锚点不是“一个点”，而是带姿态（position + rotation）、参考系（如 world、device、image）、生命周期和唯一 ID 的结构体。建议用轻量 JSON 格式传输：
{
"anchorId": "a_8d2f4e",
"type": "plane",
"pose": {
"position": {"x": 1.2, "y": 0.0, "z": -2.4},
"rotation": {"x": 0, "y": 0.707, "z": 0, "w": 0.707}
},
"referenceSpace": "local-floor",
"timestamp": 1718234567890,
"owner": "user_abc"
}
避免传原始矩阵或二进制 blob；用四元数而非欧拉角防万向节锁；所有坐标统一单位（米）和坐标系约定（如 Y 向上、Z 向前）。
WebSocket 连接与房间管理
前端用 new WebSocket("wss://ar-sync.example.com/room/lobby-001") 连入指定房间。服务端（如 Node.js + ws 库）需维护：
• 每个房间的客户端连接池
• 锚点状态快照（用于新加入者同步）
• 心跳检测与异常断连清理
• 可选：按用户角色区分读写权限（如仅创建者可更新/删除自身锚点）
新用户加入时，服务端应主动推送当前房间全部有效锚点（带 timestamp），避免“看不见已有虚拟物体”问题。
立即学习“前端免费学习笔记（深入）”；
客户端锚点同步与冲突处理
收到锚点消息后，不直接渲染，而是做三步校验：
• 检查 timestamp 是否过期（如 >500ms 视为陈旧）
• 验证 anchorId 是否已存在，若存在且新数据更新（timestamp 更大），则触发更新逻辑
• 对比 owner 和本地设备身份，决定是否接受（例如只同步他人锚点，忽略自己刚发的回显）
AR 框架适配示例（WebXR + Three.js）：
→ 将 pose.position/rotation 转为 Three.js 的 Object3D.position 和 quaternion
→ 使用 XRFrame.getPose(anchorReferenceSpace, viewerSpace) 做跨空间系转换（尤其当发送端与接收端 referenceSpace 不同时）
稳定性与体验优化要点
• 启用 WebSocket 压缩（permessage-deflate）减小 pose 数据体积
• 对高频更新的锚点（如跟随手部的 marker），采用变化阈值过滤（位移 >2cm 或旋转 >5° 才发）
• 客户端本地缓存最近 30 秒锚点历史，网络抖动时插值过渡，避免跳变
• 在 UI 显示同步状态（如 “3 个锚点已就绪”、“等待主锚点对齐…”），降低用户困惑
