你游戏的平均帧率没问题，玩起来却还是很卡。这个矛盾就是整个案例。HORDEFALL 玩起来感觉卡，尤其是在菜单里，而平均 FPS 看着却很健康。开发者只有在不再相信平均值、逐帧记录之后，才找到真正的问题。那些卡顿根本不是慢帧，而是一次次最长四秒的停顿，藏在一个看着不错的平均值里。
快速信息
来源：HORDEFALL 开发日志第 1 篇《追查随机卡顿》，2026年10月24日发表于 itch.io。本文关于该游戏的事实均出自这篇日志，数字均为开发者自报的测试结果，不是独立复现的测量。
游戏：HORDEFALL，three.js 与 Electron 做的 Windows 平台 3D 俯瞰僵尸潮射击游戏，日志发表时刚进入抢先体验。
症状：游戏感觉卡，尤其是在菜单里，尽管平均 FPS 没问题。逐帧记录后发现，问题是一次次 0.3 到 4 秒的停顿。
本文不声称的内容：不写测试硬件、显卡、系统版本或 three.js、Electron、Chromium 版本，不写价格，也不拆分每个单项修复各贡献了多少改善。日志里都没有这些。
最后核实：2026年10月31日。
平均值用真话撒了谎
平均值是一种概括，而概括天生就会藏起异常值。如果大多数帧跑得很快，只有少数帧卡住几秒，平均值仍然可能看着不错，因为快速的大多数压过了卡住的少数。这正是这篇日志里的陷阱。开发者逐帧记录了全部帧，外加 CPU 与 GPU 使用情况，画面就完全变了。问题根本不是慢帧，而是一次次 0.3 到 4 秒的停顿，菜单里最严重，因为那时没有别的动态能掩盖每一次卡顿。
按开发者的说法，原因是 Windows 上首次使用的着色器编译。Chromium 经 ANGLE 走 D3D11 绘制，每种新效果在第一次出现时都需要现建一个 GPU 着色器，菜单里的每种 CSS 模糊尺寸、渐变、遮罩与混合模式，以及每个 three.js 材质，都在其中。每次编译都会让 GPU 停顿最多一秒。开发者还说，Electron 在退出时会丢掉这份着色器缓存，所以首次启动的代价每次都会回来。缓存这一点是开发者在日志里自己的说法，本文把它作为他的解释来转述，而不是作为独立核实的 Chromium 行为。
四项修复，全都针对第一次出现
原因一旦点明，每项修复都遵循同一个思路：把首次使用的代价付在玩家感觉不到的地方，而不是付在游玩正中间。启动时，在加载画面后面，开发者把每种昂贵的 CSS 效果都在微小、几乎看不见的 div 上各画一次，358 种效果约 1.3 秒，这样在打开任何菜单之前着色器就已经存在。Boss 改为在 WARNING 画面期间于后台隐藏构建并编译，而不是在它第一次出现的那一帧。自动画质不再在战斗中途切换，只在卡牌、商店或暂停界面切换，因为一次画质切换会重新编译全部受光材质。菜单与 HUD 的 2D 画布则移到了 CPU 上，根本不需要 GPU 着色器。
在开发者自己的 400 只僵尸加 Boss 测试里，总卡顿时间从 55 秒降到 3 秒，尸潮战斗从 11 FPS 升到 80 FPS，首次启动的菜单卡顿大约减半。请带着标签读这些数字：它们是一位开发者自报的测试，四项修复是一起上的，日志没有说每项单独贡献了多少，也没有说用的是什么硬件。真正有用的不是精确的倍数，而是结果的形态：一款平均值看着不错的游戏，在把首次使用成本移出游玩过程后，变得明显顺滑得多，而这正是逐帧记录所预言的。
能复用的部分
下面的步骤不是 HORDEFALL 开发者在已述四项修复之外做过的事，而是把这些修复推广到你自己项目的清单，全部只停留在你自己的项目里。能复用的习惯是测量分布，而不只是平均值：卡顿的游戏与慢的游戏需要不同的修复，只有逐帧记录能告诉你你面对的是哪一种。如果你的游戏感觉卡而平均值看着不错，不要一上来就全面降画质，先找到最差的那些帧。
周一早上照着做
在你自己的项目里，对一次测试全程逐帧记录，而不只是记平均 FPS。先看最差的帧与最长的停顿，分布本身就是诊断。
检查你自己最差的停顿是不是发生在第一次出现时：新的菜单效果、新的材质、新的敌人类型。首次使用成本总是聚集在第一次出现的地方。
像这篇日志那样，把你自己昂贵的效果放在加载画面后面预热，并量一下预热时间，让它始终是加载成本，而不是游玩成本。
把你自己重量级的敌人或 Boss 在第一次出现之前就构建并编译好，放在玩家本来就预期要等的画面上，而不是放在它第一次露面的那一帧。
绝不要在你自己的游戏里战斗中途自动切换画质。把画质切换移到安全的界面上，让重新编译无法打断游玩。
对你自己的菜单与 HUD，逐项问一句：这块 2D 内容真的需要 GPU 吗？把廉价的 2D 工作移到 CPU 上，就能去掉一整类首次使用停顿。