ZIP 为什么能让文件变小？—— 压缩的原理、格式与极限

先看三个事实，它们看起来互相矛盾。

第一个：一个 221 KB 的中文文本文件，压成 ZIP 之后只剩 1.1 KB，砍掉了 99.5%。

第二个：一个 293 KB 的随机数据文件，压成 ZIP 之后变成 293.1 KB，不但没小，还胖了一点。

第三个：把一个已经压好的 ZIP 再压一遍、再压一遍、再压一遍。

这三个事实是同一件事的三个侧面。这篇文章想把它们串起来讲清楚。下面所有数字都是我在自己机器上跑出来的，不是抄的，代码逻辑在文中随手能找到。

顺便说一下这篇的写法。压这个话题有很多层，我打算把几套不同的思路混着用：用第一性原理拆它的成本结构，用它反过来想想什么时候不该压，用代码跑一遍验证，再盯一下那些极端情况。同一件事从几个角度各看一遍，比只从一个角度往下挖更容易看到全貌。

一、ZIP 文件格式分析

要理解压缩，先看看压缩出来的东西长什么样。很多人用了十几年 ZIP，从没打开过一个 ZIP 文件看里面。

一个 ZIP 文件不是”一团压缩数据”，它是一个有结构的容器。它的结构大致是这样：

从左到右，重复出现的是本地文件头 + 压缩数据的组合，每加一个文件就重复一组。真正的目录信息不在开头，而是攒在文件最后面，叫做中央目录。

三个关键位置各有一个魔数（magic number），也就是固定字节序列：

1
2
3

PK\x03\x04   本地文件头，每个文件一个
PK\x01\x02   中央目录条目，每个文件一条
PK\x05\x06   中央目录结束记录，整个文件一条

PK 是 Phil Katz 的缩写，ZIP 格式的发明者。他把自己的名字缩写塞进了每个 ZIP 文件的第一个字节里，这个签名就这么流传了四十年。

我实际造了一个最小的 ZIP，只放一个 hello.txt，内容是 "Hello, ZIP! " 重复 20 遍，一共 240 字节。整个 ZIP 文件 133 字节，十六进制长这样：

1
2
3
4

0000  50 4b 03 04 14 00 00 00 08 00 f3 2a 4e 5d 27 70  PK.........*N]'p
0010  7a 7e 11 00 00 00 f0 00 00 00 09 00 00 00 68 65  z~............he
0020  6c 6c 6f 2e 74 78 74 f3 48 cd c9 c9 d7 51 88 f2  llo.txt.H....Q..
0030  0c 50 54 f0 18 01 6c 00 50 4b 01 02 14 03 14 00  .PT...l.PK......

一段段读：

开头 50 4b 03 04 就是 PK\x03\x04，本地文件头。

14 00 是版本号，00 00 是标志位，08 00 是压缩方法（8 代表 deflate），后面 f3 2a 4e 5d 是修改时间戳，27 70 7a 7e 是 CRC32 校验值。

再后面 11 00 00 00 是压缩后大小，17 字节。f0 00 00 00 是原始大小，240 字节。240 字节压到 17 字节，比例 14:1。09 00 是文件名长度，9 个字节，跟着就是 hello.txt。

然后是压缩数据本身，从 f3 48 cd c9... 开始。直到偏移 0x36 附近，出现 50 4b 01 02，中央目录开始了。

注意中央目录里存的是什么：压缩方法、CRC、压缩前后大小、文件名长度、以及本地文件头在文件中的偏移量。这些信息在本地文件头里已经出现过了，中央目录里又存了一份。

重复存两次，是故意的。 本地头是在写入数据前就得先写好的，那时候压缩还没完成，所以压缩后大小和 CRC 只能先占位、后面再回头补（或者在数据后面追加一个”数据描述符”）。而中央目录是最后写的，所有值都已经确定。解压软件打开文件时直接跳到文件尾部读中央目录，就能拿到完整目录，不用从头扫描整个文件。

这个设计还有一个后果：中央目录的偏移量是从文件开头算的。所以如果你在 ZIP 文件前面拼接一段数据，很多软件的中央目录偏移就对不上了，ZIP 会被”破坏”。这也是为什么 ZIP 有一个”自解压包”变种（前面拼一段可执行程序）需要特殊处理偏移。

ZIP 结构还有一点值得说：每条目录项和每个文件头都是”长度前缀 + 可变长字段”，是顺序解析的格式，不是定长结构。这种设计写起来方便、扩展起来方便（后来的 ZIP64 就是靠加新字段扩展的），但解析时必须严格按长度跳，跳错一个字节后面全乱。

二、什么是压缩

现在讲压缩本身。压缩这个词有误导性，它让人以为文件里”少了一些东西”。

实际上，压缩一个字节的信息都没丢（无损压缩的情况下）。变的是表示方式，不是内容。

有个特别直接的例子。假设你要记录一串抛硬币结果，正面写 H，反面写 T，抛 100 次：

1

HHTHHTTTHTHTTHHHTTHHTTTTH...

一个字符一个字节，100 字节。

但如果你数出来正面 52 次、反面 48 次，你完全可以用另一句话描述它：抛 100 次，正面 52 次，反面的位置是第 3、6、7、8……

两种说法描述的是同一件事，第二种明显更短，因为它利用了”硬币有规律”这件事。压缩做的就是这件事：找出数据里的规律，然后用更短的写法把规律表达出来。

关键在于，压缩赚的钱全部来自”规律”。没有规律的数据，压缩无从下手。这就是第二个事实的来源。

用一个更精确的说法：压缩的本质是预测。一个好的压缩算法，是在给定前面已经出现的内容时，对下一个字节做出准确预测。预测得准，就只需要存”预测错了什么”，而不是”实际是什么”。ZIP 里用的 deflate 就是这么干的，下一节展开。

三、ZIP 为什么能让文件变小

ZIP 默认用的算法叫 deflate，它是两个老技术拼起来的：LZ77 找重复，Huffman 编码压缩。

第一步：LZ77，把重复换成”往回数几个，抄几个”

LZ77 的思路朴素得不像话：如果一段内容前面刚出现过，就别再存一遍，存一个”往回几个字节、复制多长”的指令就行。

我用十几行代码实现了一个迷你版 LZ77，让它处理这段字符串：

1

ababababababababababcccccc

26 个字符，它的输出是 5 个记号：

1

[('字面', 'a'), ('字面', 'b'), ('复制', 2, 18), ('字面', 'c'), ('复制', 1, 5)]

翻译一下：先直接写个 a，再直接写个 b，然后”往回数 2 个字符，复制 18 个”，于是剩下的 18 个 ab 全出来了。再写个 c，”往回数 1 个，复制 5 个”，五个 c 到位。

26 个字符，用 5 个记号描述完了。这就是压缩的全部魔术，剩下的是细节。

真实数据没有这么规整，但规律无处不在。一段中文里”的””了””是”反复出现，一段英文里 “the” 反复出现，一段 JSON 里每个对象的 key 都一样。LZ77 就是在这些地方省字节。

ZIP 里 LZ77 的滑动窗口大小是 32 KB（后来有各种扩展），意思是它只能”往回看 32 KB”找重复。超过 32 KB 之外的重复，它看不见。这个数字以后会变成一个关键点。

第二步：Huffman 编码，给常出现的东西发短码

LZ77 的输出是一堆字面字节和一堆(距离, 长度)对。这些东西也不是均匀分布的，有些值出现得特别多。

Huffman 编码的做法是：统计频率，出现得多的给短码，出现得少的给长码。

比如正常情况下一个字节要 8 位。如果某个值占了 30% 的出现次数，给它一个 2 位的短码，平均下来每个符号占用的位数就降下来了。

举个最极端的例子，一个只含四种字符的文件，理论上每个字符只需要 2 位，能压到 1/4。而一个 256 种字符均匀分布的文件，每个字符 8 位，一点都压不动。

Huffman 的天花板是”符号的出现频率”。LZ77 的天花板是”重复的长度和距离”。这两者叠加，就是 deflate 的能力边界。

用前面那个 ZIP 例子收个尾：hello.txt 的内容是 "Hello, ZIP! " 重复 20 遍，240 字节。LZ77 立刻看到这 12 个字符重复了 20 次，第一个记号是 12 个字节的字面量，后面 19 次全是”往回数 12 个，复制 12 个”。输出压缩到 17 字节。

240 字节里的信息量其实只有 12 个字节那么多，剩下的都是同一句话说了二十遍。压缩把这份啰嗦收走了。

四、压缩的地板：香农熵

到这里有个自然的问题：能压多小？有没有下限？

有，而且这个下限在 1948 年就被算出来了。香农提出一个量叫熵，衡量一段数据里每个符号平均携带多少信息：

其中 $p_i$ 是第 i 种符号出现的概率。

公式的意思是：一个符号如果几乎必然出现，它携带的信息就接近零（因为不需要告诉别人）；一个符号如果完全随机，它携带的信息就多。所有符号的信息量按概率加权平均，就是熵。

香农的结论是：无损压缩的平均码长不可能低于熵。这是一个定理，不是一个经验规律。任何压缩算法，无论多聪明，都撞不破这堵墙。

熵的单位是 bit/符号。一个字节有 256 种可能，最大熵就是 $\log_2 256 = 8$ bit。

我测了几类数据的熵，和它们的实际压缩效果放在一起：

图二把熵和压缩率画在一起。横轴是熵，纵轴是压缩后体积占原始体积的百分比。点越往右，越压不动。全零数据（熵 0）压到千分之一，随机数据（熵 7.999）压完还多了两个字节，正好落在 100% 以上那条红线上方。

不过这里有个必须交代的技术细节，不交代就是骗人。

我算的这个熵是零阶熵，它只看单个字节出现的频率，完全不管字节的顺序。对于”重复了 900 遍同一段话”的中文文本，零阶熵给出 5.471 bit/字节，换算一下理论下限是 68%，但实测压到了 0.5%。差距巨大。

原因不难理解。那段文本真正的规律不在”哪些字节出现得多”，而在”下一段和上一段完全一样”。这种跨距离的重复，零阶熵看不见。

要衡量它，得用更高阶的模型：考虑字节之间的条件概率，或者考虑重复结构本身。阶数越高，估计越准，但计算也越贵。

所以准确的说法是：熵告诉你”在给定模型下还剩多少可压的空间”。模型越强，看到的规律越多，估出来的下限越低。而真实的信息量下限（那个算法无论如何都撞不破的）需要最理想的模型才能算出来。

零阶熵虽然粗糙，但方向是对的：全零数据熵为 0，怎么压都行；随机数据熵接近 8，谁都救不了。这两端它判得很准。

五、为什么有的文件压不动

现在可以回答第二个问题了。

压不动的原因只有一个：里面已经没有规律了。

随机数据是最典型的。我造了 293 KB 的真随机字节（os.urandom），它每个字节值都均匀分布，零阶熵 7.999，接近理论上限 8。任何压缩算法面对这种数据都无从下手，因为下一个字节和前面的字节没有任何关系。

压缩之后那 0.1 KB 是哪来的？是头部开销。gzip 带 18 字节头部，zip 还有本地文件头、中央目录、CRC，这些是固定的元数据。所以压随机数据的结果是变大。

这里有个常见说法需要改一下：”已经压过的文件就压不动了”。

这句话大体对，但不够准。看我测的数据：PNG 图片（本身就是 deflate 压过的）还能被 gzip 再压掉 57%，JPEG（有损压缩过的）还能再压 82%。看起来像是推翻了那句话。

不完全是。原因在于这两张图是我生成的渐变色，PNG 自身的 compress level 和块结构未必最优；PNG 内部有多个 IDAT 块、每块都有块头和对齐，这些结构本身有冗余；而 JPEG 里那段量化表、霍夫曼表，也是每个文件都一样的固定结构，gzip 一眼就能识别。

所以更准确的说法是：决定能不能压的，是”还有没有可利用的规律”，而不是”它是不是已经压过”。已经压过的文件通常规律被榨得比较干，所以一般压不动。但压缩算法不是完美的，它的输出里往往还残留着格式级的结构，二次压缩偶尔还能捡一点。捡到多少，取决于原格式留了多少余地。

这就引出了最有趣的一部分。

六、套娃为什么不管用

第三个问题：压了再压再压，会不会越压越小？

实测最直接。把那段 221 KB 的中文文本连续 gzip 五次：

1
2
3
4
5
6

原始        226,800 bytes
第 1 层       1,128 bytes
第 2 层         292 bytes
第 3 层         315 bytes
第 4 层         338 bytes
第 5 层         358 bytes

用 ZIP 套 ZIP 再套五层：

1
2
3
4
5
6

原始        226,800 bytes
zip 1         1,220 bytes
zip 2           439 bytes
zip 3           531 bytes
zip 4           627 bytes
zip 5           734 bytes

看清楚这个曲线。第一层砍掉了 99.5%，剩下 1.1 KB。

第二层居然还能再砍，砍到 292 字节。这个现象值得停下来想一下，因为它打破了很多人的直觉。

为什么第二层还能压？因为 deflate 的输出不是理论最优的。第一层用的滑动窗口只有 32 KB，而原始文本是 226 KB，里面有跨 32 KB 的重复它够不着。它输出的一串(距离, 长度)记号里，这些记号本身又形成了新的规律模式。第二层压缩面对的是”第一层输出的字节流”，它能看到一些第一层看不到的结构。

从第三层开始，曲线掉头向上：315、338、358，一路涨。

因为到了这个阶段，数据已经接近熵的下限了。里面剩下的规律少得可怜，压不动了，而每一层都会增加自己的头部开销。gzip 每层加 18 字节，ZIP 每层加几十字节的本地头加中央目录。压不动的同时还在往里塞元数据，于是净结果就是变大。

用一句话总结这个规律：每一层压缩都在”还剩下的规律”里捞最后一点油水。第一层捞走最多，第二层捞一点渣，第三层开始，你付的头部开销已经超过捞到的东西了。

再换个角度看。压缩是在做一笔交易：你用”计算时间 + 头部开销”换”体积缩小”。这笔交易在第一层几乎稳赚，因为原始数据里规律遍地都是。到了第三层，一次压缩要扫描整个文件、建 Huffman 表、输出各种头，而这些成本换来的收益接近零，交易就亏了。

所以那些”压个十遍文件就小到看不见了”的说法，纯属想象。

一个必须提的极端情况

刚才说每层都在缩小，这有个前提：内容真的在变小。

如果内容不缩小，而是反过来膨胀呢？

有一类文件叫 ZIP 炸弹，专门利用这一点。公开资料里最著名的是 42.zip，文件本身只有几十 KB，解压出来有几 PB。它的做法就是多层嵌套：每一层里放 16 个文件，每个文件又是下一层，层层相乘。因为它压的东西是全零数据（我实测全零数据熵为 0，能压到千分之一以下），每一层都能缩小十倍以上。

这就是那种典型的边界情况：平时看起来温良无害的机制，在极端参数下会变成攻击面。一个正常的压缩工具，遇到一个压缩比异常高的文件时，不应该直接按头部声明的原始大小去分配内存。这是解压软件的基本防御。

七、常用压缩算法与格式科普

无损压缩的几大家族

我实测了同一份数据在几种算法下的表现：

规律很清楚：压缩率上 xz > bzip2 > gzip，代价是速度。

但看源代码那一行。源文件只有 23 KB，bzip2 压出来 4.8 KB，反而比 gzip 的 3.8 KB 更大。

这不是 bzip2 算法差，是它吃亏在了块结构上。bzip2 会把数据切成块处理，每块有自己的头和变换开销，对短输入还没摊薄成本就先付了固定开支。大力士去搬一只蚂蚁，力气都花在热身上了。小文件用 gzip 通常比 bzip2 划算，就是这个道理。

有损压缩是另一回事

上面说的全都是无损压缩，解压后和原始数据一个字节都不差。

还有一类叫有损压缩，它会主动扔掉一些信息，换取大得多的压缩率。JPEG 就是这样：它把图像切成 8×8 的小块，做一次离散余弦变换，然后把高频细节（人眼不敏感的部分）粗略量化掉。丢掉的那些细节，你肉眼看不出来，但数据上确实没了。

音频的 MP3、视频的 H.264、以及新一代的 AVIF 和 AV1，都是这个路子，只是利用的是听觉和视觉的心理特性。

这是压缩能突破香农极限的唯一方式：改变游戏规则，不再要求”完全相同”。香农熵管的是无损压缩的下限，有损压缩不在这个坐标系里。

容器和算法是两件事

这是新手最容易混淆的地方，值得单独拎出来。

tar 只打包，不压缩。它把一堆文件首尾相接拼成一个大文件，加上每个文件的名字、权限、时间戳。拼完的文件通常比原来还大（多了那些元数据），但它把”很多小文件”变成了”一个大文件”。

gzip 只压缩，不打包。它处理一个字节流，输出一个字节流，不知道什么叫”文件名”。

所以要归档一堆文件，得两步：先 tar，再 gzip，得到 .tar.gz。

zip 两件事都干，因为它的格式是专门为此设计的（中央目录里存文件名）。

这个区别在压缩率上能差多少？我拿 200 个内容相似的小文件测了一遍：

1
2
3

原始合计        55,490 bytes
分别 gzip       48,029 bytes
tar 后 gzip      5,027 bytes    ← 省了 90%

同样的数据，同样的算法，差出近十倍。

原因还是那个滑动窗口。每个小文件单独压缩时，算法只能看见这一个文件内部的重复。而每个文件里都有一段相同的中文段落，这段文字在 200 个文件里重复了 200 次，分头压的时候完全利用不上。打包成一个大文件后，第 2 个文件里的那段话和第 1 个文件的完全一样，LZ77 一句”往回数 3000 个字节，复制 150 个”就打发了。

打包和压缩是两个正交的维度，把”相关的数据放在一起”本身就是一种压缩手段。这就是 tar 存在的理由。

八、反过来想：什么时候不该压缩

前面全在讲压缩怎么有用，但芒格那句”反过来想”在这里同样适用。列一下压缩帮倒忙的情况：

数据本来就小。几十字节的配置文件压一下，头部固定开销比省下的还多。

数据已经接近随机。加密过的数据就是典型。加密的设计目标之一就是让输出不可预测（消除规律），这恰好也让它不可压缩。所以你不需要给加密文件加压缩，也不会成功。

要频繁随机读取。压缩文件要读取中间某个位置，得先解压前面全部内容（除非用支持随机访问的格式）。数据库和日志系统宁可少压一点，也要保证随机读的快。

要写入的流式数据。一边写一边压，一旦中间出错，整个流可能全废，而且没法回退修改前面的内容。

最重要的一条：压缩是在拿计算换空间。当空间不贵（今天的硬盘很便宜）而计算贵（CPU 时间、电量、延迟）的时候，这笔交易是亏的。很多系统默认关掉压缩，就是这个原因。

把这些和前面的收益放在一起看，压缩的决策其实很清楚：有规律可压、体积值得压、不需要随机访问、计算资源有余，这四个条件同时成立，压缩才划算。

九、回到那三个问题

为什么压缩能让文件变小？

因为文件里有规律。压缩算法找出这些规律（重复的内容、偏斜的符号频率），用更短的写法表达同一份内容。你损失的是”啰嗦”，不是”信息”。

为什么有的文件压不动？

因为它已经没规律可捡了。随机数据和加密数据每个字节都是独立均匀的，熵接近 8 bit/字节，压缩算法面对它无计可施，还要倒贴头部开销，所以压完变大。已经压过的文件（JPEG、PNG、MP4）接近这一类，但未必完全无规律，偶尔还能再挤出一点。

为什么套娃不管用？

因为第一层已经捞走了绝大部分油水，后面的每一层能捞到的越来越少，而每层都要新增自己的头部开销。收益递减，成本叠加，很快就开始亏。实测里 gzip 第二层还能从 1128 压到 292，第三层就掉头向上了。

这三件事其实是同一条规律的三种表现：压缩的收益来自规律，规律的多少决定压缩的空间，规律被榨干之后，任何额外的压缩动作都只是在增加开销。

十、自己动手

想真明白，跑一遍最快。用不到二十行代码就能全部复现：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

import gzip, os, io, zipfile

# 1. 看压缩率和熵的关系
data = open("某个文件", "rb").read()
print("原始:", len(data), "压后:", len(gzip.compress(data, 9)))

# 2. 看随机数据会不会变大
import os as _os
rnd = _os.urandom(300_000)
print("随机数据:", len(rnd), "→", len(gzip.compress(rnd, 9)))

# 3. 看套娃
d = data
for i in range(5):
    d = gzip.compress(d, 9)
    print(f"第 {i+1} 层: {len(d):,}")

# 4. 看 tar 和 gzip 的分工
# tar 只打包不压缩，gzip 只压缩不打包，这就是为什么需要 .tar.gz

如果只让你做一个实验，做第三个。看着那个数字先猛掉、然后回头上涨，比读十页论文都清楚。

十一、最后

压缩这件事有意思的地方在于，它的道理简单到一句话就能说完：把重复的东西写成一次，其他地方引用回去。但这句话往下挖，能挖出 LZ77 的滑动窗口、Huffman 的变长编码、BWT 的块变换、香农的熵下限、以及整个文件格式的设计取舍。

ZIP 格式里那个”目录写在文件最后”的设计，LZ77 里”只往回看 32 KB”的限制，bzip2 在小文件上的劣势，tar 和 gzip 分成两个工具，每一个都是具体的设计决策，每一个都有它要解决的问题，也都有它留下的遗憾。理解这些取舍，比记住”ZIP 能压缩文件”有用得多。

最后留一句给以后会踩的坑：压缩不是一种让文件变小的魔法，它是一种用计算换空间的交易。既然它是交易，就有划算和不划算的时候。看清这笔交易的两头，就知道什么时候该压，什么时候该算了。

什么是均摊复杂度？均摊分析？

上篇文章里我们聊了复杂度和它那个偷懒的写法，大 O。这次聊一个更刁钻的问题。

你妹妹的书包又出场了。她每次往书包里塞一本作业本，就是一次操作。书包满了怎么办？只能换一个更大的书包，然后把旧书包里的本子一本一本倒进新书包。

现在问题来了：“往书包里放一本本子”这个操作，到底有多快？

• 平时：掀开盖子塞进去，一秒钟。
• 换书包那次：要把旧书包里所有本子全部倒过去，本子越多越慢。

如果只盯着最坏那一次，你会说：这个操作很慢，跟本子数量成正比。但如果盯着整个过程，你会发现换书包的次数少得可怜。

同一个操作，两个完全不同的答案。 均摊分析就是用来处理这种事的。

一、先说清楚：均摊不等于”平均”

这是我见过最多人搞错的地方，所以放在最前面。

听到”均摊”两个字，很多人立刻想到”平均”。然后就想：平均嘛，就是对所有情况取个平均。

不是这么回事。

平常说的”平均复杂度”，背后藏着一个概率假设。比如快排的平均复杂度是 $O(n\log n)$，这个”平均”的意思是：假定输入数据是随机排列的，在这种假定下取平均。如果对手故意构造一组最坏数据喂给你，快排立刻掉到 $O(n^2)$。

均摊复杂度不一样。它不需要任何概率假设，也不需要假定输入是随机的。它说的是：

连续做 n 次操作，总代价除以 n，是多少。

这个结论对任意操作序列都成立，包括最坏的那种序列。它不是”通常情况下的平均值”，它是”无论如何，摊到每一次头上都不会超过多少“。

一句话区分：

所以”均摊 O(1)”是一个非常硬的结论，比”平均 O(1)”硬得多。

二、动态数组：这件事的最好的例子

现在回到书包，我们把这件事写成代码。

Python 的 list 和 C++ 的 vector 都是动态数组。它们一开始分配一块固定的内存，你往里加元素，加满了，它们就悄悄做一件事：申请一块更大的内存，把老数据全部搬过去，再继续往新地方加。

1
2
3
4

# Python：往里加元素
a = []
for i in range(1000):
    a.append(i)      # 大多数时候很快，偶尔触发一次"搬家"

1
2
3
4

// C++：同样的事
std::vector<int> v;
for (int i = 0; i < 1000; ++i)
    v.push_back(i);  // 满了就重新分配 + 搬数据

关键问题是：新内存申请多大？

如果每次只多申请一格，那就灾难了。每加一个元素都要搬一次家，搬 m 个元素要 m 步，做 n 次就是 $1+2+\dots+n = O(n^2)$。这时候 append 就真的变成 $O(n)$ 了，没人用得起。

实际的做法是倍增：满了就开两倍大。于是搬家发生的时机是第 1、2、4、8、16……次。

那么 n 次 append 一共搬了多少个元素？

这是一个等比数列求和。用初中就学过的方法：设

反过来写一遍：

两个式子相加，每一项都变成 $2 \times$ 对应的项，中间全部消掉：

所以搬运的总代价小于 $2n$。再加上 n 次插入本身：

这是均摊分析里最干净的一个推导，值得记住。 贵的操作不是消失了，是它们出现的次数足够少，少到可以被便宜的操作分摊掉。

三、实测：那些”偶尔很贵”的操作到底长什么样

上面是数学。我更喜欢看真的东西，所以我在自己机器上跑了 30 万次 append，把每一次花的时间都记了下来。

看图一。纵轴是对数刻度，也就是说每一格差 10 倍。绝大多数点趴在底下，那是一次普通的插入。红色的竖线是扩容的位置，一共 76 条。尖刺就是从这些线上窜起来的。

具体数字：

注意中位数和平均差了 4 倍多。原因是那 76 次扩容（占总数的万分之二点五）非常贵，把平均值整个拉了起来。

现在关键的一步在这里：

图二横轴是”已经 append 了多少次”（对数轴），纵轴是”到目前为止平均每次耗时”。你会看到这条线一开始剧烈波动，然后越来越稳，最后趴在 676 纳秒附近不动了。

这条平稳的线就是”均摊 O(1)”的真身。 它不是对某一次操作的预言，它是总账除以次数的结果。扩容还会不时发生，尖刺还会不时出现，但累计平均不会再涨上去。

我又用 C++ 的 std::vector 跑了一遍同样的规模：中位数 29 纳秒，平均 65 纳秒，最慢一次 722,283 纳秒。最慢比中位数慢了将近 25,000 倍。 这个倍数听着吓人，但它仍然是均摊 O(1)，因为它在 30 万次里只出现了 20 次。

四、三种分析方法

均摊分析不是只有一种做法。教科书里讲了三种，我按好用的顺序说。

方法一：聚合法

就是上面做的那件事：先把 n 次操作的总代价算出来，再除以 n。

适合”整体好算、单次不好算”的情形。动态数组和二进制计数器都属于这一类。

方法二：记账法

这个方法最像生活。思路是：每次便宜操作的时候，多收一点钱存着；等到昂贵操作发生时，从存款里付。

拿 append 举例。假设每存一个元素收费 3 块：

• 1 块用来完成这次插入；
• 2 块存进一个”搬家基金”。

等到需要搬家时，要复制 m 个元素，花 m 块。而搬家基金里有多少钱？从上次搬家到现在，一共插入了 $m/2$ 个元素（因为容量翻倍），每个存 2 块：

正好够付。

这个推导里最漂亮的地方在于：我们不需要知道搬家什么时候发生，只需要保证存款始终够用。这就叫”用便宜的操作给贵操作预付”。

方法三：势能法

记账法很直白，但它有个弱点：你得凭直觉去设”收费多少”。势能法把这个直觉变成了公式。

定义一个函数 $\Phi$，叫势能，表示数据结构当前”存了多少没付的账”。第 i 次操作的均摊代价定义成：

其中 $c_i$ 是真实代价，$D_i$ 是第 i 次操作后的状态。

这一行读出来就是：均摊代价等于真实代价，加上这次操作为未来存下的账。

把 n 次加起来，中间的势能项会一路对消：

只要 $\Phi(D_n) \ge \Phi(D_0)$，就有 $\sum \hat{c}_i \ge \sum c_i$。也就是说，用均摊代价去估计总代价，只会高估，不会低估，这是安全的。

对动态数组，取 $\Phi = 2 \times \text{size} - \text{capacity}$（size 是元素数，capacity 是已分配的空间）。不扩容时，每次操作势能增加 2，均摊代价 $1 + 2 = 3$；扩容那一次，势能大幅下降，正好把真实代价抵消掉，均摊还是 3。

三种方法算出来的都是同一个数。聚合法最好懂，记账法最直观，势能法最通用，也最难看懂。工程上你几乎不会真的去写势能函数，但是读论文的时候会碰到它。

五、再练一个：二进制计数器

这是均摊分析的另一个标准例子，我拿它又跑了一次实测。

一个 $k$ 位的二进制计数器，从 0 开始，每次 +1。加的时候可能会有连锁进位，比如 7 变成 8：

这一下翻动了 4 位。看起来很贵。那么每次 +1 平均翻几位？

数一下：第 1 位每次 +1 都翻；第 2 位每 2 次翻一次；第 3 位每 4 次翻一次。所以 n 次自增的总翻转次数是：

均摊到每次：

我实测了 1 到 5000 的自增：平均每次翻转 2.00 位，最坏一次 13 位。

图三左边是每一次 +1 翻了几位，右边是累计平均。看右边那条绿线，它稳稳地落在 2 上，和理论值一模一样。左边那些高高低低的柱子（最坏 13 位）全都被平均掉了。

理论值 2，实测 2.00。这种对上号的感觉，比读十页证明都让人踏实。

六、均摊分析有个重要的限制，别用错地方

写到这里必须停一下，说个容易被忽略的事。

均摊 O(1) 不保证每一次都快。

它保证的是”总的账摊下来很便宜”，它对单次操作没有任何承诺。上面那个 C++ 测试里，有一次 append 花了 722 微秒，是从前一次的一万倍以上。均摊分析对此完全不否认，它只是说：这种破事很少发生。

所以在有些场景里，均摊结论不管用：

• 实时系统。 如果一个操作必须在 100 微秒内返回，那平均下来再便宜也没用。你碰上那一次 722 微秒的，就是事故。
• 延迟敏感的交互。 游戏、音视频编辑、交易撮合，用户能感觉到卡顿。偶发的长停顿会被直接投诉。
• 对最坏情况有硬性要求的算法。 比如某些安全协议要求严格的时间上界，你不敢用一个偶尔会抽风的操作。

这类场合需要的不是均摊保证，是最坏情况保证。有些数据结构专门做了这个取舍，比如用”每次搬一点、分散着搬”的办法（增量式 rehash、实时队列），代价通常是要维护更复杂的结构。

同一个结论，在不同的场景里价值完全不同。 判断一个结论能不能用，先看它对”最坏一次”作不作承诺。

七、工程里还有一堆均摊

均摊分析不是学术摆设，它是很多你天天在用的东西的基础。举几个：

• 哈希表扩容。 元素多了要扩大桶数组、重新分配所有元素。单次很贵，均摊之后插入还是 $O(1)$。Python 的 dict、C++ 的 unordered_map、Java 的 HashMap，背后都是这套。
• 并查集。 路径压缩加按秩合并，单次操作的最坏代价不好看，但均摊下来是 $O(\alpha(n))$。$\alpha$ 是反阿克曼函数，对任何现实中的 n 都不会超过 4。这是均摊分析里最著名的结果之一。
• 单调栈 / 单调队列。 每个元素最多进栈一次、出栈一次，所以整个过程是 $O(n)$，哪怕某一次操作会连着弹出一大堆。
• 伸展树。 单次操作可能是 $O(n)$，均摊是 $O(\log n)$。
• KMP 的失配跳转。 看着那个 while 循环会回退很多步，但整个匹配过程是线性的。

它们有个共同点：昂贵的动作不会凭空消失，但它的总次数被某个不变量卡住了。 找到那个不变量，就是均摊分析的全部工作。

八、我不知道的部分

有几个地方我不想装懂。

• 三种方法是等价的吗？ 对同一份分析，它们给出的界是一样的，聚合法和记账法在数学上可以互相翻译。但具体到某个问题上用哪个更顺手，是经验问题，我承认我是靠试。
• 势能函数怎么找？ 教科书教的是”定义成这个就对了”，但没人告诉你第一眼怎么猜出来。我的经验是：先看昂贵操作发生时，哪个量会突然变小，把它反过来当势能。这是技巧，不是方法。
• 这篇里的所有实测数据都来自我这台机器的一次运行。 不同机器、不同编译器、不同时刻，绝对值会差很多倍。但中位数和平均值之间那种数量级的差距，以及累计平均会收敛这件事，是稳定的，那才是均摊分析在说的东西。

九、一句话记住

均摊分析问的问题只有一句：

做 n 次操作，总账除以 n，是多少？

它跟”平均情况”最大的区别是：它不需要你假设输入长什么样。 这是它硬气的地方。

再用一句话配上一个动作：

路上偶尔有个坑，不代表这条路平均速度很差；
但如果你开的是救护车，你就得管那个坑到底有多深。

十、自己试

照旧，读是没用的。

1. 亲手看见尖刺。 用 30 万次 append，把每一次的耗时记下来画散点图。你会亲眼看到那 76 根尖刺。
2. 把倍增改成加一。 自己写一个”每次只多申请一格”的动态数组，跑同样规模，对比耗时。你会第一次真切感觉到：均摊 O(1) 不是白来的，是靠一个具体策略换来的。
3. 算一个你自己的例子。 找一个你项目里”偶尔会慢”的操作，数一数它到底多久发生一次，用总代价除以总次数算一算。很多时候你会发现它根本不是问题，只是那一次很难看。

如果你算完发现它真的有问题，恭喜你，你已经学会均摊分析了。

时间复杂度与空间复杂度详解

时间复杂度和空间复杂度，是衡量算法效率的两个核心度量。下面从”数一数”这种最直观的方式讲起，给出大 O 的形式化定义，配上 C++ / Python 双版本代码、公式推导和三张图，中间点几个常见误区，也说说这篇讲不到的地方。

这两天在教一个小孩子学习算法，用一种简单的思维讲解时间复杂度和空间复杂度。

一、先别管名字，来数一数

假设你妹妹让你帮她在书包里找一本作业本。

书包里有 3 本本子的时候，你抓两下就找到了，用了 2 秒。
书包里有 30 本本子的时候，你要翻一会儿，用了 20 秒。
书包里有 300 本本子的时候，你翻了两个小时。

现在我问你一个问题，“找本子”这件事，到底”有多快”？

你可能会说：”2 秒。”

错。2 秒是书包里有 3 本时的答案。 本子变成 300 本，答案就变成了两个小时。

所以真正要问的，是下面这句话。

本子每多一倍，我要多用多少时间？

这就是”复杂度”这个词真正在问的东西。它不关心你跑得多快，关心的是东西变多了以后，你变慢的速度有多快。

我觉得这是理解复杂度的唯一入口。如果你记住了 O(n²) 这四个字符，但不知道它在问这个，那你只是在背咒语——飞机不会因为机场修得像飞机场就降落。

二、大 O：一种”只留主干”的写法

我妹妹真正找本子的动作是这样的：

1
2
3
4
5

翻开第 1 本 → 不是
翻开第 2 本 → 不是
翻开第 3 本 → 不是
...
翻开第 n 本 → 找到了

一共翻了 n 次。（n 就是本子的数量。）

如果每翻一本要花 0.1 秒，还要先花 2 秒拉开书包拉链，那总时间是：

翻本子的力气（0.1n）是主角，拉开书包拉链那两秒（+2）是个跑龙套的。

现在把 n 取几个数：

看最后一列，n 从 100 涨到 10000（100 倍），总时间从 12 涨到 1002，涨了大约 83 倍。

再看 0.1n 这一项，12 里它占 10，1002 里它占 1000。它一直是主角。 而那个 +2（拉链的时间）在 n 很小的时候还有点存在感，n 一大就完全不算数了。

这就是大 O 的全部秘密。

当 n 变得很大很大时，只留下涨得最凶的那一项，把前面的系数和后面加的小尾巴都扔掉。

写成数学语言，就是：

这就像报身高，1.83 米报成 1.8 米，没人跟你较真那 3 厘米；报成 2 米，那就要吵一架了。

更严谨一点，大 O 的定义是：存在两个正常数 $c$ 和 $n_0$，使得对所有 $n \ge n_0$ 都有

就是「不管你怎么跑，我这条线永远压在你头上」。大 O 是一根天花板，它不保证贴得多近，只保证你撞不穿。

这时我们就写 $T(n) = O(f(n))$。翻译成人话就是，

“从某个 n 开始，它的增长速度不会超过 f(n) 的某个倍数。”

注意这里我用了”增长”和”不超过”，大 O 说的是一根上限，不是一个精确值。 它天生就是个偷懒的写法，而且这个偷懒是第一流的。因为当 n 足够大时，你根本不需要知道精确值，你只需要知道它在怎么涨。

三、五种涨法（图一）

把最常见的那几种”涨法”画出来，你会一眼看懂为什么计算机老师总在念叨它们：

图一，横轴是数据量 n，纵轴是要做的操作次数。注意红色那条 O(n²)，它一开始很谦虚，到后面直接冲上天。

我用找本子来翻译这五条：

这里有个特别容易搞混的点。你一定会听到有人说”$O(n)$ 比 $O(n^2)$ 快”，这句话不完全对。

它准确的说法是，当 n 足够大的时候，$O(n)$ 才一定比 $O(n^2)$ 快。 n 小的时候，一条 O(n²) 的代码完全可能跑赢一条 O(n) 的代码，只要它每条指令写得更精简。

看图二你就明白了。同一份代码，n=8 的时候两条线几乎贴在一起，你根本看不出谁好谁坏；n=60 的时候，一个上一个冲天。

这是我见过的、最值得记住的一件事：如果数据不够大，你测出来的快慢可能是假的。

我是做工程的人，对这种事特别敏感——实验做得不对，数据就会骗你，而且它骗得特别自然，让你觉得你懂了。

四、例子一：找人（$O(n)$ 对上 $O(\log n)$）

现在上代码。同一件事，我们写两种做法。

做法 A：一本一本翻（$O(n)$）

1
2
3
4
5
6

# Python
def 线性查找(名单, 目标):
    for 名字 in 名单:        # 从头看到尾
        if 名字 == 目标:
            return True
    return False

1
2
3
4
5
6

// C++ —— 同一件事
bool linear_search(const vector<string>& names, const string& target) {
    for (const auto& n : names)   // 从头看到尾
        if (n == target) return true;
    return false;
}

最坏情况下要看 n 次。所以：

做法 B：每次砍掉一半（$O(\log n)$）

但是，如果名单是排好序的（比如按拼音排好），你就能干一件聪明得离谱的事。

先翻中间那本。

• 如果中间这本的拼音在你找的名字前面，那你要找的肯定在后半边，前边一半整块扔掉。
• 如果在后面，后边一半扔掉。

每翻一次，名单就少一半。

1
2
3
4
5
6
7
8
9
10
11
12

# Python
def 二分查找(有序名单, 目标):
    左, 右 = 0, len(有序名单) - 1
    while 左 <= 右:
        中 = (左 + 右) // 2
        if 有序名单[中] == 目标:
            return True
        elif 有序名单[中] < 目标:
            左 = 中 + 1        # 扔掉左半边
        else:
            右 = 中 - 1        # 扔掉右半边
    return False

1
2
3
4
5
6
7
8
9
10
11

// C++ —— 同一件事
bool binary_search_sorted(const vector<string>& a, const string& target) {
    int lo = 0, hi = (int)a.size() - 1;
    while (lo <= hi) {
        int mid = lo + (hi - lo) / 2;   // 这么写是为了防止 lo+hi 溢出
        if (a[mid] == target)      return true;
        else if (a[mid] < target)  lo = mid + 1;  // 扔掉左半边
        else                       hi = mid - 1;  // 扔掉右半边
    }
    return false;
}

为什么是 $\log$？我们来推一下。n 本本子，每次砍一半：

像剥洋葱，每次把剩下的对半撕。只不过这个洋葱剥 20 层就没了——哪怕它有 100 万片。

砍了几次？设砍了 k 次：

这就是 log 的来历。「我要撕几次才能把这一摞纸撕成一张？」答案给出来就是 $\log_2 n$。所以撕 100 万张纸只要 20 下，因为纸是成摞撕的。

所以：

log 是复杂度里的「温柔型选手」，数据翻一倍，它只多干一趟活。

这两个差多远？我给你算个实在数。一本 100 万条的名单：

• 做法 A：最坏要找 1,000,000 次。
• 做法 B：$\log_2 1000000 \approx 20$ 次。

20 次。

我第一次算这个的时候是有点恼怒的。你想，你妹妹找本子找两个小时，你只消翻 20 下。就这么个”每次都从中间下手”的笨办法，把人家的两个小时变成了 20 下。这不是什么高深技巧，无非是换了个问法，不问”下一个在哪儿”，问”它可能在左半边还是右半边”。

这就是我一直在说的事。不懂的东西你没法简单地说出来，等你真能简单地说出来了，你会发现它本来就很朴素。

（顺便：C++ 标准库的 std::binary_search、Python 的 bisect 模块，干的就是这件事。别人已经写好了，你直接叫即可。）

五、例子二：两两都比较（$O(n^2)$），以及它为什么可怕

给你一个名单，问你：谁和谁同名？

最笨的做法，是让每个人跟其他每个人都比一遍：

1
2
3
4
5
6
7

# Python
def 找重名(名单):
    for i in range(len(名单)):
        for j in range(len(名单)):     # 注意这个内层循环
            if i != j and 名单[i] == 名单[j]:
                return (名单[i], 名单[j])
    return None

1
2
3
4
5
6
7
8

// C++ —— 同一件事
pair<string,string> find_duplicate(const vector<string>& a) {
    for (size_t i = 0; i < a.size(); ++i)
        for (size_t j = 0; j < a.size(); ++j)
            if (i != j && a[i] == a[j])
                return {a[i], a[j]};
    return {};
}

为什么会变成 n²？因为这是两层循环：外层跑 n 次，每跑一次内层又跑 n 次。乘起来：

两层循环不神秘，就是「每个人挨个跟所有人握手」，握手次数 = 人数 × 人数。人一多，握到手软。

看图二右边那条红色曲线，那就是它。

为什么我说它可怕？拿数字说话：

注意这个感觉，n 变 1000 倍，时间变 1,000,000 倍。这就是平方的恐怖之处，它慢得越来越离谱。

所以我让你记住一句话：

一个 $O(n^2)$ 的算法能不能用，不取决于你的电脑有多好，取决于 n 会不会长大。

电脑快 4 倍，你只能扛住 n 翻一倍。而现实里的数据，往往不止翻一倍。

六、例子三：排序，以及为什么好的排序是 $n\log n$

排序的朴素做法是：每次从剩下的里面挑一个最小的放前面（选择排序）。挑一个要扫一遍，扫 n 次：

挑出最小的放前面，每挑一次都得把剩下的人全体扫一遍。你这不是在排序，你是在点名，而且每挑一个都重新点一次名。

而聪明做法（归并排序、快速排序）的核心思想是：先把问题切一半，解决两个小问题，再拼起来。

「把活儿劈成两半干（$2T(n/2)$），干完再花点力气粘回去（$O(n)$）」，分治的哲学就这一句，会分活儿的人不吃亏。

这个式子的意思是一行一行读出来：

• $T(n)$：排 n 个数要花的时间；
• 右边：分成两个 n/2 的问题（两个 $T(n/2)$），
• 再花 O(n) 把它们拼回一起。

解这个式子（一层层展开，得到 $\log n$ 层，每层总共 O(n)）：

听起来很唬人，其实只是「n 个东西，每个花 $\log n$ 步就找到自己的位置」。这是排序界的天花板。

对比一下（还是 100 万条）：

这就是为什么全世界的库函数里，排序都不用”挑最小”那种笨办法。 这跟学术洁癖没关系，差的是 5 万倍。

七、空间复杂度：不光要能跑，还要占得住

到这里我们一直在数时间。但还有另一半故事：它要占多大地方。

这个不难理解。你去搬东西：

• 时间=你跑了几趟；
• 空间=你要多大的仓库。

空间复杂度问的是同一类问题：

数据量 n 变大，占用的内存会涨多快？

看这段代码：

1
2
3
4
5
6

# 空间 O(1)：不管 n 多大，只多用一个格子
def 求和_循环(列表):
    总数 = 0                      # 一个变量
    for x in 列表:
        总数 += x
    return 总数

1
2
3
4
5
6

// C++ —— 同样是 O(1)
long long sum_loop(const vector<int>& v) {
    long long total = 0;          // 一个变量
    for (int x : v) total += x;
    return total;
}

再看这个：

1
2
3
4
5

# 空间 O(n)：每次递归都新开一份
def 求和_递归(列表):
    if not 列表:                 # 基线情形
        return 0
    return 列表[0] + 求和_递归(列表[1:])

1
2
3
4
5

// C++ —— 同样是 O(n)
long long sum_rec(const vector<int>& v, size_t i = 0) {
    if (i == v.size()) return 0;
    return v[i] + sum_rec(v, i + 1);   // 每一层都还没返回
}

为什么递归是 O(n) 空间？ 因为计算机执行递归，就像你打电话找人，每一层的人都在线上等着，谁都没挂。第 1 层调用第 2 层，第 2 层调用第 3 层……到第 n 层时，前面 n 层全都在内存里挂着。看图三右边，那摞起来的柱子就是这个意思。

一个我必须说实话的地方：这段 Python 里 列表[1:] 还会额外复制一份新列表，所以它其实更浪费。真正的工程写法会用下标 i 往前挪（像上面那段 C++ 那样），避免复制。这算个挺好的教训，代码怎么写，直接决定复杂度。 我一开始举这个例子就是为了让你看见它。

八、最有用的那一招，空间换时间

如果你今天只带走一件事，带走这个。

回到第五节那个”两两比较找重名”。有没有办法不找死？

有。开个登记本。

1
2
3
4
5
6
7
8

# 空间 O(n)，时间 O(n)
def 找重名_快(名单):
    登记本 = set()                 # 用一点额外空间
    for 名字 in 名单:
        if 名字 in 登记本:          # 查登记本几乎是瞬间
            return 名字
        登记本.add(名字)
    return None

1
2
3
4
5
6
7
8
9

// C++ —— 同一件事
optional<string> find_dup_fast(const vector<string>& a) {
    unordered_set<string> seen;    // 用一点额外空间
    for (const auto& n : a) {
        if (seen.count(n)) return n;
        seen.insert(n);
    }
    return nullopt;
}

我们干了什么？我们多花了一点内存（那个”登记本”），换来时间从 $O(n^2)$ 变成 $O(n)$。

n=100 时：从 10,000 次比较，变成 100 次。图三左边那两根柱子就是这个对比。

代价是：多占 O(n) 的内存来存登记本。

这是一笔交易。 时间和空间本来就是一对可以互换的东西，你几乎总是在拿一个换另一个。整个计算机科学里一半的工程技巧，说到底就是在做这笔买卖。

九、别骗自己：三个常见的自欺

这一段是我最想说的。因为复杂度这东西，特别容易让人假装懂了。

① “我测过了，它很快。”

看图二。n=8 的时候，$O(n^2)$ 和 $O(n)$ 的线是重合的。你用 8 个数据测，然后下结论说”我的代码没问题”，这在实验设计上就是个错误。你没测错，你只是测了一个不说明任何问题的东西。

② “我用了最新的库，所以肯定快。”

用了复杂算法库里最快的函数，不代表你的那段代码变快了。工具是形式，你的算法才是实质。去掉工具的名字，看你的代码在做什么，这才是真的。

③ “大 O 越大就越慢。”

不对，是”n 够大以后越慢”。$O(n^2)$ 的 C++ 代码跑赢一个 $O(n)$ 的 Python 代码，太正常了。大 O 比较的是自己和自己在不同 n 下的表现，不是两门语言打架。

十、我不知道的部分（以及它为什么不丢人）

我不想让这篇文章显得比它实际的样子更完整。有几个地方我要说清楚：

• 大 O 只是”上限”，它不管你平时的实际快慢。现实中还有”平均复杂度””最坏复杂度”的区别。快速排序最坏是 $O(n^2)$，但你天天在用它，因为它平均是 $O(n\log n)$，而且常数很小。“理论最坏”和”实际天天”完全是两回事。
• 常数真的会被忽略吗？ 数学上会。工程上不会。一个常数是 1000 的 $O(n)$ 算法，在 n 小于某个数之前，跑不过一个常数是 1 的 $O(n^2)$。所以真实的程序里要”两个都写，小了用笨的、大了用聪明的”，这个技巧叫混合策略，Python 和 C++ 的排序里都藏着它。
• 内存的”快”不止一层。 你的 CPU 里有一层层的缓存（缓存比内存快几百倍）。两个复杂度一样的算法，谁把数据摆得更近，谁就真快。这部分（cache-oblivious、内存局部性）我不知道得足够深，就不装懂了。
• 我这篇文章里的所有时间估算（比如”1 微秒一次比较”）都是为了让你有感觉的随手假设，不是实测数据。真要看真实数字，你得自己在你的机器上跑一遍，而且要用足够大的 n。

最后一条我不知道，但我认为它比前面所有我知道的都重要：

“我不知道”不是终点。它是你唯一能站上去的地板。

十一、一句话，带走就行

如果你明天全忘了，只记得一句话，我希望是这句：

「东西变多了，你会怎么变慢」，这才是复杂度真正在问的。

再用一句话配上一个动作：

$O(1) < O(\log n) < O(n) < O(n\log n) < O(n^2)$

这条链背下来比背单词有用。但它有个前提，「n 足够大的时候」。不加这五个字，这条链就是耍流氓。

但顺序里那个”<”要加前缀：「n 足够大时」。

十二、自己试（别光看，看没用）

我最后想说：这篇文章你读完，你什么都没学会。

难不难先不说，光读不算学。要用上手，你得自己动手。给你三个练习，每个都只要几十行：

1. 亲手做个实验：把第四节的两个查找函数各写一遍，n 取 1000、10000、100000，真的计时，把结果画成表格。
   你会看到你的电脑”骗”了你多少次。
2. 把 $O(n^2)$ 改成 $O(n)$：用第五节的”找重名”，先用双重循环，再用哈希表，n 取 10000，比较真实耗时。
   你会第一次真切体会”空间换时间”不是一句口号。
3. 把它讲给别人：找一个完全不懂编程的人，用找本子这个例子给他讲一遍二分查找，直到他问出”那为什么不一开始就翻中间”，到那一刻你就懂了。

如果你讲不清楚，别急着说自己笨。说不清楚的地方，正是你还没懂的地方。 这就是我全部的方法，没什么神秘的。