企业官网建设流程全解析

简介：一份基于Unity3D打造的互动投影捕鱼案例，面向互动投影产品测试、AR/VR互动体验与激光雷达应用开发人员。虽然是面向效果验证的非代码版演示包，但完整呈现了捕鱼玩法与投影画面，适合用于互动投影功能验证、手感评估和方案预研。RAR压缩包约26.64MB，详情页未提供文件总数与内部文件类型明细，因此不展开罗列，下载后可直接解压测试。目前已有1739人学习下载，作为互动投影雷达技术的代表性用例，画面清晰且交互反馈直观，适合作为雷达互动选型的对照样本。读者可获得一套可直接体验的Unity3D互动投影捕鱼Demo，重点用于观察激光雷达定位与投影画面的联动效果、检查捕鱼游戏在真实投影场景中的运行表现，适合在项目选型或技术交流时快速上手验证。

1. 互动投影捕鱼：为什么激光雷达方案比摄像头方案多花一倍钱也值得

在商场儿童区做投影捕鱼，最怕的不是鱼画得不好，而是孩子明明踩在鱼身上，鱼没反应，旁边的鱼倒是爆了。这类互动投影用摄像头做人脚检测时，反光地砖、射灯直射、投影画面本身的亮度变化都会让识别结果像看运气。换成激光雷达技术以后，系统只认“扫描平面上有什么”，不认画面内容，天黑天亮对它都一样。这就是 Unity3D 互动投影雷达技术的核心逻辑：雷达负责告诉 Unity 实体位置，Unity 负责把位置变成游戏反馈。这套方案已经跑在很多线下乐园和展厅里，适合集成商、独立开发者和准备自己搭互动展厅的运营方，照着能直接把整套流程落地。

2. 从激光雷达点云到 Unity 世界坐标：标定这一步决定 80% 的体验

互动投影的第一关不是写游戏，而是把“雷达看到的点”变成“Unity 认识的坐标”。很多项目死在半路，都是因为坐标没对齐。后面所有玩法、特效、视频流都是建立在坐标正确的前提上，所以我单独用一章讲透。

2.1 激光雷达还是深度相机：选型决定后面所有坑

做地面互动投影，检测人体的方案主要有三种：普通摄像头、TOF 深度相机、单线激光雷达。普通摄像头在商场环境下受光照影响太大，阴影和投影画面会直接干扰识别，背景一换就要重新调参。TOF 深度相机（类似 Kinect 那类）可以拿到深度图，能区分地面和人体，但它在强光下的深度值会变稀，地面是深色大理石时深度图会出现大片空洞，后期处理成本很高。

单线激光雷达是地面互动投影里最常见的选型。它扫出一个平面，人走进这个平面时，脚踝或身体会切断激光线，被切断的角度和距离数据就是我们要的“目标点”。它的优点是抗光干扰、精度可以做到厘米级、帧率稳定在 20Hz 到 30Hz。缺点是只扫一个平面，安装位置和角度有讲究。

我一般把雷达装在投影区域上方，斜向下扫，让扫描平面恰好贴近地面（离地 10 到 15cm）。这个高度有讲究：低于 10cm，脚尖和地面反光物分不清；高于 15cm，扫描平面切到小腿，一个人的两条腿会被切成两个目标，聚类时容易分裂。如果是墙面互动（人用手拍墙），扫描平面就竖直扫一个平面，原理一样，后面提到的标定流程完全通用。

雷达本身选购时只看三个核心参数：测距半径（至少 5m）、角度分辨率（0.5 度到 1 度）、帧率（20Hz 以上）。很多国产工业级单线雷达都能满足，不需要买多线雷达，多线雷达的数据量对互动游戏来说反而是负担。有人说激光雷达方案比摄像头方案贵一倍，确实，但现场维护成本和误触率降下来的收益更大，这钱花在省心上。

2.2 数据链路：TCP 点云解析与极坐标转笛卡尔

单线雷达的输出格式通常是角度加距离。常见做法是雷达通过 TCP 或串口把一帧数据发出来，帧内容包含包头、起始角度、角分辨率、若干个距离采样点和校验位。不同雷达帧格式差别很大，有的固定 360 个采样点，有的带变长角度区间。核心动作都是同一个：把 (角度, 距离) 对解析出来，再转成笛卡尔坐标。

数据接收有一个谁做都会踩的坑：不能在 Unity 主线程里直接读 Socket。雷达帧率虽然只有 30Hz，但主线程要跑渲染、物理、游戏逻辑，任何网络阻塞都会让画面卡顿。正确做法是开一个后台线程接收原始字节，塞进线程安全队列，主线程每帧只取最新一帧来解析。这样即使主线程偶尔卡一帧，雷达数据也不会丢，只是丢掉中间帧，对交互体验没有影响。

using System.Collections.Concurrent; using System.Threading; using UnityEngine; public class LidarFrameReader : MonoBehaviour { public string host = "192.168.1.100"; public int port = 8089; private ConcurrentQueue<byte[]> frameQueue = new ConcurrentQueue<byte[]>(); private TcpClientWrapper client; void Start() { client = new TcpClientWrapper(host, port); Thread recvThread = new Thread(ReceiveLoop); recvThread.IsBackground = true; recvThread.Start(); } void ReceiveLoop() { // 后台线程只做一件事：读帧、压队列 while (true) { byte[] frame = client.ReadFrame(); // 阻塞读，按包头和长度拆帧 if (frame != null) { if (frameQueue.Count > 2) // 队列积压超过 2 帧，直接清掉旧的 frameQueue.TryDequeue(out _); frameQueue.Enqueue(frame); } } } void Update() { // 主线程只取最新帧，不逐帧累积 if (frameQueue.TryDequeue(out byte[] raw)) { ParseFrame(raw); } } }

这段代码里有三个关键点。第一，接收线程不碰任何 Unity API，连 Mathf 都不要用，否则 Unity 会在非主线程访问时报错或者随机崩溃。第二，队列积压的判断非常关键，如果主线程某帧超时，队列里积了十几帧，逐帧处理会导致延迟越来越大，所以超过 2 帧直接丢旧保新。第三，ReadFrame 是阻塞读，我在 TcpClientWrapper 里做了超时重连处理，这块在第 5 章展开。

帧解析出来之后就是坐标转换。雷达给的是极坐标，先转雷达本地笛卡尔坐标，再过一遍标定矩阵，变成 Unity 世界坐标。

Vector2 PolarToWorld(float angleDeg, float distanceMeter) { float rad = angleDeg * Mathf.Deg2Rad; Vector2 radarLocal = new Vector2( distanceMeter * Mathf.Cos(rad), distanceMeter * Mathf.Sin(rad) ); return calibrationMatrix.Transform(radarLocal); // 单应矩阵映射 }

distanceMeter 一般是从雷达数据里读出的毫米值除以 1000，注意别在循环里做除法，先把系数算好。calibrationMatrix 就是下一节要算的东西。坐标转换完成后，做一次矩形范围过滤，只保留投影区域内的点，投影区外的行人、货架、玻璃反光都会被挡在外面，这一步能过滤掉一大半干扰。

2.3 四点标定：从雷达坐标到 Unity 世界坐标的桥

标定是整个项目里最玄学也最重要的环节。原理不复杂：雷达有自己的坐标系，投影画面有 Unity 的世界坐标系，两者之间是一个透视变换关系。因为雷达和投影机安装位置不可能完全重合，地面的投影区在雷达视角里通常是个梯形，不能简单用平移加缩放解决。

最通用的做法是四点标定。在投影区域取四个角点，让雷达扫出这四个点在雷达坐标系下的坐标，同时记录这四个点在 Unity 世界坐标系下的目标坐标，然后解一个单应矩阵（Homography）。单应矩阵是一个 3x3 矩阵，可以把雷达坐标映射到 Unity 世界坐标，它能表达平移、旋转、缩放，也能表达透视形变。如果你是从 SolidWorks 出的场地 CAD 模型导入 Unity 做点位规划，标定矩阵算的是屏幕平面到 Unity XZ 平面的映射，模型的 Y 轴朝向和单位必须一致，否则地面上所有目标都会偏一个角度。

public class PerspectiveTransform { private float[,] matrix = new float[3, 3]; private Vector2[] source = new Vector2[4]; // 雷达坐标: 依次为左下、右下、右上、左上 private Vector2[] target = new Vector2[4]; // Unity 世界坐标，必须同一顺序 public void ComputeMatrix() { float[,] A = new float[8, 8]; float[] b = new float[8]; for (int i = 0; i < 4; i++) { float x = source[i].x, y = source[i].y; float u = target[i].x, v = target[i].y; A[i * 2, 0] = x; A[i * 2, 1] = y; A[i * 2, 2] = 1; A[i * 2, 6] = -u * x; A[i * 2, 7] = -u * y; A[i * 2 + 1, 3] = x; A[i * 2 + 1, 4] = y; A[i * 2 + 1, 5] = 1; A[i * 2 + 1, 6] = -v * x; A[i * 2 + 1, 7] = -v * y; b[i * 2] = u; b[i * 2 + 1] = v; } float[] h = GaussianEliminate(A, b, 8); for (int k = 0; k < 8; k++) matrix[k / 3, k % 3] = h[k]; matrix[2, 2] = 1f; } public Vector2 Transform(Vector2 p) { float w = matrix[2, 0] * p.x + matrix[2, 1] * p.y + 1f; return new Vector2( (matrix[0, 0] * p.x + matrix[0, 1] * p.y + matrix[0, 2]) / w, (matrix[1, 0] * p.x + matrix[1, 1] * p.y + matrix[1, 2]) / w ); } }

高斯消元部分我直接用的标准列主元消元法，如果项目里已经引用了 MathNet.Numerics 或者 Accord.Math，可以直接换成现成的 GaussianElimination 求解，结果一样。这个类的核心是把 8 个未知数解出来，得到单应矩阵 H。Transform 方法里最后那个除以 w 是透视变换的关键，w 等于 1 时就是仿射变换，w 不等于 1 时会产生近大远小的形变效果，正好补偿雷达和投影机不平行的问题。

标定操作时，我会先投影一个标定画面，画面上显示四个角点标记。然后人站在角点标记上，用雷达调试工具读取当前目标点坐标，连续读 5 帧取平均值，减少手持读数误差。四个点都记完后，按同一个顺序填入上面的 source 数组，target 数组填投影画面四个角点在 Unity 世界坐标里的值。这里最容易出的错是顺序不一致，雷达坐标的枚举顺序必须和 Unity 世界坐标完全一致，否则矩阵算出来是个镜像，鱼的位置左右对调，踩左鱼炸右鱼。

2.4 坐标平滑：单点抖动会毁掉整个手感

标定做完后还有一个不可省的步骤：坐标平滑。雷达单帧的点云是离散的，人站着不动时，点云质心也会有几厘米的抖动。如果直接用这个坐标去触发鱼群，会出现“没踩到但爆了”的误触感。

我一般用一阶低通滤波（指数平均），alpha 取 0.3 左右，公式是 smoothed = alpha * current + (1 - alpha) * previous。alpha 越大越灵敏但抖动越大，alpha 越小越平滑但会感觉“拖着走”。实际调试时先把 alpha 设 0.3，然后让孩子快速跑动，看脚下光标的反应：如果追不上，降到 0.2；如果站着不动还在抖，升到 0.4。这个参数是手感的分水岭，值得反复调。

更高级的做法是卡尔曼滤波，但对互动投影这种低频场景是杀鸡用牛刀，调协方差矩阵的时间够你把低通滤波调出三个版本来。

3. 捕鱼玩法落地：鱼群游动、触碰判定与视频流接入

坐标系统通了，游戏逻辑才有意义。捕鱼项目看起来简单，真要把“鱼游得自然”“踩得准”“画面不糊”同时做到，里面还是有几个关键决策。这章按鱼群、判定、视频流三个维度拆开讲。

3.1 鱼群系统：路径点加平滑转向，别用 NavMesh

做鱼群游动，有的开发者第一反应是上 NavMesh（导航网格），但这是过度设计。NavMesh 是为带障碍寻路设计的，捕鱼场景里鱼不需要避障，它们要的是“自然感”——缓慢转向、偶尔变速、集群时拉开距离。用 NavMesh 会引入导航网格烘焙的额外工作，鱼游起来反而像机器人。

我用的方案是路径点系统：每条鱼维护一个私有路径点列表，每到一个点就随机选下一个点，位置在水面范围内。鱼本身有游动速度和转向速度，转向用 Quaternion.Slerp 平滑过渡，避免瞬转。

public class FishController : MonoBehaviour { public float swimSpeed = 1.5f; public float turnSpeed = 2.5f; public Vector2 moveRange = new Vector2(10f, 6f); private Vector3 targetPoint; void Start() { PickNewTarget(); } void Update() { Vector3 dir = targetPoint - transform.position; Vector3 flatDir = new Vector3(dir.x, 0f, dir.z); // 接近目标点后立刻换下一个点，不要原地停滞 if (flatDir.magnitude < 0.3f) { PickNewTarget(); return; } transform.position += flatDir.normalized * swimSpeed * Time.deltaTime; if (flatDir.sqrMagnitude > 0.001f && flatDir != Vector3.zero) { Quaternion look = Quaternion.LookRotation(flatDir, Vector3.up); transform.rotation = Quaternion.Slerp(transform.rotation, look, turnSpeed * Time.deltaTime); } } void PickNewTarget() { float x = Random.Range(-moveRange.x, moveRange.x); float z = Random.Range(-moveRange.y, moveRange.y); targetPoint = new Vector3(x, 0f, z); } }

两个细节值得注意。第一，LookRotation 前必须先调用 flatDir.sqrMagnitude 判断一下，否则鱼到达目标点瞬间 dir 为零向量，Quaternion.LookRotation 会报错并打印一条 “Look rotation viewing vector is zero” 的警告，场景里鱼一多控制台会刷屏。第二，pick 新目标后用 return 跳过一次 Update，不要继续执行位置更新，避免鱼因为这个误差在目标点周围来回抖动。

如果你想做一群鱼的整体感，可以给每条鱼一个相对群中心的偏移量，由群中心统一移动，鱼只做局部微调。这样 40 条鱼在投影面上游动时看起来是一个编队在巡游，而不是 40 个独立随机点乱窜，现场视觉效果差异很大。

3.2 触碰判定：别用 Physics 碰撞，直接算距离

很多人习惯用 Unity 的 Collider 做触碰检测，给每条鱼挂 BoxCollider，再给脚部生成一个触发器。这个方案在捕鱼项目里是给自己挖坑：物理引擎每帧要和 UI、动画抢时间，还要处理碰撞矩阵配置；而且投影互动里的“脚”不是连续物体，是一个不断跳动的点云质心，用物理引擎模拟这种离散输入，参数调起来非常痛苦。

触碰判定其实只是多组距离比较。每帧拿到玩家的脚部坐标列表（可能同时有 4 个玩家），对每条鱼算一次水平距离，小于判定半径就触发捕获。50 条鱼最多同时 8 个玩家，一轮最多 400 次距离计算，这个量级连优化都不用做。

public class InteractionManager : MonoBehaviour { public FishController[] fishes; public float touchRadius = 0.35f; void Update() { // 从雷达数据管线拿当前帧所有玩家目标点 List<Vector3> footPositions = LidarPlayerTracker.GetFootPositions(); foreach (Vector3 foot in footPositions) { for (int i = 0; i < fishes.Length; i++) { FishController fish = fishes[i]; if (fish.IsCaptured) continue; float dx = foot.x - fish.transform.position.x; float dz = foot.z - fish.transform.position.z; float distSqr = dx * dx + dz * dz; if (distSqr < touchRadius * touchRadius) { fish.OnCaptured(); } } } } }

用平方距离比较而不是完整开根号，是为了省掉每帧几百次 Mathf.Sqrt 调用，虽然这个量级无所谓，但养成这个习惯没坏处。touchRadius 的取值直接关系到手感：0.35m 适合脚踩交互，成年人一脚踩下去的直径大概就是这个范围；如果做儿童乐园，孩子的鞋码小，可以缩到 0.3m，太小的孩子踩不准，反而容易挫败。

OnCaptured 里面不要立刻销毁鱼，而是播放一个 0.4 秒的水花动画再隐藏，否则画面会有明显的“瞬移消失感”，玩家会觉得自己踩空了。这是我最早做捕鱼时踩过的坑，鱼直接消失，客户反馈说“没有打中的爽感”。

3.3 背景视频流接入：VideoPlayer 处理外部视频源的坑

捕鱼项目的投影画面通常分为两层：一层是实时渲染的鱼和特效，一层是动态水下背景，背景可能是大屏播控软件推过来的 RTSP 视频流，也可能是本机视频文件。Unity 处理这两种情况都用 VideoPlayer 组件，但有个容易翻车的地方：视频源是 RTSP 流时，VideoPlayer 的 Prepare 流程是异步且依赖网络状态的，直接 Play 经常会黑屏。

using UnityEngine; using UnityEngine.Video; public class BackgroundStream : MonoBehaviour { public VideoPlayer videoPlayer; void Start() { videoPlayer.source = VideoSource.Url; videoPlayer.url = "rtsp://192.168.1.20:554/underwater.mp4"; videoPlayer.isLooping = true; videoPlayer.renderMode = VideoRenderMode.CameraNearPlane; videoPlayer.aspectRatio = VideoAspect.FitHeight; videoPlayer.prepareCompleted += OnPrepared; videoPlayer.errorReceived += OnVideoError; videoPlayer.Prepare(); } void OnPrepared(VideoPlayer vp) { vp.Play(); } void OnVideoError(VideoPlayer vp, string message) { // 播控端没开流或地址写错时会走到这里 Debug.LogError("视频流拉取失败: " + message); } }

videoPlayer.Prepare() 不播，等 prepareCompleted 回调后再 Play，这是视频流接入的第一条纪律。renderMode 用 CameraNearPlane 时注意深度值，必须保证背景视频的摄像机 depth 低于游戏层摄像机，否则视频会把鱼全部盖住。如果播控端用的是 NDI 或者 Spout 推流，Unity 侧没有原生支持，我一般装对应的第三方插件，把视频流当作一个 Texture 接到 Render Material 上，这比用 VideoPlayer 拉 RTSP 更稳，但那属于插件范畴，这里不展开。视频流码率太高时会占用大量解码带宽，现场经常出现“鱼正常动，背景一卡一卡”的问题，码率压到 8 到 12Mbps 基本够用。

3.4 状态控制：空闲、运行、校准三态切换

投影设备不是开了就没人管。现场运营场景里，经常要在一场活动结束后切换到其他内容，或者每天早上开机后做一遍标定校验。我习惯把整个 Unity 工程做成三态：空闲态（播放循环演示动画）、运行态（捕鱼互动）、校准态（显示点云叠加层）。三态之间用状态机控制，切换时通过同一个管理器把所有鱼重置到随机位置。这个设计能让运营方在无人值守的商场里也能远程切换内容，不至于只能靠重启解决一切问题。

4. 参数调优清单：十个关键参数与默认值怎么调

互动投影的“爽”是调出来的。同样的工程，让不同的人去配参数，现场效果可能一个天上一个地下。下面这个表是我在多个项目里积累下来的默认基线，新场地先按这套值跑起来，再根据手感微调。

单说几个容易调错方向的参数。扫描平面离地高度是最容易被忽略的，很多人觉得越低越准，结果 5cm 高度把地砖接缝、口香糖、纸屑全扫出来了，误触率飙升。聚类半径也不是越大越好，0.25m 意味着两个人并肩站时，两簇点之间的距离小于 0.25m 就会合并成一个点，所以人流密度高的时段要把聚类半径降一降。

帧率和延迟要一起看。雷达 30Hz，Unity 渲染 60FPS，数据链路从雷达出点到游戏对象响应，整个闭环最好控制在 150ms 以内。超过 200ms 玩家就会明显感觉到“慢半拍”。从图形性能角度，同屏鱼数量对帧率的影响远小于粒子特效数量，鱼只是移动的网格，但每条鱼被踩时爆出的水花粒子如果做得太豪华，几十个粒子系统同时触发才是掉帧元凶。

标定残差这个指标很多人听过但不会测。我一般在校准态里把每个角点的雷达坐标和理论坐标的欧氏距离直接显示在屏幕上，四个角的偏差都小于 5cm 才算过。如果某个角偏差明显比其他大，不用急着调矩阵，先去看雷达是不是被碰歪了，标定矩阵替雷达背了很多不该背的锅。

5. 常见问题排查：画面漂移、误触、延迟翻车的五个真实案例

这一章写的都是我在现场真实碰到过并且花时间填过的坑。每条按现象、原因、解决三步走，可以直接当排查手册用。

5.1 画面漂移：踩左边鱼，右边鱼爆了

现象：标定做完了，当时测没问题，运营两天后开始出现整体偏移，往某个方向偏了十几厘米，越远离投影中心偏差越大。

原因：雷达安装支架松动或者被保洁撞歪了。标定矩阵没有错，错在雷达的物理位置变了。另一个低频原因是雷达扫描平面和投影平面夹角太大，透视变换的残差被放大，边角区域偏移明显。

解决：先把雷达支架重新上紧，挂一个防撞护栏或者固定结构，别让支架裸露在行人通道旁边。然后重新做四点标定，不要试图用软件补偿物理位移。我在校准态里专门加了一个“偏移检测”开关，开机时用一个标准杆放在投影中心，看画面上的光标和实际位置的偏差，超过 5cm 就提示运营方重新标定，把人为排查成本降到最低。

5.2 频繁误触：没人踩，鱼自己爆

现象：场地空着没人，鱼群在投影区里游着游着就自己爆了，爆得很随机。

原因：两类，一类是雷达扫到了投影区内的杂物，比如落在角落的宣传单页、矿泉水瓶、儿童丢下的玩具；另一类是投影区外的人流经过，目标点的距离过滤没有做好，让范围外的行人点进入了判定逻辑。

解决：第一类问题，把扫描平面往上抬一点，让高度低于大多数直立杂物的反射高度，同时加一个“连续命中帧数”过滤：连续 3 帧距离判定命中才算真正被踩中。单帧误触几乎不可能连续 3 帧都命中同一个静止物体。第二类问题，把距离过滤阈值从投影矩形外扩 0.5m 收紧到外扩 0.2m，并把边缘做 10cm 的缓冲带，缓冲带内的目标只跟踪不触发。做过滤逻辑时留意：滤波器要放在标定矩阵之后、聚类之前，顺序反了效果完全不同。

5.3 延迟明显：脚都踩下去了，鱼 0.5 秒后才爆

现象：点云检测看起来没问题，坐标也对，但鱼的爆炸动作总比脚踩下去慢半拍，玩起来非常不爽。

原因：网络接收线程和主线程同步出了问题。雷达每帧 30Hz，数据到达的间隔约 33ms，如果主线程 Update 里逐帧处理积压队列，且处理过程中有 GC（垃圾回收）卡顿，延迟就会滚雪球。另一个常见原因是用了 Unity 的协程来收网络数据，协程调度在渲染完成后才跑，压力和低帧率时只能排队。

解决：第一，接收线程和主线程之间用 ConcurrentQueue 解耦，并且主线程只取最新帧，不做逐帧消费。第二，把雷达帧解析从 Update 挪到 FixedUpdate 里，保证以固定频率处理，不受渲染帧率波动影响。第三，如果数据管线里还叠加了聚类计算，把聚类结果缓存在成员变量里，不要每帧 new List，GC Alloc 是隐蔽的卡顿来源。我这样改完，延迟从 300ms 以上稳定降到 100ms 以内。

5.4 两个人互踢：A 踩鱼，B 旁边的鱼爆了

现象：两个玩家同时站在投影区内，A 踩左边的鱼，右边 B 脚边的鱼也爆了，或者两人走过之后，鱼在两人交叉位置连续爆。

原因：点云聚类后没有给每个目标分配稳定的身份 ID。当两个人的点簇在交错时，最近邻匹配会把 A 的点簇分给 B，导致 A 的脚实际出现在了 B 的坐标上。这是多人互动里最隐蔽的坑，单人测试永远测不出来。

解决：引入跨帧目标跟踪。对上一帧的每个目标 ID，预测它这一帧的位置（默认静止，运动快时加一个速度外推），然后找当前帧点簇中离预测位置最近的作为同一个人的新位置。同时限制单帧最大位移，超过 0.6m 就判定为旧目标消失、新目标出现，重新分配 ID。做了这个之后，即使两人交叉穿行，目标 ID 也不会互换，互踢问题基本消失。

5.5 运行半小时雷达掉线，画面全部冻结

现象：开机前 20 分钟一切正常，半小时后鱼群全部停在原地，控制台日志显示 Socket 异常，重启程序才恢复。

原因：TCP 连接被中间设备切断，但接收线程没有重连逻辑，一直阻塞在 Read 上；还有一个常见原因是雷达数据帧队列只进不出，内存持续增长，最终卡死了处理线程。

解决：接收线程对 ReadFrame 设置超时（一般 3 秒），超时主动断开重连，重连失败则等待 2 秒再试。队列长度超过 2 帧就主动清空，只保留最新帧，这样即使断连重连期间积压了大量旧数据，也不会让延迟膨胀。监控方面，我在调试界面常驻显示“最近一次心跳时间戳”，超过 5 秒没更新就黄灯告警，现场运维不用等玩家骂街才知道掉线了。

6. 从测试场景到现场部署：三层验收清单与一个调试技巧

最后这层，是你在办公室里测不出问题、一到现场就翻车的分水岭。我自己的项目上线前，最差的经历是压测只做了 40 分钟，结果现场开业第三个小时雷达掉线，顾客在投影区前站了一圈，场面非常尴尬。从那以后我每次接新场地都强制走一遍三层验收，特别是稳定性那一层。

第一层是标定验收。四个角点残差全部小于 5cm，并且在投影中心的十字对准测试偏差不超过 3cm。验收动作是把标定矩阵写死之后，用一根 1 米的标准杆在投影区四个角各放一次，看画面上光标和实际杆尖的偏差。只看软件显示不够，一定用物理物体实地验证。

第二层是响应延迟验收。用手机慢动作模式（240fps）录一段踩鱼视频，逐帧数从脚落地到鱼爆炸的帧数。按 240 帧每秒算，150ms 大约是 36 帧，超过这个数就继续优化。别凭感觉测，手感和数据之间往往有主观偏差。

第三层是稳定验收。跑一套定时补间脚本，每隔 10 秒投下一个模拟雷达目标点，连续跑 12 小时，记录掉线次数、内存占用曲线和帧率波动。内存曲线持续上涨的话，优先查 List 对象复用，互动投影的 GC 压力比普通游戏大，因为目标点数据每帧都在重建。

最后留下一个小技巧，也是我最想让你带走的：一定要做一个“点云可视化”调试开关。平时游戏运行时把雷达点云以半透明小圆点的形式叠画在投影画面上，能看到玩家脚的实际位置和屏幕上的互动光标是否重合。标定、排查误触、调平滑系数时打开这个开关，验收结束后再关掉。没有这个调试层，前面所有问题排查都会变成盲猜。我后来所有互动项目都强制带这个开关，它救过的现场，比我记住的参数表还多。希望帮到你。

本文还有配套的精品资源，点击获取