依据所列项目文档编写，核对日期为 2026-10-31。请匹配实际版本、加载器和构建；命令为文档示例，本文不声称进行过托管商性能实测。
01 在问题发生时采样
spark 应在实际卡顿时采样。午夜空服报告无法证明晚间繁忙基地为何停顿。记录服务端构建、在线人数、具体活动、发生时间，以及客户端是否也有低帧率。
Paper profiling docs / Paper 文档 ↗ 说明从 1.21 起内置 spark。其他平台应选兼容的模组或插件，不能把 Paper 插件放到任意加载器。先核对是否已提供，再决定安装；spark mod 与 spark plugin 是部署形态，不是两种独立修复。
02 采集有明确时长的报告
兼容 Paper 环境的文档示例为：
/spark profiler start --timeout 600采集十分钟后返回报告链接，期间复现正常负载。控制台若要求无斜杠命令，则去掉开头斜杠。保存报告时附负载记录，不只发一个毫无背景的链接。
公开前检查报告内容，可能暴露插件名称、路径或运维资料。向相关维护者或支持人员提供脱敏信息，不因“完整诊断”要求附上账户密码。这是文档示例，不表示我们已在你的游戏服做过跑分。
03 解释报告，不凭最大标签直接归罪
| 观察结果 | 下一步 |
|---|---|
| 探索新地形时成本增加 | 比较已生成路线，考虑有限预生成。 |
| 已发展基地反复高耗时 | 复现同样实体、机器或插件操作。 |
| 内存压力与垃圾回收一起升高 | 检查分配与负载，不凭一个大堆数值断言泄漏。 |
| 只有一名玩家低帧率 | 单独检查客户端画面链路。 |
调用栈中的方法可能被别处调用，大分类本身不能证明某插件有缺陷。带报告和复现说明联系作者，不要一次删多个组件。每次只改一项，再用相同负载采集。
04 让修复匹配瓶颈
Chunky 处理提前生成地形，不能代替繁忙基地的性能分析；Shader checks / 光影排查 针对另一类客户端负载。真正内存不足时扩容可能有效，但不会自动减少慢 tick 的工作量。
前后记录应使用相同游戏构建、负载时长和主要设置。一次改多项时，不能声称已分离某个原因。无效改动应回退，不积累来历不明的“优化”参数。