Rob Pike 的 5 条编程规则
规则内容
第一条：你无法预知程序会把时间花在哪里。瓶颈往往出现在出人意料的地方，不要靠猜，要用证据证明。
第二条：先测量。在测量之前不要为速度做调优；即便测了，除非代码中某一部分的开销压过其余所有部分，否则也不要调优。
第三条：花哨的算法在 n 很小时是慢的，而 n 通常都很小。当常数项占主导时，大 O 记号并不重要。先应用第二条规则。
第四条：花哨的算法比简单的算法更容易出 bug。使用简单的算法和简单的数据结构。
第五条：数据占主导地位。选对了数据结构，算法就会变得不言自明。“写使用聪明对象的笨代码。”
如何应用
在任何优化之前
第 0 步：检查是否已有埋点
在问“你测量过了吗”之前，先判断当前是否具备测量的条件。
扫描代码库中已有埋点的迹象：
日志：查找 logger 的导入、log 调用、结构化日志库
性能剖析：查找 profiler 的导入、基准测试文件、追踪设置
计时：查找耗时测量、秒表模式、计时装饰器
APM/可观测性：查找指标导出、span、trace 上下文
然后询问用户：
若已有埋点：“我在 [位置] 发现了日志/性能剖析。你是否有具体怀疑较慢的区域，还是我们先看看已有测量结果告诉了我们什么？”
若埋点缺失或很少：“目前没有任何测量手段能证明时间花在哪里。在优化任何东西之前——你怀疑瓶颈在哪里？我们先在那里加上测量，然后让数据来决定。”
目标不是规定使用某个具体工具，而是确保在任何优化讨论继续之前，测量已经存在。如果没有任何可用于测量的东西，第一步动作是添加埋点，而不是改代码。
第 1 步：提出测量问题
停下来，按顺序问这些问题：
“我测量过了吗？”——如果没有，先测量。任何没有测量数据的优化都是过早优化。使用项目所用语言和生态中最自然的性能剖析工具。
“是否有一个部分压过了其余部分？”——如果没有哪个区域占主导，就没有什么值得优化。分散在众多区域的微小改进通常无足轻重。
“n 是多少？”——如果 n 很小（通常都很小），简单的 O(n²) 方案很可能因为常数项、缓存行为和实现复杂度而胜过巧妙的 O(n log n) 方案。
“这是数据结构问题吗？”——在改算法之前，先考虑换一个数据结构是否就能让问题变得平凡。正确的结构往往能完全消除对巧妙算法的需求。
“新增的复杂度值得吗？”——慢 10% 的简单代码，几乎总是优于脆弱且难以维护的聪明代码。
需要拦截的反模式
当你发现自己在做或用户在做以下任何一项时，停下来并重新引导：
冲动 → 违反的规则 → 应对话术
“这个循环看起来慢，我来优化一下” → 第一条 → 你做过性能剖析吗？瓶颈可能完全在别处。
“我在这里加个缓存” → 第二条 → 先测量。这条路径真的占用了大部分运行时间吗？
“我来用 B 树 / 字典树 / 跳表” → 第三条 → n 是多少？如果很小，有序切片加二分查找就够了。
“我来实现一个自定义分配器” → 第四条 → 从简单开始。先测量。只有数据逼着你时才上复杂方案。
“这个算法是 O(n²)，需要修” → 第三条 → n 是多少？n=100 时 O(n²) 是 10 微秒。先测量。
“我来把它并行化” → 第二条 → 这真的是 CPU 密集型吗？测量。通常瓶颈在 I/O。
何时优化才是合理的
只有当以下条件全部成立时，才继续做优化：
你有测量数据指出某个具体瓶颈
该瓶颈在整体运行时间中占主导地位（而不只是 5-10%）
所提出的修改是能解决该已测量问题的最简单改动
你会在改动后重新测量以确认改进