效率：同一个问题，为什么有的算法几微秒、有的要跑一百万年

0. 本讲导读

到目前为止，你判断一段代码好不好的标准只有一个：它跑出来的答案对不对。递归、高阶函数、可变数据、面向对象、链表——每一讲都在教你「怎么把一个想法正确地表达成代码」。

本讲换一把尺子。正确只是及格线。 同一个问题往往有很多种正确的写法，它们的答案完全一样，但代价可以相差到荒谬的程度。本讲最震撼的一个例子是斐波那契数：

• 递归版 fib(100)：要做大约 1.1 × 10²¹ 次函数调用。按本机实测的速度算，跑完需要一百万年以上。
• 迭代版 fib(100)：本机实测 不到万分之一秒。fib(100000)（十万项，结果有两万多位）也只要 0.05 秒。

两段代码都不到十行，都完全正确，差距却是天文数字。这个差距不来自「Python 慢」，不来自「电脑不够快」——换台快一百万倍的机器，递归版还是跑不完。差距来自算法本身的结构。

那么怎么把这种差距说清楚？说「递归版慢」太含糊；说「递归版在我机器上跑了 0.27 秒」又依赖于机器。本讲给出的答案是增长阶（order of growth）：不看绝对时间，只看输入规模变大时，代价按什么规律涨。涨得慢的算法，规模一大就必然赢，跟机器无关。这套语言写出来就是你早晚会在各种地方见到的 O(n)、O(log n)、O(2ⁿ)。

它和前后讲的关系：上一讲的链表让你亲眼看到「在开头插入元素，链表快、Python list 慢」这个现象——本讲给这个现象一个名字和一套算法。往后学 Scheme、解释器、SQL，你会一再遇到「同一件事有多种实现」的选择题，本讲教的就是做这种选择题的依据。真正把这套东西展开讲的是 CS 61B 和 CS 170；61A 只要求你能对着一段几十行的代码，说出它的最坏情况运行时间是哪一档。

1. 为什么需要一把新尺子

先把问题摆清楚：解决同一个问题常常有很多种算法，我们凭什么说 A 比 B 好？

一个直觉的答案是：A 跑得比 B 快，A 就比 B 好。 这个直觉方向没错，但直接拿它当标准会立刻出问题。

为什么不能直接用「跑了多少秒」

因为秒数不是算法的性质，是这次运行的性质。它至少受三样东西影响：

• 硬件不同。同一段代码在你的笔记本和在服务器上跑，时间可以差十倍。那到底哪个数字代表这个算法？
• 同一台机器上也不稳定。后台有没有别的程序、缓存是冷是热、这一刻 CPU 降不降频，都会让结果抖动。测两次得到两个数是常态。
• 没法预测。你测了 n = 1000 用了 0.1 秒，那 n = 100000 要多久？秒数本身回答不了，除非你真的再跑一次。

下面这组数据是本机实测的，它同时展示了「秒数有用」和「秒数不够用」两面：

差了 500 多倍。上一讲的链表 demo 说的就是这件事：Python 的 list 在末尾加元素很便宜，在开头插元素很贵，因为后面所有元素都得整体往后挪一格。但「500 倍」这个数字换台机器就变了。真正不变的、可以写进教科书的，是「往开头插 n 个元素，总代价按 n² 涨；往末尾加 n 个元素，总代价按 n 涨」。

为什么也不能用「代码有几行」

• 一行代码里的活儿可多可少。x = 1 是一行，x = sorted(big_list) 也是一行，后者干的活是前者的几百万倍。
• 语言语法不一样。同一个算法，Python 写 5 行，C 写 20 行，Scheme 写 3 行——算法没变，行数变了三次，那行数显然不是算法的性质。

为什么也不能用「调用了多少次函数」

这个比前两个靠谱，本讲后面数 exp 和 fib 的调用次数时用的就是它。但它不能当通用标准，因为每个函数体内部干的活多少不一样：调用 10 次 square 和调用 10 次「排序一百万个数」完全不是一回事。它只在「所有调用干的活量级相同」时才是好的代理指标（fib 恰好满足，所以我们用它）。

2. 求幂：同一个函数，两种递归，两种命运

求幂（exponentiation）就是算 bⁿ：把数 b 自乘 n 次。b 叫底数（base），n 叫指数（exponent）。它可以递归地定义：

这个定义直译成代码就是：

def exp(b: int, n: int) -> int:
    if n == 0:
        return 1
    return b * exp(b, n - 1)

（b: int 和 -> int 是类型标注（type annotation），只是写给人看的注释，Python 运行时完全不检查它们。）

把它真的展开一遍

SPEC 里说得对：不要满足于「递归调用自身处理更小的问题」这种废话。exp(2, 5) 到底发生了什么，一层一层写出来：

exp(2, 5)   n≠0 → 返回 2 * exp(2, 4)     ← 卡住，等下面算完
  exp(2, 4)   n≠0 → 返回 2 * exp(2, 3)   ← 卡住
    exp(2, 3)   n≠0 → 返回 2 * exp(2, 2) ← 卡住
      exp(2, 2)   n≠0 → 返回 2 * exp(2, 1)
        exp(2, 1)   n≠0 → 返回 2 * exp(2, 0)
          exp(2, 0)   n==0 → 返回 1      ← base case，终于有确定的值了

现在逐层回代（从最里面往外算）：
          exp(2, 0) = 1
        exp(2, 1) = 2 * 1  = 2
      exp(2, 2) = 2 * 2  = 4
    exp(2, 3) = 2 * 4  = 8
  exp(2, 4) = 2 * 8  = 16
exp(2, 5) = 2 * 16 = 32

这里有一件对理解代价至关重要的事：在 exp(2, 0) 返回之前，那 6 个帧是同时活着的。exp(2, 5) 这一帧里的 return b * exp(b, n - 1) 只算了一半——它必须等 exp(2, 4) 给出值才能做那次乘法，所以它的帧不能销毁。画成环境图就是一摞：

Global frame
    exp  ──→ func exp(b, n) [parent=Global]

f1: exp [parent=Global]     b ──→ 2   n ──→ 5    正在算 2 * exp(2, 4)
f2: exp [parent=Global]     b ──→ 2   n ──→ 4    正在算 2 * exp(2, 3)
f3: exp [parent=Global]     b ──→ 2   n ──→ 3    正在算 2 * exp(2, 2)
f4: exp [parent=Global]     b ──→ 2   n ──→ 2    正在算 2 * exp(2, 1)
f5: exp [parent=Global]     b ──→ 2   n ──→ 1    正在算 2 * exp(2, 0)
f6: exp [parent=Global]     b ──→ 2   n ──→ 0    返回值 ──→ 1

注意每一帧的 parent 都是 Global，不是上一帧——parent 由「函数定义在哪儿」决定，exp 定义在全局，所以它每次被调用产生的帧的 parent 永远是 Global。帧的堆叠顺序是「谁在等谁返回」，跟 parent 链是两码事。这一点在 Lecture 05 讲过，这里再确认一次，因为下一节讲空间复杂度要用到：同时活着的帧数 = 递归深度。

数一数调用次数

规律一眼可见：n 每加 1，调用次数就加 1。这叫线性时间（linear time），记作 O(n)。

换一个递归定义

上面那个定义把 n 减 1。但数学上还有另一个同样正确的递归分解，它利用了平方：

翻译成代码：

def exp(b: int, n: int) -> int:
    if n == 0:
        return 1
    elif n % 2 == 0:
        temp = exp(b, n // 2)
        return temp * temp
    else:
        return b * exp(b, n - 1)

exp(2, 8)   8 是偶数 → temp = exp(2, 4)，然后返回 temp * temp
  exp(2, 4)   4 是偶数 → temp = exp(2, 2)，然后返回 temp * temp
    exp(2, 2)   2 是偶数 → temp = exp(2, 1)，然后返回 temp * temp
      exp(2, 1)   1 是奇数 → 返回 2 * exp(2, 0)
        exp(2, 0)   n==0 → 返回 1

回代：
        exp(2, 0) = 1
      exp(2, 1) = 2 * 1 = 2
    exp(2, 2) = 2 * 2 = 4
  exp(2, 4) = 4 * 4 = 16
exp(2, 8) = 16 * 16 = 256

只用了 5 次调用就算出了 2⁸。旧版本要 9 次。差距在 n 大的时候会拉开：

（表里 8、64 两行与幻灯片一致；1、100 两行是我在本机用计数器实测的。）

为什么是对数？ 想清楚这一点比记住结论重要得多。看 n 的下降路径：偶数时 n 折半，奇数时 n 减 1（而 n − 1 立刻变成偶数，下一步就折半）。所以最多每两步，n 就至少折一次半。一个数 n 能被折多少次半才降到 1？答案就是 log₂n。n = 64 折 6 次到 1，n = 1024 折 10 次，n = 1000000 折 20 次。

这就是对数时间（logarithmic time），记作 O(log n)。它的标志性特征是：n 翻倍，代价只增加一个常数。n 从 64 涨到 128，调用次数从 8 变成 9——涨了 1。

# 错误写法：看起来只是把 temp 展开了
def exp_bad(b, n):
    if n == 0:
        return 1
    elif n % 2 == 0:
        return exp_bad(b, n // 2) * exp_bad(b, n // 2)   # 算了两遍！
    else:
        return b * exp_bad(b, n - 1)

>>> 10**400 / 2
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
OverflowError: integer division result too large for a float

3. 斐波那契：树递归为什么会爆炸

斐波那契数列（Fibonacci sequence）：0, 1, 1, 2, 3, 5, 8, 13, 21, …，每一项是前两项之和。递归定义直译成代码只有三行：

def fib(n):
    if n == 0 or n == 1:
        return n
    return fib(n - 1) + fib(n - 2)

这段代码完全正确，而且优雅得几乎是递归的教科书范例。fib(0) 返回 0，fib(1) 返回 1，fib(35) 返回 9227465——全对。

问题在于它有两个递归调用。exp 每次只生一个孩子，所以它的调用结构是一根链；fib 每次生两个孩子，调用结构是一棵树。这就是树递归（tree recursion），而树的节点数是随深度指数增长的。

把 fib(5) 的调用树完整画出来

fib(5)
├── fib(4)
│   ├── fib(3)
│   │   ├── fib(2)
│   │   │   ├── fib(1) → 1      ← base case
│   │   │   └── fib(0) → 0      ← base case
│   │   │   fib(2) = 1 + 0 = 1
│   │   └── fib(1) → 1
│   │   fib(3) = 1 + 1 = 2
│   └── fib(2)
│       ├── fib(1) → 1
│       └── fib(0) → 0
│       fib(2) = 1 + 0 = 1
│   fib(4) = 2 + 1 = 3
└── fib(3)
    ├── fib(2)
    │   ├── fib(1) → 1
    │   └── fib(0) → 0
    │   fib(2) = 1 + 0 = 1
    └── fib(1) → 1
    fib(3) = 1 + 1 = 2

fib(5) = 3 + 2 = 5

数一数这棵树上有多少个节点：15 个。也就是说，算 fib(5) 一共调用了 15 次 fib——为了得到一个 5。

而且请看清楚这棵树里的重复：

• fib(3) 被完整地算了 2 次
• fib(2) 被完整地算了 3 次
• fib(1) 被算了 5 次，fib(0) 被算了 3 次

每一次 fib(3) 都从零开始把它下面那一整棵子树重算一遍，尽管答案永远是 2。这就是指数爆炸的来源：不是问题难，是同一个子问题被反复求解。

调用次数到底涨得多快

下面这张表是我在本机加计数器实测出来的（不是估算）：

n 每加 10，调用次数就乘以 123 左右——注意是「乘以」，不是「加上」。这正是指数时间（exponential time）的定义特征：n 增加一个常数，代价乘以一个常数。（123 开十次方约等于 1.618，正是黄金比例 φ；准确地说调用次数等于 2·fib(n+1) − 1，增长率是 φⁿ，而 φⁿ 属于 O(2ⁿ) 这一档。）

4. 记忆化：把算过的答案记住

上一节把病因诊断清楚了：同一个子问题被反复求解。那治法就很自然——算过一次就把答案存起来，下次直接拿。 这个技术叫记忆化（memoization）。

它能成立有一个前提，幻灯片专门点出来了：fib 是一个纯函数（pure function）——给定同样的实参，它每次的返回值都一样，而且不产生任何副作用。所以「上次算 fib(3) 得到 2」这条信息这次仍然有效。如果函数会读时间、读随机数、改全局变量，缓存就会给出错误答案。

def memo(f):
    cache = {}
    def memoized(n):
        if n not in cache:
            cache[n] = f(n)
        return cache[n]
    return memoized

@memo
def fib(n):
    if n == 0 or n == 1:
        return n
    return fib(n - 1) + fib(n - 2)

先看懂 memo 本身：这是一个闭包

memo 用上了 Lecture 04 的全套高阶函数机制，值得逐步拆开。执行 fib = memo(fib)（这就是 @memo 的含义）的时候：

Global frame
    memo  ──→ func memo(f) [parent=Global]
    fib   ──→ func memoized(n) [parent=f1]      ← 注意！fib 已经不是原来那个函数了

f1: memo [parent=Global]
    f      ──→ func fib(n) [parent=Global]      ← 原始的、未加缓存的 fib
    cache  ──→ {}                               ← 这个字典只有 memoized 能看见
    返回值  ──→ func memoized(n)

为什么记忆化能对递归生效？这是整段代码最妙、也最容易看漏的地方。 原始 fib 函数体里写的是 fib(n - 1) + fib(n - 2)。这两个 fib 是名字，要到运行时才去查——而 fib 定义在全局，所以它的帧的 parent 是 Global，查 fib 会查到全局帧里现在的那个绑定，也就是 memoized！

于是每一次内部递归调用都会先经过缓存检查。如果名字查找不是「运行时才查」，这个技巧根本不成立。

加了缓存以后到底省了多少

再跑一遍 fib(5)，这次跟踪的是「原始 fib 函数体被真正执行了几次」：

fib(5)  cache={}            5 不在 cache → 执行原始函数体 → 需要 fib(4) + fib(3)
  fib(4)  4 不在 cache → 执行函数体 → 需要 fib(3) + fib(2)
    fib(3)  3 不在 cache → 执行函数体 → 需要 fib(2) + fib(1)
      fib(2)  2 不在 cache → 执行函数体 → 需要 fib(1) + fib(0)
        fib(1)  1 不在 cache → 执行函数体 → 返回 1，存 cache[1] = 1
        fib(0)  0 不在 cache → 执行函数体 → 返回 0，存 cache[0] = 0
      fib(2) = 1 + 0 = 1，存 cache[2] = 1
      fib(1)  1 在 cache 里！直接返回 1，函数体一次都不执行
    fib(3) = 1 + 1 = 2，存 cache[3] = 2
    fib(2)  2 在 cache 里！直接返回 1
  fib(4) = 2 + 1 = 3，存 cache[4] = 3
  fib(3)  3 在 cache 里！直接返回 2
fib(5) = 3 + 2 = 5，存 cache[5] = 5

最终 cache = {1: 1, 0: 0, 2: 1, 3: 2, 4: 3, 5: 5}
原始函数体执行次数：6 次（n = 0,1,2,3,4,5 各一次）

从 15 次降到 6 次。而且规律很清楚：每个不同的 n 只会真正算一次，所以原始函数体总共执行 n + 1 次。这是 O(n)——从指数直接降到线性。本机实测确认：n = 5 时 6 次，n = 10 时 11 次，n = 30 时 31 次。

实际效果：记忆化版的 fib(100) 本机耗时 4.8 × 10^-5 秒，结果是 354224848179261915075。而不带缓存的版本需要一百四十万年。同样的三行递归定义，只是外面套了一个字典。

def memo(f):
    def memoized(n):
        cache = {}          # 错！
        if n not in cache:
            cache[n] = f(n)
        return cache[n]
    return memoized

>>> fib(1000)
Traceback (most recent call last):
  ...
RecursionError: maximum recursion depth exceeded

5. 迭代版 fib：不用缓存也能线性

记忆化保留了递归的写法，用额外内存换时间。还有第三条路：彻底不递归。想想人手算斐波那契是怎么算的——你不会从 fib(5) 往下拆，你会从 0, 1 开始往上加：0, 1, 1, 2, 3, 5。这个过程只需要记住最近两个数。

def fib(n):
    curr, nxt = 0, 1
    k = 0
    while k < n:
        curr, nxt = nxt, curr + nxt
        k += 1
    return curr

（写 nxt 不写 next，是为了不遮蔽 Python 内置函数 next。）

逐轮追踪 fib(5)

循环里的三个名字：curr 是「当前这一项」，nxt 是「下一项」，k 是「已经往前走了几步」。循环不变式（loop invariant）是：每轮循环开始时，curr == fib(k) 且 nxt == fib(k+1)。

返回 curr，也就是 5。对照不变式：退出时 k == 5，所以 curr == fib(5) == 5。✓

循环体执行 n 次，每次做的都是常数量的工作（一次加法、两次赋值、一次比较）。所以是 O(n) ——线性时间。而且它只用了三个名字，不管 n 多大都是三个，空间是 O(1)。

def bad_fib(n):
    curr, nxt = 0, 1
    k = 0
    while k < n:
        curr = nxt          # curr 已经变了
        nxt = curr + nxt    # 这里的 curr 是新值，不是老值！
        k += 1
    return curr

[0, 1, 2, 4, 8, 16, 32, 64]

        old_curr = curr
        curr = nxt
        nxt = old_curr + nxt

三个版本横向对比

三个都返回 354224848179261915075。正确性完全一样，代价天差地别。

6. 增长阶与大 O 记号

前面三节一直在用「线性」「对数」「指数」这些词。现在把它们变成一套正式的语言。

增长阶（order of growth）：用一个数学函数描述「运行时间随输入规模 n 增长的方式」。写法是 大 O 记号（Big O notation），比如 O(n)。

注意两处「技术上」的补充说明，幻灯片用灰字标出来了：

• O(log n) 里的对数底数是几其实无所谓。因为换底只差一个常数因子（log₂n = log₁₀n / log₁₀2），而常数因子要丢掉。所以直接写 O(log n)，不写底数。
• O(2ⁿ) 里的底数不一定是 2，3ⁿ、φⁿ 都算指数级。但底数在这里不能随便换——3ⁿ 和 2ⁿ 差的是 1.5ⁿ，那不是常数。写 O(2ⁿ) 是这一档的习惯代号。

为什么这五档差距这么大

把抽象曲线换成具体数字更有冲击力。假设一次操作要 1 纳秒（10^-9 秒）：

读这张表最该注意的不是指数那一列有多离谱，而是平方那一列：n = 100 时它还只要 10 微秒，看起来毫无问题；n = 一百万时就要 17 分钟了。真实工程里绝大多数性能事故是 O(n²) 造成的，因为它在小数据上完全看不出毛病，测试全过，上线以后数据一涨就炸。

7. 时间复杂度分析：拿到一段代码该怎么下手

正式名称是时间复杂度分析（time complexity analysis），也叫运行时分析（runtime analysis）或渐进分析（asymptotic analysis）。

哪些操作是 O(1)

第 1 步要能一眼判断单行代价，得先有一张常数时间操作的清单：

x in lst          # 列表成员检查：最坏要把整个列表扫一遍
lst.index(x)      # 同上
lst.insert(0, x)  # 要把后面所有元素往后挪
lst[1:]           # 切片会复制出一个新列表
sum(lst)          # 遍历
max(lst)          # 遍历

完整走一遍：分析 bonk

def bonk(n):
    sum = 0
    while n >= 2:
        sum += n
        n = n / 2
    return sum

三处需要看仔细：

• 循环外的 O(1) 只算一次，循环内的要乘轮数。 这是第 2 步的全部内容，也是最常出错的地方。
• 丢低阶项：那个 O(2) 是循环外那两行（sum = 0 和 return sum）的和。相比 5·log₂n，常数项在 n 大时可以忽略。
• 丢常数因子：5 没了，底数 2 也没了（换底只差常数），剩下 O(log n)。

>>> bonk(10**400)
Traceback (most recent call last):
  ...
OverflowError: integer division result too large for a float

8. 实战一：两种查找

下面三节是课上的随堂练习，代码来自 17.py。先自己分析，再看解答。 任务都是一样的：说出运行时间关于 n 的表达式，n 是 nums 的长度。

def search_list1(nums, target_num):
    """Returns the index of TARGET_NUM in sorted list NUMS or -1 if not found.
    >>> search_list1([1, 2, 3, 4], 3)
    2
    >>> search_list1([14, 23, 37, 48, 59], 23)
    1
    >>> search_list1([14, 23, 37, 48, 59], 47)
    -1
    """
    found_index = -1
    for i, elem in enumerate(nums):
        if elem == target_num:
            found_index = i
            break
    return found_index

search_list1：线性查找

逐行数：

答案：O(n)，线性时间。这和官方解答 17-sol.py 里标注的 # O(n) 一致。

那个 break 值得单独说一句。它确实能让运气好的时候提前结束——目标在第一个位置时只跑一轮。但本课要的是最坏情况：目标在最后一个位置，或者根本不在列表里（比如 doctest 里找 47 那个例子），循环必须跑满 n 轮。所以答案还是 O(n)。

search_list2：二分查找

def search_list2(nums, target_num):
    """Returns the index of TARGET_NUM in sorted list NUMS or -1 if not found.
    >>> search_list2([1, 2, 3, 4], 3)
    2
    >>> search_list2([14, 23, 37, 48, 59], 23)
    1
    >>> search_list2([14, 23, 37, 48, 59], 47)
    -1
    """
    min_index = 1
    max_index = len(nums)
    while min_index <= max_index:
        middle_index = (min_index + max_index) // 2
        if target_num == nums[middle_index]:
            return middle_index
        elif target_num > nums[middle_index]:
            min_index = middle_index + 1
        else:
            max_index = middle_index - 1
    return -1

这是二分查找（binary search）。它成立的前提是 docstring 里那个词：NUMS 是有序的。因为有序，看一眼中间那个数就能断定目标在左半边还是右半边，一刀砍掉一半。

初始： min_index = 1, max_index = 5

第 1 轮： 1 <= 5 成立
         middle_index = (1 + 5) // 2 = 3
         nums[3] 是 48
         47 == 48 ? 否
         47 >  48 ? 否 → 目标在左半边 → max_index = 3 - 1 = 2

第 2 轮： 1 <= 2 成立
         middle_index = (1 + 2) // 2 = 1
         nums[1] 是 23
         47 == 23 ? 否
         47 >  23 ? 是 → 目标在右半边 → min_index = 1 + 1 = 2

第 3 轮： 2 <= 2 成立
         middle_index = (2 + 2) // 2 = 2
         nums[2] 是 37
         47 == 37 ? 否
         47 >  37 ? 是 → min_index = 2 + 1 = 3

第 4 轮检查： 3 <= 2 不成立 → 退出循环 → return -1   ✓

搜索区间的宽度依次是 5 → 2 → 1 → 0，每轮至少砍掉一半。这就是复杂度的来源：

答案：O(log n)，和官方解答一致。

实测一下这个差距（在一个 200 万元素的有序列表里找最后一个元素）：

快了约 5600 倍。而且这个倍数会随 n 继续拉大——n 翻倍时，线性查找的时间翻倍，二分查找只多做 1 步。

>>> search_list2([1, 2, 3, 4], 1)
-1

>>> search_list2([1, 2], 5)
Traceback (most recent call last):
  ...
IndexError: list index out of range

    min_index = 0
    max_index = len(nums) - 1

9. 实战二：素数判定与嵌套调用

is_prime1 与 is_prime2

这两个函数都判断 n 是不是素数。注意这里的 n 是那个数字本身，不是列表长度——「相对于什么规模」每次都要问清楚。

def is_prime1(n):
    for i in range(2, n):
        if n % i == 0:
            return False
    return True


def is_prime2(n):
    i = 2
    while i * i <= n:
        if n % i == 0:
            return False
        i += 1
    return True

is_prime1：循环变量从 2 走到 n−1，最多跑 n − 2 轮，每轮做一次取模和一次比较（都是 O(1)）。答案：O(n)。

那个 return False 同样只在运气好时提前结束（比如 n 是偶数，第一轮就返回）。最坏情况是 n 真的是素数——循环一轮都省不掉。所以 O(n)。

is_prime2：循环条件是 i * i <= n，也就是 i <= √n。所以最多跑 √n 轮，每轮仍是 O(1)。答案：O(√n)。

本机实测（n = 1000003，是素数，也就是两个函数的最坏情况）：

bar 与 biz：嵌套调用

def bar(n):
    i, sum = 1, 0
    while i <= n:
        sum += biz(n)
        i += 1
    return sum

def biz(n):
    i, sum = 1, 0
    while i <= n:
        sum += i**3
        i += 1
    return sum

这题的全部难点在一行：sum += biz(n)。它看起来只是一次加法赋值，但右边藏着一整个循环。

答案：O(n²)，和官方解答标注一致。

关键在于 biz 拿到的实参是 n，不是 i——所以内层循环每一轮都跑满 n 次，跟外层进行到第几轮无关。总操作数正好是 n × n。

本机实测验证（平方级的标志：n 翻倍，时间约变 4 倍）：

10. 空间复杂度

时间不是唯一的代价。空间复杂度（space complexity）问的是同一个问题的另一面：这个算法运行时要占多少内存？ 分析方法完全一样——看内存占用随 n 的增长形式，丢常数和低阶项。

对本课来说，最主要的内存开销就是帧。每一个还没返回的函数调用都占着一帧，帧里有形参和局部变量。所以：

这正好解释了第 3 节末尾那个对照：

幻灯片点明的正是这一条：递归和记忆化版本的 fib 空间复杂度都比迭代版高，因为递归要开一堆帧，每帧还带着自己的局部变量。

时间与空间常常互换

记忆化是最干净的例子：它花掉 O(n) 的额外内存，换来时间从 O(2ⁿ) 降到 O(n)。这笔买卖显然划算，但不是所有场合都划算——如果内存本来就紧张（嵌入式设备、超大数据集），你可能宁愿多算一会儿。「时间-空间权衡（time-space tradeoff）」是工程里天天要做的决定。

>>> fib(1000)          # 记忆化版本，时间上明明是 O(n)
Traceback (most recent call last):
  ...
RecursionError: maximum recursion depth exceeded

本讲小结

一张速查：看到什么，答什么

这张表是起手直觉，不是判决书。真遇到代码，还是得按第 7 节那四步老实数一遍——尤其要盯住「循环里调用的那个函数自己要花多少时间」。

动手练习

下面每一题都建议先自己算出答案再展开。所有代码我都在本机跑过，答案里给的数字都是实测值。

练习 1：三段代码，各是什么复杂度

def a(n):
    total = 0
    for i in range(n):
        for j in range(i):
            total += 1
    return total

def b(n):
    total = 0
    i = 1
    while i < n:
        for j in range(n):
            total += 1
        i = i * 2
    return total

def c(n):
    total = 0
    i = n
    while i > 1:
        total += 1
        i = i // 2
    return total

练习 2：这个「去重」函数为什么慢

def unique(lst):
    """返回 lst 中不重复的元素，保持原顺序。
    >>> unique([1, 2, 1, 3, 2])
    [1, 2, 3]
    """
    result = []
    for x in lst:
        if x not in result:
            result.append(x)
    return result

它的复杂度是多少（n 是 lst 的长度）？怎么改进？

def unique_fast(lst):
    result = []
    seen = set()
    for x in lst:
        if x not in seen:
            seen.add(x)
            result.append(x)
    return result

练习 3：数调用次数

def g(n):
    if n <= 0:
        return 1
    return g(n - 1) + g(n - 1)

g(4) 一共调用了多少次 g？g 的时间复杂度是多少？空间复杂度呢？如果把函数体改成 x = g(n - 1); return x + x，答案会变吗？

练习 4：记忆化的执行顺序

def memo(f):
    cache = {}
    def memoized(n):
        if n not in cache:
            cache[n] = f(n)
        return cache[n]
    return memoized

@memo
def fib(n):
    print(n)
    if n == 0 or n == 1:
        return n
    return fib(n - 1) + fib(n - 2)

调用 fib(4)，屏幕上会打印出哪些数字，按什么顺序？cache 最终是什么？

fib(4)  cache 空 → 执行函数体 → 打印 4 → 需要 fib(3) + fib(2)
  fib(3)  不在 cache → 打印 3 → 需要 fib(2) + fib(1)
    fib(2)  不在 cache → 打印 2 → 需要 fib(1) + fib(0)
      fib(1)  不在 cache → 打印 1 → 返回 1，cache[1] = 1
      fib(0)  不在 cache → 打印 0 → 返回 0，cache[0] = 0
    fib(2) = 1，cache[2] = 1
    fib(1)  在 cache 里 → 直接返回 1，函数体不执行，不打印
  fib(3) = 2，cache[3] = 2
  fib(2)  在 cache 里 → 直接返回 1，不打印
fib(4) = 3，cache[4] = 3

练习 5：判断题

下面每句话对不对？说出理由。

1. 一个 O(n²) 的算法在任何输入下都比 O(n) 的算法慢。
2. 说「迭代版 fib 是 O(2ⁿ)」是错的。
3. 递归 fib 的空间复杂度是 O(2ⁿ)，因为它要做 2ⁿ 次调用。
4. lst.append(x) 和 lst.insert(0, x) 都是往列表里加一个元素，复杂度相同。
5. 快速求幂里 temp = exp(b, n // 2) 换成 return exp(b, n // 2) * exp(b, n // 2)，结果和复杂度都不变。