三个进度条互相打架：一个被误诊三次的 bug

10/211 浏览综合

2026-10-19

这是整个项目最难查的问题，因为它表现得像三个不同的 bug。

玩家同时靠近资源和节点，按住空格，驯养进度和修复进度会互相打断，其中一个突然归零。

最直接的猜测是目标选择逻辑每帧重选最近的实体，导致焦点来回切。

改成「粘滞锁定」—— 一旦锁定目标，只要它还在交互范围内就绝不换。修完，问题从「频繁打断」变成「偶尔打断」。

有改善，但没解决。这种「变好了但没好」是最容易让人收手的信号。

接着猜是玩家微小的移动导致超出交互半径。

加了 1.35 倍滞回：走出半径只暂停、不清零，只有走得更远才解锁。修完，还是偶尔打断。

主循环里 updateInteract(dt, active) 每帧都调用，松手时 active=false。当时在 else 分支里写了清空三类 target 和 progress。

也就是说，松开空格的瞬间，三套交互的进度全被清零。手指抖一下，几十秒的进度就没了。

玩家体感是「三条交互互相打架」，实际是「松手就全清」。

修法是把「暂停」和「放弃」彻底分开：

同期还改了 UI：原来用 if/else if 只显示一条进度条，剩下两条被顶掉不显示。玩家看到进度条消失，自然判断「被另一条打断了」。

改成三条并列显示、向上堆叠之后，很多「互相打断」的投诉自己就消失了 —— 明明逻辑没变，只是让人看见了真实状态。

这件事的教训写进了项目备忘：松手 ≠ 清零；三套交互的状态必须同时可见。

两天后修节点时发现：进度到 100%，但孢囊不足 4，代码在 if 外面把 progress 清零。于是变成「修到满 → 清零 → 再修 → 再清零」，玩家体感是「永远修不好」。

驯养段一模一样 —— p.tameTarget = null; p.tameProgress = 0; 同样写在 else 外面。孢囊耗尽的玩家会卡在「驯到满 → 清零」的死循环里。

统一改成一条规则：扣款成功才清状态。

失败时把 progress 钳在 1，target 保留，下一帧凑够资源自动完成。提示用 1.2 秒 CD 防刷屏。

现在有断言守着这个行为，包括「补齐资源后下一帧必须完成」。

这类 bug 最麻烦的地方在于它不是崩溃，是慢慢磨掉耐心。玩家不会报「进度被清零了」，只会说「这游戏修不好东西」。