Rob Pike 的 5 条编程规则是一套用于性能决策的框架，目标是防止过早优化，并强制推行以测量为驱动的开发流程。
用途 该框架用于在开发者准备进行性能优化时提供判断依据，避免凭直觉改动代码。当用户提出诸如“这个循环看起来慢，我来优化一下”“这里加个缓存”“改用 B 树 / trie / 跳表”“实现自定义分配器”“这个算法是 O(n²)，需要修复”“把它并行化”等请求时，可依据这 5 条规则先行拦截与引导。
5 条规则
- 你无法判断程序会把时间花在哪里。瓶颈出现在令人意外的地方，不要猜测，要证明。
- 先测量。在测量之前不要为了速度调优；即使测量之后，也不要调优，除非某一部分代码压过了其余部分。
- 当 n 较小时，花哨的算法会变慢，而 n 通常都很小。当常数项占主导时，大 O 复杂度并不重要。先应用第 2 条规则。
- 花哨的算法比简单的算法更容易出 bug。使用简单的算法和简单的数据结构。
- 数据结构起决定作用。选对数据结构，算法就会变得不言自明。“用聪明的对象写笨代码。”
使用方式：优化前的检查 第 0 步：检查是否已有测量手段。在问“你测量了吗”之前，先判断当前是否具备测量的条件。在代码库中查找既有测量痕迹：日志（logger 导入、log 调用、结构化日志库）、性能剖析（profiler 导入、基准测试文件、追踪设置）、计时（耗时测量、秒表模式、计时装饰器）、APM/可观测性（指标导出、span、trace context）。如果已有测量手段，可询问：“我在[位置]发现了日志/性能剖析。你是否有具体怀疑较慢的区域，还是我们先看看现有测量结果说明了什么？”如果缺失或稀少，则说明当前没有测量手段能证明时间花在哪里，应先确定怀疑的瓶颈位置并添加测量，再让数据决定，第一步动作是加测量而不是改代码。目标不是指定具体工具，而是确保在任何优化讨论继续之前测量已经存在。
第 1 步：按顺序追问测量问题。“我测量了吗？”如果没有，先测量；任何没有测量数据的优化都是过早优化，可使用项目语言生态中自然的性能剖析工具。“是否有某一部分压过其余部分？”如果没有单一区域占主导，就没有值得优化的东西，分散在许多区域的小改进通常无关紧要。“n 是多少？”如果 n 很小（通常如此），简单的 O(n²) 方案很可能因常数项、缓存行为和实现复杂度而胜过巧妙的 O(n log n) 方案。“这是数据结构问题吗？”在改动算法之前，先考虑换一种数据结构是否能让问题变得简单，正确的结构往往能完全消除对巧妙算法的需求。“新增的复杂度值得吗？”慢 10% 的简单代码几乎总是优于脆弱且难以维护的巧妙代码。
应拦截的反模式 把优化冲动对应到被违反的规则并加以重定向：想“这个循环看起来慢，我来优化”——违反规则 1，应先问是否已做性能剖析，瓶颈可能完全在别处；想“这里加个缓存”——违反规则 2，先测量，这条路径真的主导运行时间吗；想“用 B 树 / trie / 跳表”——违反规则 3，n 是多少，如果很小，排序切片加二分查找就够；想“实现自定义分配器”——违反规则 4，从简单开始，测量，只有数据逼迫时才复杂化；想“算法是 O(n²)，需要修复”——违反规则 3，n 是多少，n=100 的 O(n²) 只需 10 微秒，先测量；想“把它并行化”——违反规则 2，这真的是 CPU 密集吗，测量，往往瓶颈是 I/O。
何时优化是合理的 只有当以下条件全部满足时才继续优化：有测量数据指出具体瓶颈；该瓶颈主导整体运行时间（而不只是 5%–10%）；所提出的修复是解决该已测量问题的最简单改动；改动后会重新测量以确认改进。
适用场景 适用于性能优化决策、代码评审中的优化质疑、性能瓶颈定位讨论，以及需要以测量数据为依据判断是否值得改动的开发场景。
限制 该资料未提供具体编程语言、工具链、安装命令或平台要求等信息，这些内容暂未提供。