正文开始

1. 算法复杂度到底在算什么——先建立直觉

1.1 数学定义与“运行时间”的真实含义

前阵子帮一个朋友复盘面试题，他卡在一道“求这个递归的时间复杂度”上，折腾了半天也没算明白。其实这种问题我在实际开发里也常遇到，尤其是定位线上接口为什么突然变慢、或者写了一段循环嵌套被同事吐槽“能不能别整O(n²)”的时候。很多人一听到“算法复杂度”就头皮发麻，觉得是数学题，但实际上它就是一把尺子，量的是：当输入规模变大时，你的程序需要付出的时间或空间成本，会以什么速度增长。

这里必须先澄清一个很多人搞混的点：复杂度衡量的不是“运行多少毫秒”，而是“运行次数随输入规模增长的趋势”。同一段代码，在2.5GHz的机器上跑和在老破小的嵌入式板子上跑，耗时能差出几十倍，但它的算法复杂度不会变。我们关心的是抽象的“代价”，而不是墙上的时钟。

数学上的定义也不复杂，但要理解到位。假设输入规模是n，算法执行的基本操作次数记为T(n)。算法复杂度研究的不是T(n)在某一个n下到底是多少，而是当n趋于无穷大时，T(n)的增长趋势。比如：

• T(n) = 3n + 5，当n翻倍时，T(n)也大约翻倍。
• T(n) = 2n² + 3n + 1，当n翻倍时，T(n)大约变成原来的4倍。
• T(n) = n!，当n从10变成11，结果直接翻11倍。

显然，这三种T(n)的增长速度天差地别。我们用大O记号（Big O notation）把这三种趋势分别记作O(n)、O(n²)和O(n!)，这就是“算法复杂度”的核心内容。后面所有复杂的计算，本质上都是在回答一个问题：这个T(n)到底是什么形式，最终会被哪一项主导？

1.2 大O、Θ、Ω三种符号的区别与使用场景

严格来说，算法复杂度记号不只是大O一个，还有Θ和Ω。我见过很多程序员把所有情况都叫“大O”，虽然日常沟通够用，但真的在推导复杂算法或者面试被追问的时候，混淆这三个符号会直接翻车。简单捋一下：

• 大O（渐进上界）：表示算法在最坏情况下的增长率上界。比如你说“这个算法是O(n²)”，意味着不管怎么跑，它的操作次数不会超过n²的某个常数倍。
• Ω（渐进下界）：表示最好情况下的增长率下界。你写一个线性遍历，最乐观的情况第一个元素就命中，那它是Ω(1)，但没人会拿这个说事。
• Θ（渐进紧界）：表示上下界压同一个数量级，即算法的最优和最差增长率一致。比如双重循环遍历矩阵，不管输入怎么排列，都是n²次操作，这就是Θ(n²)。

那问题来了，为什么实际工作和面试里大家都在说大O？原因很简单：我们最关心的是性能底线，也就是“这代码再怎么差也不会差到哪去”。大O描述的就是这条底线，它能把最坏情况直接暴露出来。比如哈希表的平均查询是O(1)，但碰上哈希冲突极端场景，最坏能退化到O(n)，如果你只关心平均表现，线上就可能被这个“最坏”打爆。

不过我要提醒一点：面试官问“这个算法的复杂度是多少”，他真正想要的答案往往是一个紧界Θ，而不是宽松的大O。比如有人回答说“快速排序是O(n²)”，严格来说没错（因为大O就是上界，最坏情况确实是n²），但这显然不是面试官期望的答案。他期望你说的其实是“平均情况是Θ(n log n)，最坏情况是Θ(n²)”。所以我建议你学习的重点放在怎么算出一个紧的复杂度上，大O作为一个沟通语言的包袱反而没那么重。

2. 手把手算复杂度的基本套路

2.1 基本语句计数法：从一行的复杂度开始

很多人一上来就背结论：冒泡排序O(n²)、快排O(n log n)、二分查找O(log n)。背结论当然轻松，但题目稍微变个形，比如来个变种的分治、嵌套条件混合循环，立刻就不会了。我自己的经验是，真正吃透复杂度计算，必须回到最底层那些“一看就知道复杂度的操作”上，然后再做组合和累加。这一节先把地基打好。

首先，单个基本操作的时间复杂度是O(1)，意思是它不随输入规模变化。比如：

这几行每条语句都是O(1)。这里要特别说明“基本操作”的范围：通常包括算术运算、赋值、比较、数组按下标访问、对象字段访问、函数返回等。它们的执行时间只跟CPU指令数有关，跟输入数据量无关。这就像你去商店买一瓶水，不管今天商店里有多少顾客在排队，拿一瓶水本身花的时间就是固定的。

但有个最常见的坑：方法调用的复杂度取决于被调用方法内部做了什么。很多人看到一行arr.sort()就直接忽略，这大错特错。比如Java的Arrays.sort()，对基本类型数组是dual-pivot quicksort，平均O(n log n)；对对象数组是TimSort，最坏也是O(n log n)。你要是把这一行当成O(1)，整个算法分析全盘皆输。

还有更隐蔽的：字符串拼接。Java里直接str += c在循环中反复执行，由于String是不可变的，每次拼接都会新建一个对象并拷贝旧字符串，单次拼接其实要O(len)的时间，循环n次就是O(n²)。而使用StringBuilder.append()，大多数情况下append是摊还O(1)，整体就是O(n)。这个“看起来像O(1)、实际上不是”的细节，是复杂度计算里最容易翻车的地方之一。类似的还有动态数组扩容、substring在不同语言里实现不同（Java 7+是拷贝O(len)，早期是共享数组O(1)），分析前必须清楚语言底层行为。

2.2 循环结构的三种类型：单循环、嵌套循环、对数循环

有了单元操作的基础，接下来就是循环。绝大多数复杂度计算都落在循环的“迭代次数”上，所以循环结构是重中之重。我把常遇到的循环分成三类，分别说。

2.2.1 单循环：迭代次数直接决定复杂度

最常见的单循环，比如累加、遍历数组，循环体是O(1)，迭代n次，那么总复杂度是n × O(1) = O(n)。这种大家都能理解。但不常被注意的是：如果循环体内不是O(1)，而是O(i)或者O(n-i)这种随迭代次数变化的操作，总数就不能简单相乘了，而是要求和。

比如这段代码：

内层循环每次迭代次数分别是0、1、2、…、n-1，总和是0+1+2+…+(n-1) = n(n-1)/2，所以整体复杂度是O(n²)。这种“1到n求和”的套路，在算很多嵌套循环里都是核心方法，会了以后一眼就能看出来，根本不用逐个跑。

2.2.2 嵌套循环：乘法原理

两层循环各跑n次，内层是O(1)，复杂度就是n×n = O(n²)。三层循环就是O(n³)。这听着简单，但套上条件判断后很多人就懵了。比如：

内层循环从i+1开始，那么总迭代次数是(n-1) + (n-2) + … + 1 = n(n-1)/2，复杂度为O(n²)。这种“去掉一半”的写法仍然是O(n²)，只是常数系数小了一半，但渐进上界不变。很多人到这里会问：“那到底什么时候看系数？”短答案是大O里不看系数，但在实际工程优化里系数很重要。比如n的规模很小的时候，O(n²)带小系数的实现可能比O(n log n)带大系数的实现更快，这属于工程权衡，复杂度分析反而要往后放。

2.2.3 对数循环：变量的增减规律

第三种是迭代变量不是+1，而是翻倍或者减半，典型的是二分查找里：

每次循环区间长度减半，那么执行次数k满足：n经过k次减半后变成1，即n / 2^k = 1，解得k = log₂n。这就是O(log n)的来源。记住这个推导过程很关键，因为很多人只会背“二分查找是log”，一旦遇到尝试从右往左扫描但跳跃步长递增的题目就不会算了。其实思路一样：找变量在每轮变化的比例，设执行k次后到达终止条件，解出k关于n的表达式。

比如另一种常见写法：

i的变化是1、2、4、8、…，经过k次后i = 2^k。当2^k ≥ n时循环结束，所以k ≈ log₂n，复杂度O(log n)。这种“变量翻倍”和对数复杂度是一对好兄弟，见到i *= 2就直接想到log。

2.3 递归复杂度计算：递推方程与主定理

循环结构的复杂度相对容易看出来，递归就麻烦得多。因为递归没有明显的“循环次数”可数，它的代价分散在每一层调用里。算递归复杂度最通用的办法是把T(n)写成递推方程，然后求解。这一节我把它掰开揉碎。

先说最简单的递推：线性递归。比如阶乘：

设T(n)为计算factorial(n)的时间。基准情形T(0) = O(1)。对于n > 0，它做一次乘法（O(1)）再加上一次规模为n-1的递归调用，所以T(n) = T(n-1) + O(1)。展开得到T(n) = T(n-2) + 2O(1) = … = T(0) + n·O(1) = O(n)。这类“每层工作都是常数，但调用链深度为n”的递归，复杂度一般是O(n)。

再看减半递归，典型是二叉树的前序遍历或者归并排序的递归框架：

设T(n)是数组长度为n时的排序时间。基准情形T(1) = O(1)。递归部分产生两个规模为n/2的子问题，加上合并操作O(n)，所以递推方程是T(n) = 2T(n/2) + O(n)。这一串代入展开的过程，我建议大家亲手写一遍：T(n) = 2·(2T(n/4) + O(n/2)) + O(n) = 4T(n/4) + 2O(n)，继续推到第k层，得到T(n) = 2^k·T(n/2^k) + k·O(n)。当n/2^k = 1，即k = log₂n时，T(n) = n·T(1) + n·log₂n = O(n log n)。

这就是主定理（Master Theorem）在常见场景下的直观体现。主定理其实是一个求解形如T(n) = aT(n/b) + f(n)递推方程的公式表，但很多人背公式背得一塌糊涂，不如理解“每一层有多少个节点、每层的工作量是多少、共有多少层”这个递归树法。递归树法的核心是：先画出递归调用形成的树，统计每层的工作量，再把所有层的工作量加总。树的层数通常等于log_b n（如果每次除以b），每层节点数等于a^k，每层总工作量 = 节点数 × 该节点内部工作。把所有层加总后取主导项，就是最终复杂度。

再比如斐波那契数列的朴素递归：

递推方程是T(n) = T(n-1) + T(n-2) + O(1)。直觉上它每层会产生两个子问题，是一个接近满二叉树的递归树，节点数大概是O(2^n)的量级，所以复杂度是指数级的O(2^n)。这个结论大家在面试里经常听到，但真正理解“为什么是指数”的人不多：因为每次递归都分裂成两个，树的高度是n，节点数以2的幂增长，所以总节点数是指数级。实际跑fib(50)就能明显感觉到卡顿，而改成带记忆化的动态规划就能降到O(n)，这个差距就是指数和线性之间的鸿沟。

3. 真实算法的复杂度推导——从案例分析中学方法

3.1 二分查找：log底数、区间减法与循环不变式

二分查找算是最经典的O(log n)案例。前面推导过一次循环版本，这里我想再补充几个“看起来像二分、实际不是”的边界，帮你把这类题彻底吃透。

首先，二分查找log的底数真的是2吗？ 严格来说，迭代次数是⌊log₂n⌋+1，底确实是2。但在大O记号里，log₂n和log₃n只差一个常数倍数（换底公式：logₐn = log_b n / log_b a），所以大O里log的底数没有意义，统一写O(log n)就行。这个点很多人纠结，我直接帮你们断了这个念想：以后看到log都不必纠结底数，因为常数倍会被大O吸收掉。

其次，二分查找的一个重要变形是“在有序数组中寻找第一个不小于目标值的位置”，也就是lower_bound。它的循环不变式是：答案一定在区间[low, high]内。每次取mid = (low + high) / 2，根据arr[mid]与target的大小关系排除一半区间。维护这个不变式的方法，和普通二分“找到就结束”不一样，必须保证区间最后收敛到边界上。很多人写lower_bound翻车，就是没想清楚循环退出条件到底该是low < high还是low <= high，以及mid到底向哪边偏。我个人的习惯是：如果是在闭区间[low, high]内找第一个不小于target的位置，循环条件写while (low < high)，mid取(low + high) / 2（整数除法自动向下取整），当arr[mid] < target时low = mid + 1，否则high = mid。这样循环结束后low就是答案。这个模板的复杂度自然还是O(log n)，不用因为写法变了就慌。

最后，二分查找的复杂度会不会因为数据分布而变差？ 不会。不管数据是均匀分布还是集中在某一段，每次比较之后区间都至少缩小一半，所以永远是对数级。这一点和二叉搜索树不同——二叉搜索树如果插入顺序不当会退化成链表，搜索变成O(n)；二分查找则没有这个烦恼，因为它的“树”是固定每次取中点，天然平衡。

3.2 排序算法的复杂度对比：快排“期望”这个词为什么关键

排序是算法复杂度最热闹的战场。这里我从计算复杂度的方法论角度，把主流排序算法挨个串一遍，重点讲清楚“为什么是那个复杂度”，而不是贴一张结论表让你背。

冒泡排序和选择排序：都是两层循环各跑n次，内层是常数操作，所以是O(n²)，这没什么悬念。冒泡有个小优化——如果某一轮没有发生交换就提前退出，最好情况（输入已经有序）能降到O(n)。选择排序无论输入如何，都必须扫描完剩下的元素，所以最好、最坏、平均都是Θ(n²)。

插入排序：它的复杂度取决于逆序对的数量。最好情况（已有序）每个新元素只比较一次就放好，是O(n)；最坏情况（完全逆序）每个新元素都要和前面所有元素比较并搬移，是O(n²)。平均也是O(n²)。这个“对输入敏感”的特性，让它特别适合小规模或者“基本有序”的数据——这也是工程里TimSort会把插入排序作为小片段排序手段的原因。

快速排序：很多人会背“快排平均O(n log n)，最坏O(n²)”，但我想稍微深入一层：为什么快排的平均复杂度是O(n log n)？关键在于每次partition后，划分位置的不确定性。如果每次partition恰好把数组分成两半，递推方程就是T(n)=2T(n/2)+O(n)，解得O(n log n)。如果每次划分极度不平衡，比如数组本身有序且pivot选第一个元素，一遍partition之后左边为空、右边剩n-1个，递推方程变成T(n)=T(n-1)+O(n)，解得O(n²)。但为什么概率上“平均”能达到O(n log n)？ 这是因为即使partition不是正好五五分，只要划分比例是常数比（比如1:9），递推方程T(n)=T(n/10)+T(9n/10)+O(n)的解仍然是O(n log n)。而绝大多数随机情况下，分区不会每次都歪到极端。工程实现进一步用随机pivot和三数取中法把最坏概率压到极低，所以快排在实际情况里非常稳。

归并排序：铁打的O(n log n)。前面已经用递归树推过一遍，它的优势是复杂度不受输入顺序影响，劣势是需要额外的O(n)空间。在Java对象排序里，TimSort（一个融合归并和插入的混合算法）也是这个量级，而且对“部分有序”的数据特别友好。

堆排序：也是O(n log n)，而且空间O(1)。堆排序的复杂度分析有一点容易让人迷惑：建堆过程到底是O(n)还是O(n log n)？答案是原地建堆可以做到O(n)，但很多人记的是“正确但容易误导”的O(n log n)。如果从最后一个非叶子节点开始向下调整（sift down），每个节点的调整代价和它的高度成正比，所有节点的调整代价之和经过几何级数求和之后是O(n)。堆排序后面每次取出堆顶再调整的n次操作，每次O(log n)，合计O(n log n)，所以整体是O(n log n)。我见过不少博客把建堆写成O(n log n)，这实际上是把“逐个插入”和“原地建堆”两种算法搞混了，是个非常经典的坑。

3.3 动态规划与记忆化搜索：状态数×转移代价

动态规划的复杂度计算，有一个通用公式：DP复杂度 ≈ 状态数量 × 单个状态转移的代价。这个公式本身不难，难的是确定状态数和转移代价分别是什么。这里说几个实际例子。

一维DP，比如台阶问题：dp[i] = dp[i-1] + dp[i-2]，状态数是n，每个状态的转移是O(1)，总复杂度O(n)。这本质上就是一个斐波那契数列，前面说朴素递归是O(2^n)，加了记忆化或者自底向上就变成O(n)——这个对比足以说明DP的价值。

二维DP，比如矩阵路径最小和：dp[i][j] = min(dp[i-1][j], dp[i][j-1]) + grid[i][j]，状态数是m×n，每个状态转移O(1)，总复杂度O(mn)。很多二维DP题目都是这个套路，状态维数上去了复杂度就上去了。

带内层循环的DP，比如最长递增子序列的经典O(n²)解法：dp[i] = max(dp[j] + 1) for j < i 且 arr[j] < arr[i]。状态数是n，每个状态的转移要扫描前面所有j，代价是O(n)，汇总就是O(n²)。如果改用贪心+二分，把状态定义为“长度为i的递增子序列的末尾最小值”，状态转移变为二分查找O(log n)，总复杂度降到O(n log n)。这就是为什么DP的状态设计本身决定了复杂度上限，题目刷多了之后，第一反应不应该是“能不能用DP”，而应该是“用什么状态定义能让转移代价可控”。

区间DP，比如矩阵链乘法：dp[i][j] = min(dp[i][k] + dp[k+1][j] + ...)，状态数是O(n²)，每个状态要枚举切分点k，转移O(n)，总复杂度O(n³)。这类题目一眼看上去状态已经二维了，但转移还带循环，复杂度一下子从O(n²)跳到O(n³)。

我自己的经验是：拿到一道DP题，先别急着写代码，先在纸上把状态定义、状态转移方程、边界条件列出来，然后单独算一遍状态数和每个状态的转移开销。如果乘积超过你能接受的量级（比如10^8以上），那就得想优化方案：换状态定义、用单调队列/前缀和/二分优化转移、或者改成记忆化搜索看看哪些状态实际访问不到。复杂度计算在这里不是纸上谈兵，而是直接决定你的程序能不能在时限内跑完的生死线。

4. 复杂度计算中常见的坑与实战排查

4.1 常见误区与边界条件速查表

算复杂度的时候，有些坑是所有人都会踩的。我把这几年看代码、写代码、面试别人时遇到的典型误区整理成一个速查表，方便你对着自查。

其中“输入规模到底是啥”这个坑，我想多展开一点。比如下面这段代码：

这里i是倍增，时间复杂度是O(log n)。但如果我把循环条件改成for (long long i = 2; i <= (1LL << n); i *= 2)，迭代次数就变成n，复杂度就是O(n)了（因为循环范围随n指数增长）。同一个变量n，在不同上下文里代表的“输入规模”完全不同。这个例子听起来极端，但很多字符串匹配、大数运算相关的算法里都有类似问题。数值n做循环次数时，真正应该看的往往是n的二进制位数（即log₂n），否则最容易把O(n)当成O(log n)或者反过来。

4.2 面试和项目中的实战排查思路

算法复杂度不只是面试题，它在我定位线上性能问题的时候，是一个快速缩小范围的工具。我自己有个一套相对固定的排查思路，分享给你。

第一步，先静态分析代码，画出“热点路径”。比如一个接口响应变慢，我会从入口开始，把循环、递归、外部调用、数据库查询全部列出来，对每个单独算复杂度。这个阶段我不关心具体耗时，只关心它的渐进量级。用前面讲到的“基本语句计数法”，把每个循环的迭代次数和循环体代价标出来。

第二步，估算规模，确定瓶颈。线上接口的输入规模往往是已知或可测量的：比如一次请求要处理多少条记录、数据库表有多少行。回到那个著名的公式：如果数据量是10^5，O(n²)就是10^10次操作，在普通服务器上可能要数十秒；O(n log n)大约1.7×10^6次，毫秒级。通过数量级估算，可以直接判断瓶颈大概率在哪个环节。

第三步，用实际的数据或工具验证你的推测。静态分析可能会漏掉隐藏的线性扫描、版本库的排序行为、甚至是JIT编译优化带来的常数因子差异。我的习惯是先在代码里临时加一些计数器（操作次数统计），或者直接用性能分析器（Java的JFR、Go的pprof、Python的cProfile）跑一条真实流量，看热点函数被调用的次数和耗时，对照你手算的结果是否在同一个数量级。如果差了数量级，那大概率是你对某个“伪O(1)操作”产生了误判。

第四步，优化后再验证。定位到O(n²)的循环之后，常见的优化手段包括：把内层扫描改成哈希映射（从O(n²)降到O(n)）、把重复计算变成前缀和/后缀和、把递归改成自底向上的DP、或者引入缓存。优化之后再用同样的数据跑一遍，对比前后性能差异，确认复杂度确实降下来了。

说到这，我想起之前一个真实案例：有个批处理任务是遍历一个字符串列表，对每个字符串里的字符做去重统计，我同事一开始用了类似List.contains()的写法，每次判断都是O(m)的线性扫描，整体变成O(n×m)。数据量上来之后线上任务跑到超时。我把List.contains()换成HashSet后，整体降为O(n)，任务耗时从半小时缩到十几秒。这其实就是“循环体内藏了一个看似O(1)实则O(m)的调用”的典型案例，用复杂度分析能一眼识别。这就是我为什么反复强调：复杂度计算不是学院派的纸上谈兵，而是排查性能问题时的第一把手术刀。

自己在做复杂度分析时，我还有一个习惯：每一段重要的循环或者递归，都在代码注释里写清时间复杂度和空间复杂度。比如：

这看起来是个小动作，但效果非常好。代码过一周再看，或者同事接手，顺着注释里的复杂度就能瞬间判断这段代码在数据规模变大时会不会出问题。这比在代码评审里争论“这效率不行”要有说服力得多。

回看这些年走过的路，我越来越觉得复杂度计算就是程序员的“成本意识”。它不直接给你一份优化方案，但能在你写代码的那一刻就提醒你：这个循环嵌套在数据量大的时候会爆炸，这个递归层数深了会压爆栈，这个字符串拼接在循环里会让运行时白白做大量拷贝。很多时候，项目性能问题的根源不是某一个算法没写对，而是某一个隐蔽复杂度被忽略了。掌握一套“看见即算”的复杂度分析方法，就是拥有了在这种隐患还处于代码阶段时就发现它的能力。