航拍视角下的田野与风力发电机

用一个梗开场的老传统

微软的 Stephen Toub 每年会写一篇超长的 .NET 性能改进清单，这个习惯已经连续了十年。今年的文章用《这就是 Spinal Tap》开场：电影里的吉他手向导演展示他引以为傲的功放，旋钮刻度不终止于 10，而是 11——「别人最多到十，而我可以再响一点」。.NET 11 就是那台功放。

这个梗放在性能工程里其实特别贴切，因为接下来全文的内容，恰恰是反银弹的。

清单里都是些什么

作者自己列了一串：去掉一次边界检查、少发生一次内存分配、少拿一次锁、某个循环比去年少跑几个时钟周期、一个比较被折叠成常量、一个重复检查被提到循环外、两条指令被融合成一条、绕过了一次系统调用、一次数组拷贝交给了 SIMD 指令。

单独拿出任何一条，都很难写成标题——因为没人会因为「少一次边界检查」点开一篇文章。但它们的总和，就是一年之后可测量、可复现的速度提升。用作者的话说，这叫「一遍又一遍地响一点」。

为什么这种活最容易被组织放弃

企业的技术决策往往偏爱大动作：重构、换框架、上微服务、迁云。原因不复杂——大动作有立项、有排期、有汇报材料，做完可以写进季度总结。而「把热路径上的冗余检查摘掉」这种工作，投入产出比虽然极高，却几乎没有可见度。

于是就出现一个尴尬局面：团队一边抱怨性能不行，一边把真正能改善性能的小活当成技术债的边角料。长期主义在这里不是口号，而是有没有把性能当成一项持续预算，而不是一个项目。

给中小团队的三条落地建议

第一，先建基线，再谈优化。没有可复现的基准测试，任何性能讨论都会退化成信仰之争。哪怕只有一个粗糙的脚本，也胜过没有。

第二，把优化额度拆小。每个迭代留出固定比例的时间处理小问题，比攒到年底做一次大扫除有效得多。大扫除会引入回归，小步改动不会。

第三，记录每一次改进。哪怕只是「这个接口 P99 从 40ms 降到 32ms」。这份记录本身就是团队性能文化的载体，也是下次立项时唯一有说服力的证据。

写代码二十年的人会比谁都清楚：让软件变快这件事，从来不是靠一次顿悟，而是靠成百上千次不起眼的收工。