调试与性能：先测量，再优化

持续低帧率、偶发长帧、首次加载等待和输入延迟不是同一种问题。先记录触发场景、操作和持续时间，再用 Godot Profiler 与监视器查看相关指标。Compatibility 是已选底座，不因一个未定位的卡顿就默认切换渲染器。

1. 固定同一场景、分辨率、资源和操作路径。
2. 运行基线，记录异常发生的具体时刻与可能相关动作。
3. 只做一个最小修改，例如停止每帧重复查找节点，或减少一个明确热点的工作量。
4. 重跑同一路径，比较前后；同时检查功能是否退化。
5. 再做决定：保留有效优化，撤回没有证据或增加维护负担的改动。

本次背景没有 CPU、GPU、内存和显存规格，不能保证大型模型或重型插件能运行。方案依赖硬件时再定向确认。编辑器运行、调试构建和正式导出构建可能有不同开销；性能结论应附测试环境和构建类型，而不是用另一台机器的数字替代。

先区分持续慢、偶尔停一下、首次进入房间等待和按键后迟迟没有反馈。它们都可能被叫成卡，但调查入口不同。记录问题发生的场景、操作、持续时间和是否只在第一次出现，再用性能面板对照那个时间点。平均帧率看起来正常，也可能掩盖少数很长的帧；反过来，编辑器里一个瞬间的波动也不一定代表玩家会持续遇到问题。

可以用帧时间建立直觉：如果目标是一秒六十帧，每帧大约只有十六点七毫秒。这个数只是时间预算示例，不是本项目已经确认的性能承诺。重点是观察同一路径是否出现明显超出平常的长帧，并找出它与加载、脚本或渲染活动的联系，而不是只追求一个不断跳动的漂亮帧率数字。

先保存基线条件：同一场景、同一窗口、同一资源、同一操作路线和同一种运行构建。做至少几轮观察，区分第一次加载与后续重复操作。随后只针对一个有证据的热点做修改，例如减少一处每帧重复遍历，再按原路线重跑。不要在修改代码的同时缩小窗口、删掉一半物件，否则无法判断收益来自哪里。

记录结果时写清异常出现次数和大致范围，不只贴一张最好的截图。如果某个修改没有稳定收益，却增加了缓存失效或额外状态管理，就没有理由因为它叫优化而保留。临时日志本身也可能干扰测量，尤其是每帧大量输出；先用必要日志定位问题，再在可控条件下比较性能。测量和功能调试可以交替进行，但不要把两种环境混写成同一证据。

把每帧更新改成事件通知后，可能减少工作量，但也可能漏掉状态变化；缓存资源后，可能减少重复处理，却可能保留不该共享的运行状态。因此每个优化都要补相应功能回归。比如减少交互物扫描后，测试进入、离开和重叠范围；调整场景资源处理后，测试首次进入、再次进入以及错误引用的反馈。

完成报告至少写基线、热点证据、修改、同条件复测和功能边界。如果没有硬件信息或正式导出数据，就明确结论仅适用于当前测试条件，不许诺所有电脑都流畅。Compatibility 是既定渲染底座，遇到未定位的卡顿不应先换渲染器。先解决实际瓶颈，再决定是否有必要采用更复杂的资源管理；一个偶尔调用的短函数通常不值得提前建设庞大缓存系统。