Big-O：一眼看穿代码要跑多久
拖动数据量滑块，看 O(1)、O(log n)、O(n)、O(n²) 四条曲线怎么分道扬镳；数据翻十倍，谁不动声色、谁当场爆炸
本页解决的问题
先给结论「Big-O：一眼看穿代码要跑多久」要解决的关键问题是什么？
拖动数据量滑块，看 O(1)、O(log n)、O(n)、O(n²) 四条曲线怎么分道扬镳；数据翻十倍，谁不动声色、谁当场爆炸
让这个结论先证明自己值得留下。 把这一页当成决策工具，而不是需要背下来的定义。把概念连到一个真实任务、一个可观察结果，以及一个能改变你判断的失败上。
写下一个问题：试完这个方法后，你能用什么证据回答它？
结论听起来很完整，却没有检查最关键的假设。
四种常见「套路」的耗时曲线：O(1) 灰（不管多少数据都一步到位）、O(log n) 绿（每次砍一半）、O(n) 蓝（挨个过一遍）、O(n²) 红（每个都要和每个比）。拖动滑块把数据量从 10 拉到 10 万，右侧是按「1 亿次操作/秒」换算的真实耗时。留意：前半段四条线挤在一起——数据小时啥算法都快，这正是 Demo 骗人的原因。
换个更直接的问法：老板说「用户量要翻十倍」，四种套路各自会慢多少？点「×10」按钮，连点三次，看差距怎么滚雪球。
尺子拿到手了，来验一验。三段伪代码，各选一个复杂度。诀窍：别读懂每一行，只看「数据变多时，它要多干多少活」。
「交互一 · 四条曲线分道扬镳」里的算法代价曲线
「四种常见「套路」的耗时曲线： O(1) 灰 （不管多少数据都一步到位）、 O(log n) 绿 （每次砍一半）、 O(n) 蓝 （挨个过一遍）、 O(n²) 红 （每个都要和每个比）。拖动滑块把数据量从 10 拉到 10 万，右侧是按「1 亿次操作/秒」换算的真实耗时。」真正训练的不是背诵步骤，而是识别重复工作：输入变大时，程序到底多做了多少次比较、移动或递归。
先找重复工作，再谈快慢
「换个更直接的问法：老板说「用户量要翻十倍」，四种套路各自会慢多少？点「×10」按钮， 连点三次，看差距怎么滚雪球」可以拆成输入规模、每轮做什么、以及是否能缩小下一轮范围三个问题。Big-O 是描述增长趋势的语言，不是对每台机器的精确计时；常数、内存和真实数据分布也会影响最终结果。
- Big-O 只看趋势 ：它不关心一次跑多快，只关心「数据变多时耗时怎么涨」
- 常数不重要、趋势要命 ：慢 2 倍能忍，随 n² 增长等于判死刑
- 数据小时看不出来 ：四条曲线在 Demo 阶段挤在一起，差距要到数据变多才爆发
别把理论最优当成无条件最优
面对 AI 写出的算法，先用小输入手算一遍，再用逐渐放大的数据做基准测试。这样才能把「尺子拿到手了，来验一验。三段伪代码，各选一个复杂度。」从一句结论变成可检查的性能判断。
从「交互一 · 四条曲线分道扬镳」走到「交互二 · 数据翻十倍会怎样」
「交互一 · 四条曲线分道扬镳」先把问题落在「四种常见「套路」的耗时曲线： O(1) 灰 （不管多少数据都一步到位）、 O(log n) 绿 （每次砍一半）、 O(n) 蓝 （挨个过一遍）、 O(n²) 红 （每个都要和每个比）。拖动滑块把数据量从 10 拉到 10 万，右侧是按「1 亿次操作/秒」换算的真实耗时。 留意：前半段四条线挤在一起——数据小时啥算法都快，这正是 Demo 骗人的原因」上；到了「交互二 · 数据翻十倍会怎样」，讨论继续推进到「换个更直接的问法：老板说「用户量要翻十倍」，四种套路各自会慢多少？点「×10」按钮， 连点三次，看差距怎么滚雪球」。两段连起来，重点就不只是记住一个结论，而是看清它成立所依赖的条件。
把这条判断带到下一个场景
算法题换成真实任务后，先找出重复工作，再问输入规模如何变化，最后用一个小基准验证理论判断。这样不会把复杂度记成脱离场景的标签。
- 「交互一 · 四条曲线分道扬镳」：四种常见「套路」的耗时曲线： O(1) 灰 （不管多少数据都一步到位）、 O(log n) 绿 （每次砍一半）、 O(n) 蓝 （挨个过一遍）、 O(n²) 红 （每个都要和每个比）。拖动滑块把数据量从 10 拉到 10 万，右侧是按「1 亿次操作/秒」换算的真实耗时。 留意：前半段四条线挤在一起——数据小时啥算法都快，这正是 Demo 骗人的原因
- 「交互二 · 数据翻十倍会怎样」：换个更直接的问法：老板说「用户量要翻十倍」，四种套路各自会慢多少？点「×10」按钮， 连点三次，看差距怎么滚雪球
- 「最后的要点」：n² 是大部分卡顿事故的元凶 ：验收代码先找嵌套循环
最后的「最后的要点」把讨论落到「n² 是大部分卡顿事故的元凶 ：验收代码先找嵌套循环」。回看这条线索时，最值得保留的是：当输入、规模或风险改变，哪些判断需要重新做一遍。
✅ 这一课想和你分享的
- Big-O 只看趋势：它不关心一次跑多快，只关心「数据变多时耗时怎么涨」
- 常数不重要、趋势要命：慢 2 倍能忍，随 n² 增长等于判死刑
- 数据小时看不出来：四条曲线在 Demo 阶段挤在一起，差距要到数据变多才爆发
- n² 是大部分卡顿事故的元凶：验收代码先找嵌套循环
我把这篇文章里的一个判断改写成了今天可以验证的小实验。比记住结论更有用的是，知道下一步要观察什么。
读完以后我先回头找它成立的条件，而不是直接把方法搬进项目。这个顺序让后面的取舍清楚很多。
如果把这个判断放到真实工作里，最先需要补的约束是什么？我想知道从阅读到第一次实践之间，哪一步最值得先做。
还没有这篇文章的讨论。