最近整理几个库的性能路径时，又遇到了一个很典型的问题：某段代码在 Benchmark 里快了很多，放进真实工程以后，整体帧时间却几乎没有变化。 原因其实很简单——优化的位置并不是真正的热路径。 开始改代码前，我现在会先确认： 1. 这段逻辑每帧、每秒或者每个请求会执行多少次？ 2. 当前瓶颈来自计算、内存分配、缓存失效，还是 I/O 等待？ 3. 为了减少一点开销，引入的复杂度是否会扩散到整个 API？ 只有这些问题有了数据，后面的优化才不至于变成凭感觉重写。 ## Zero GC 也需要边界 零分配是一种很有价值的目标，但并不是所有地方都应该为了它牺牲接口清晰度。高频网络包解析、PlayerLoop、序列化缓冲区与任务源生命周期值得精打细算；只执行一次的初始化代码则更应该优先保证可读性和正确性。 > 性能工程不是把每一行代码都变快，而是把有限的复杂度放在最值得的位置。 ## 记录比记忆可靠 每次优化最好留下测试环境、输入规模、基线数据与完整结果。硬件、运行时版本和编译配置都会改变结论，一张没有上下文的柱状图很容易误导后来的自己。 下一步准备把这些测试约定整理进 Lumin 系列仓库，让性能回归能够在提交代码时就被发现，而不是等到实际项目出现卡顿才回头排查。