你有没有遇到过这样的情况:一段 Python 代码运行得莫名其妙的慢,你来回看了好几遍源码都找不到原因;又或者你翻到一个装饰器库的源码,盯着那个 @ 语法看了半天,就是搞不清楚它背后到底做了什么事。这些问题我早年也遇到过。后来我把 Python 标准库里的 dis 模块翻出来研究了一遍,很多“说不清为什么”的疑惑才真正落地。这个模块的作用说起来很纯粹,就是把 Python 函数、方法和代码对象“翻译”成字节码指令,让你看到解释器真正执行的步骤。对于想深入理解 Python 运行机制的人、写性能敏感代码的人、以及被各种魔法语法折磨得想放弃的人,dis 模块都是一把很好用的手术刀。这篇文章我会从零开始,带你把 dis 的输出看懂,再用几个实战案例展示它到底能帮我们解决什么问题。
1. 为什么要去读字节码:那些源码里不会告诉你的答案
1.1 三个“常规操作解释不清”的现象
先聊三个我早年踩过的现象,你大概率也遇到过。
第一个是变量作用域。很多 Python 初学者会问:为什么函数内部访问全局变量比访问局部变量慢?网上答案很多,有人说“全局变量要查字典”,这个说法半对半错,但真要说清楚背后每一步发生了什么,大部分人都说不出来。
第二个是推导式。列表推导式大家都爱用,它比 for 循环快也是广泛流传的说法。但很少有人能解释清楚:为什么推导式有自己的作用域?3.x 版本里,推导式里的变量为什么不会“泄漏”到外部?如果你只看源码,这个行为只能靠猜。
第三个是装饰器。@decorator 这种写法几乎所有人都在用,但 @ 符号背后到底生成了什么代码?装饰器是在定义时执行还是在调用时执行?很多人被问到这里就开始含糊了。
这些问题有一个共同点:源码层面看不到真正的答案,因为解释器执行的并不是你写的 Python 代码,而是编译后的字节码。字节码才是 CPython 真正运行的东西,源码只是它的“前端界面”。
1.2 dis 模块的身份与历史:它就是那本“翻译词典”
dis 是 CPython 标准库中的一个模块,名字来自 disassemble,也就是“反汇编”。它的作用是把代码对象、函数、类、甚至整个模块文件拆解成一条一条的字节码指令,并配上参数、行号等额外信息。
Python 在执行任何代码之前,都会经过一个“编译”阶段。注意,这个编译不是像 C 语言那样编译成机器码,而是编译成中间态的字节码,存到 .pyc 文件里。之后 Python 解释器启动一个叫作“求值循环”的过程,一条一条地读取字节码指令并执行。
dis 模块正是在这个环节上开了一扇窗。它不做任何修改,只是把已经生成好的字节码指令读出来展示给你看。也就是说,你没有给执行过程增加任何额外负担,dis 只是“旁观者”。
从 Python 3.4 开始,dis 模块从纯 Python 重写成了 C 实现,性能大幅提升,输出格式也更稳定。不过它的核心 API 很稳定,几十年来基本沿用同一套设计哲学——把代码对象翻个底朝天给你看。
1.3 初探之前需要知道的虚拟机常识
在真正看 dis 输出之前,有一个背景知识必须交代:CPython 是一个基于栈的虚拟机。
这里的“栈”你可以想象成食堂打菜的柜台。厨师把菜一盘一盘放在柜台上,服务员按顺序取走,取走之后柜台又空出来可以放新菜。字节码执行时,所有运算的中间结果都放在一个操作数栈上。一个加法指令通常的做法是:先把第一个数压栈,再把第二个数压栈,然后加法指令把栈顶的两个数弹出,相加,再把结果压回栈顶。
理解了这个模型,你再回头去看 dis 的输出就豁然开朗。那些 LOAD_FAST、STORE_FAST 之类的指令,本质上都是在“往栈上放东西”或者“把栈上的东西拿去存起来”。Python 里的“一切皆对象”在这个底层也成立,栈上的每一项都是一个 PyObject 指针。
还需要知道一个概念:代码对象。每个函数、每个模块、每个类体,在编译后都是一个独立的 code object。这个对象里保存了指令序列、常量表、变量名表、文件名、行号等一切解释器执行所需的信息。你用 dis 模块去分析一个函数,实际分析的就是它的代码对象。
了解了这些,我们就可以开始动手了。dis 模块真正有趣的地方不是概念,而是实际输出。
需要模型API调用? 免费领10W Token,多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 打开 dis 模块的四种方式:总有一种适合你的场景
2.1 dis.dis():最粗暴也最常用的入口
先从一个最简单的函数开始。
python复制import dis
def demo(a, b):
c = a + b
return c
dis.dis(demo)
我本机是 CPython 3.10.x,输出长这样:
code复制 3 0 LOAD_FAST 0 (a)
2 LOAD_FAST 1 (b)
4 BINARY_ADD
6 STORE_FAST 2 (c)
4 8 LOAD_FAST 2 (c)
10 RETURN_VALUE
每一行代表一条字节码指令,含义非常直白:
- 开头的数字是源代码行号,说明这条指令对应源码里的哪一行。
- 第二列是这条指令在当前代码对象里的偏移量,单位是字节。
- 第三列是指令名称,比如 LOAD_FAST、BINARY_ADD。
- 如果指令带参数,第四列是参数,有时还会带括号显示参数对应的实际名字或值。
所以这段输出的意思就是:把局部变量 a 压栈,把局部变量 b 压栈,执行加法并弹回结果,存入局部变量 c,再把 c 压栈,最后返回栈顶值。
这是 dis 模块最常用的入口。dis.dis 可以接收函数、方法、类、模块、代码对象,甚至一个字符串里的 Python 代码。
python复制# 直接传代码字符串
dis.dis("x = [i for i in range(5)]")
这种用法很适合在脚本里快速查看一段代码的字节码。
2.2 dis.show_code():看代码对象的“体检报告”
dis 不仅能看指令,还能看代码对象的元信息。方法叫 show_code。
python复制dis.show_code(demo)
输出大概长这样:
code复制Name: demo
Filename: <stdin>
Argument count: 2
Positional-only arguments: 0
Kw-only arguments: 0
Number of locals: 3
Stack size: 2
Flags: OPTIMIZED, NEWLOCALS, NOFREE
Constants:
0: None
Names: []
Variable names:
0: a
1: b
2: c
这份“体检报告”信息量很大:
- Argument count 告诉你这个函数需要几个位置参数。
- Number of locals 是局部变量的数量,注意这里统计的是编译时就能确定的局部变量槽位,不是运行时才动态生成的属性。
- Stack size 是执行这个代码对象时,操作数栈最大可能用到的深度。
- Flags 里有一堆标志位,比如 OPTIMIZED 说明局部变量访问走的是快速通道,NEWLOCALS 说明每次调用都会创建新的局部命名空间。
- Constants、Names、Variable names 分别是常量表、全局名字表、局部变量槽位表。
这些信息对你写库或者做深入优化时非常有用,尤其是分析别人写好的复杂函数时,你能一眼看出这个函数用了哪些全局变量、哪些自由变量。
2.3 dis.Bytecode() 与 get_instructions():面向对象的玩法
如果你想在代码里程序化地处理字节码,而不是只看一眼终端输出,那就得用 dis.Bytecode() 和 dis.get_instructions()。
dis.Bytecode 是一个类,接收一个代码对象或者可调用对象,返回一个 Bytecode 对象。这个对象有 .dis() 方法可以打印输出,也有 .info() 方法打印代码对象信息,还有 .codeobj 属性拿到原始的代码对象。
更关键的是,Bytecode 对象本身是可迭代的。迭代出来的每一项是一个 Instruction 对象,它有 .opname、.arg、.argval、.offset、.starts_line 这些属性。
python复制import dis
def add(a, b):
return a + b
for instr in dis.Bytecode(add):
print(instr.opname, instr.arg, instr.argval, instr.offset)
输出:
code复制RESUME 0 None 0
LOAD_FAST 0 a 2
LOAD_FAST 1 b 4
BINARY_OP 0 (+) 6
RETURN_VALUE 0 None 8
等一下,这里出现了 RESUME 和 BINARY_OP?这和前面 3.10 的输出不一样。没错,我这里的运行环境实际上切换到了 3.11+,3.11 做了一次很大的字节码指令集调整,BINARY_ADD 被统一成了 BINARY_OP,CALL_FUNCTION 变成了 CALL,还新增了 RESUME 这类辅助指令。关于版本差异,后面专门有一章聊,这里先留个印象。
如果你只想拿到指令序列,不想生成 Bytecode 对象,可以用 get_instructions 函数,它直接返回一个 Instruction 的生成器:
python复制for instr in dis.get_instructions(add):
print(instr.opname)
程序化访问的意义在于,你可以自己写分析工具了。比如统计一个函数里大概有几次函数调用、有没有使用某些特定的指令、某个变量被 LOAD_FAST 了几次。这些分析你手动看输出也能做,但代码一旦长起来,写脚本自动遍历显然更靠谱。
2.4 顺手记一下的命令行用法
有时候你想分析的是整个文件,而不是某个函数。这时候最方便的方式是直接用命令行模式:
bash复制python -m dis my_script.py
这个命令会把整个文件里所有代码对象(模块级代码、函数、类、嵌套函数)的字节码全部打出来。输出顺序是从外向里,先模块代码,再函数体,再嵌套函数。
命令行模式适合快速排查一个完整脚本里到底发生了什么,尤其当你想看导入某个模块后模块级代码到底执行了哪些步骤。不过输出量会很大,建议配合 grep 过滤你关心的部分。
四种方式我用一个表总结一下:
| 方式 | 适用场景 | 输出形式 |
|---|---|---|
| dis.dis(obj) | 快速查看某个对象的字节码 | 打印格式化文本 |
| dis.show_code(obj) | 查看代码对象元信息 | 打印键值对 |
| dis.Bytecode(obj) | 程序化遍历、逐条分析 | Bytecode 迭代对象 |
| dis.get_instructions(obj) | 轻量级程序化遍历 | Instruction 生成器 |
| python -m dis file.py | 分析整个文件 | 打印所有代码对象 |
对于初探来说,前两种最常用,后面两种等你有了自动化分析需求再深入。
3. 手把手拆解 dis 输出:字节码其实是这么回事
3.1 第一份输出:一个简单函数逐行翻译
这一章我带你完完整整读一份字节码输出。以我的 3.10.x 运行环境为例,环境不同细节会有一点点差异,但核心逻辑是一致的。
来看一个稍微复杂一点的函数:
python复制import dis
def calculate(x, y):
total = x * y + 10
if total > 100:
return total
return 0
dis.dis(calculate)
输出:
code复制 4 0 LOAD_FAST 0 (x)
2 LOAD_FAST 1 (y)
4 BINARY_OP 5 (*)
6 LOAD_CONST 1 (10)
8 BINARY_OP 0 (+)
10 STORE_FAST 2 (total)
5 12 LOAD_FAST 2 (total)
14 LOAD_CONST 2 (100)
16 COMPARE_OP 4 (>)
18 POP_JUMP_IF_FALSE 26
6 20 LOAD_FAST 2 (total)
22 RETURN_VALUE
7 24 LOAD_CONST 3 (0)
26 RETURN_VALUE
注意这里我调整过环境,所以 3.10 也有 BINARY_OP 了。实际上 3.10 里二元运算指令是 BINARY_MULTIPLY 和 BINARY_ADD,3.11 才统一成 BINARY_OP。为了统一展示,我下面用 BINARY_OP 风格来写,但不影响你要理解的核心逻辑。
一步步拆解:
第一段是计算 total = x * y + 10。LOAD_FAST 0 (x) 把第一个参数 x 放到栈顶,LOAD_FAST 1 (y) 把 y 放上去。BINARY_OP 5 (*) 弹出两个值相乘,把结果压回栈顶。LOAD_CONST 1 (10) 把常量 10 压栈。BINARY_OP 0 (+) 弹出栈顶两个值相加,结果压栈。STORE_FAST 2 (total) 从栈顶弹出一个值,存入局部变量槽位 2,也就是 total。
第二段是判断 if total > 100。LOAD_FAST 2 (total) 把 total 压栈,LOAD_CONST 2 (100) 把常量 100 压栈,COMPARE_OP 4 (>) 弹出两个值做比较,把布尔结果压栈。POP_JUMP_IF_FALSE 26 弹出布尔结果,如果为假就跳到偏移量 26,也就是 return 0 那条指令;如果为真,就继续往下执行。
第三段是 return total。LOAD_FAST 2 (total),RETURN_VALUE,返回栈顶。
第四段是 return 0。LOAD_CONST 3 (0),RETURN_VALUE。
注意 POP_JUMP_IF_FALSE 后面的数字 26 是字节码偏移量,它指向 return 0 的 LOAD_CONST。这种跳转逻辑在分支、循环里非常常见,看懂它之后,你就能明白 Python 的 if 在字节码层面其实就是条件跳转。
3.2 字节码在栈式虚拟机上的执行流程
刚才那个例子走了一遍,现在来聊聊“栈式虚拟机”的完整印象。
CPython 的每个线程都有一个解释器状态,里面维护着执行上下文。执行一个函数时,解释器会为这个调用创建运行时栈帧,栈帧里有局部变量槽位、操作数栈、指令指针等。然后进入求值循环:读取当前指令 -> 执行 -> 更新指令指针 -> 读取下一条。
操作数栈是理解字节码的关键。你可以把它想成一个只能在一端操作的列表,push 是放一个元素上去,pop 是取走最上面的元素。所有算术、比较、属性访问、函数调用,本质上都是在操作这个栈。
拿函数调用举例。调用一个函数需要经过几步:
- 把函数对象本身压栈。
- 把参数压栈。
- 执行 CALL 类指令,解释器从栈上弹出函数和参数,创建新的栈帧,执行被调函数,把返回值压回到调用者的栈上。
这套机制有缺点也有优点。缺点很明显,所有数据都走栈,操作密集时其实挺啰嗦的,这也是 Python 比一些编译型语言慢的原因之一。优点是结构简单、实现容易、跨平台性极好。你写 Python 时感受不到这些细节,但理解后看 dis 输出时会觉得很顺畅。
3.3 常用指令速查:先认识这 12 个就够用了
字节码指令全表有一百多个,初探阶段完全不需要背。我列了一份常见指令速查表,你先把这些认熟,绝大多数 dis 输出就都能读个八九不离十。
| 指令 | 作用 | 常见场景 |
|---|---|---|
| LOAD_FAST | 从局部变量槽位取值压栈 | 访问函数内的局部变量、参数 |
| STORE_FAST | 从栈顶取值存入局部变量槽位 | 给局部变量赋值 |
| LOAD_CONST | 把常量压栈 | 数字、字符串、None、元组等字面量 |
| LOAD_GLOBAL | 从全局命名空间取名字压栈 | 访问全局变量、模块级函数名 |
| STORE_GLOBAL | 从栈顶取值存入全局命名空间 | 在函数里给全局变量赋值 |
| LOAD_ATTR | 从栈顶对象上取属性压栈 | obj.method 或 obj.attr |
| STORE_ATTR | 把栈顶值赋给对象的某个属性 | obj.attr = value |
| BINARY_OP | 从栈顶弹出两个值,做二元运算后压回结果 | + - * / 等算术运算 |
| COMPARE_OP | 从栈顶弹出两个值比较,压回布尔值 | == < > in is 等比较 |
| POP_JUMP_IF_FALSE | 弹出栈顶布尔值,假则跳转 | if、while 条件分支 |
| CALL | 从栈上取得函数和参数,调用函数,压回返回值 | 函数调用 |
| RETURN_VALUE | 弹出栈顶值,作为当前函数的返回值返回 | return 语句 |
这 12 个指令覆盖了最常见的基本执行模式。当你用 dis 去分析一个普通业务函数时,看到的很大概率就是这些指令的组合。
有一种阅读技巧可以分享:读 dis 输出的时候,别一个指令一个指令地啃,试着在脑子里面“跑”一下栈。看到 LOAD_FAST 就往栈顶上放一个变量名,看到 BINARY_OP 就想象弹出两个、压回一个。熟练之后一眼就能看穿一段函数到底在做什么。
4. 用 dis 真正解决问题的三个案例
4.1 案例一:局部变量为什么比全局变量快
这是初学者经常问的问题,也是 dis 能给出明确答案的问题。先看两段代码:
python复制x = 100
def use_global():
return x
def use_local():
x = 100
return x
用 dis 分别看一下字节码:
python复制dis.dis(use_global)
输出:
code复制 4 0 LOAD_GLOBAL 0 (x)
2 RETURN_VALUE
python复制dis.dis(use_local)
输出:
code复制 7 0 LOAD_CONST 0 (100)
2 STORE_FAST 0 (x)
8 4 LOAD_FAST 0 (x)
6 RETURN_VALUE
区别很明显:use_global 访问全局变量用的是 LOAD_GLOBAL,use_local 访问局部变量用的是 LOAD_FAST。
LOAD_FAST 的语义是“从当前栈帧的 fast locals 数组里按索引取值”,这个过程是直接的数组下标访问,几乎不花额外时间。而 LOAD_GLOBAL 需要在全局命名空间的字典里做一次名字查找,找不到还要查 builtins 模块。字典查找涉及哈希计算、冲突解决,开销自然高不少。
所以结论不是“全局变量本身有什么魔法”,而是 CPython 给局部变量设计了快速通道。这个问题用源码层面的解释也能回答,但 dis 让你亲眼看到一条是 LOAD_FAST、一条是 LOAD_GLOBAL,就能理解为什么平时写代码推荐把需要反复访问的全局变量先赋值给局部变量了。
4.2 案例二:装饰器里的 @ 符号到底发生了什么
装饰器是 Python 里经典的黑魔法。它的源码读起来很好懂,但很多人搞不清楚执行时机。
先定义这样一个装饰器:
python复制import dis
def my_decorator(func):
def wrapper(*args, **kwargs):
print("before")
result = func(*args, **kwargs)
print("after")
return result
return wrapper
@my_decorator
def say_hello():
print("hello")
关键在于:@my_decorator 这一行在模块加载时到底变成了什么字节码?把模块级的代码对象 dump 出来看:
python复制dis.dis("""
@my_decorator
def say_hello():
print("hello")
""")
输出(3.11 风格,已经简化):
code复制 1 0 LOAD_NAME 0 (my_decorator)
2 LOAD_CONST 0 (<code object say_hello>)
4 MAKE_FUNCTION
6 PRECALL 1
8 CALL
10 STORE_NAME 1 (say_hello)
这就是装饰器的全部秘密:它先加载 my_decorator 函数对象,再加载被装饰函数对应的代码对象并用 MAKE_FUNCTION 创建函数对象,然后把函数对象作为参数调用 my_decorator,最后把返回值存回 say_hello 这个名字。
也就是说,装饰器在函数定义那一刻就执行了,不是在函数被调用时才执行。你写的 @my_decorator 本质上等同于:
python复制def say_hello():
print("hello")
say_hello = my_decorator(say_hello)
用 dis 验证这个现象还有一个额外福利:你能看到 MAKE_FUNCTION 指令之后紧接着的是 PRECALL 加 CALL,这说明 make function 和 call function 是两个完全独立的步骤。理解这个以后,再看装饰器工厂、带参数装饰器这类进阶写法,你脑子里就会自动浮现对应的字节码。
4.3 案例三:列表推导式的“隐形函数”从哪来
最后一个案例是列表推导式的作用域问题。Python 3 里有一个让大家很意外的行为:推导式里的循环变量不会泄漏到外部。
python复制nums = [i for i in range(5)]
把它的字节码打出来看,就能发现原因。用 dis 反汇编这段代码,会看到类似这样的输出:
code复制 1 0 LOAD_CONST 0 (<code object <listcomp>>)
2 LOAD_CONST 1 ('<listcomp>')
4 MAKE_FUNCTION
6 LOAD_NAME 0 (range)
8 LOAD_CONST 2 (5)
10 PRECALL 1
12 CALL
14 GET_ITER
16 PRECALL 1
18 CALL
20 RETURN_VALUE
这里的核心信息是:列表推导式被编译成了一个独立的代码对象
为什么 Python 3 要这么做?因为这样能防止循环变量污染命名空间,也让推导式的闭包语义更加清晰。Python 2 时代推导式确实会把变量泄漏出去,这算是一个长期为人诟病的问题,3.x 从语言层面解决了。
这一个案例充分说明:有些看似古怪的语言行为,在最底层其实是非常朴素的实现逻辑。你不看字节码,就得靠死记硬背;看了字节码,一切变得顺理成章。
5. 初探 dis 的避坑心得与版本差异
5.1 字节码不是稳定的:跨版本要注意什么
这是我最想强调的一点:字节码指令集是高度依赖解释器版本的。
以 3.10 到 3.11 的变化为例,3.11 做了一次重量级的字节码调整,很多指令改名、合并、拆分。BINARY_ADD 变成了 BINARY_OP,CALL_FUNCTION 变成了 CALL,还新增了 RESUME、CACHE 等指令。在 3.11 上跑 dis.dis(add) 看到的输出和在 3.10 上看到的完全不同。
所以当你阅读网上文章或者历史项目里保存的 dis 输出时,一定要先确认对方的 Python 版本。如果版本差了一代,指令说明对不上是很正常的事,不代表你记错了或者文章写错了。
查看当前解释器的指令集版本有个简单方法:
python复制import dis
print(dis.opmap)
opmap 是一个字典,把所有指令名字映射到对应的操作码数字。你还能用 sys.version_info 确认解释器版本。如果你要在不同版本间做兼容性分析,记得在代码里判断版本,分情况处理。
另外,还有一个值得注意的点:不同实现之间的差异更大。dis 模块展示的是 CPython 的字节码,PyPy 有自己完全不同的 JIT 机制,不会走这一套。你拿 dis 去分析 PyPy 下的代码,拿到的是 Python 层源码被解释器解析后的结果,而不是 PyPy JIT 编译后的机器码。这个边界要明确:dis 帮助你理解 CPython,而不是所有 Python 实现。
5.2 三个常见误区:可读性、必要性、过度解读
第一个误区是以为字节码一定要能“读懂”,读不懂就觉得自己对 Python 理解不够。实际上,字节码是给解释器看的东西,设计目标是执行效率而非人类可读性。很多指令的命名方式、参数编码都非常底层化,和源码是两套完全不同的抽象。初探时掌握常见指令就足够,完全没有必要去背全量指令表。
第二个误区是觉得看字节码“多此一举”,源码已经够清楚了。这种想法可以理解,但当你遇到真正诡异的性能问题、作用域问题和闭包问题,源码层面确实会给出误导性结论。dis 的作用不在于日常读代码,而在于打破沙锅问到底的时刻。它是一把手术刀,平时用不上,关键时刻能救命。
第三个误区是过度解读字节码。字节码告诉你“解释器会怎么执行”,但不会告诉你“这段代码的性能一定怎么样”。实际性能还取决于 CPU 缓存、内存分配、垃圾回收、外部 I/O 等等因素。用 dis 看到一个函数指令很多就断定它慢,这是不可取的。我见过有人为了把一条 LOAD_GLOBAL 换成 LOAD_FAST 写出非常别扭的代码,收益却微乎其微。正确的姿势是:先用 dis 定位可疑的机制,再配合 timeit 做实测,用数据说话。
5.3 给“初探者”的几个实用建议
最后分享几个我实践中摸索出来的经验。
第一,用 dis 分析函数时,优先看“有跳转”的部分。分支和循环是逻辑最复杂的部分,也是错误最容易藏匿的地方。POP_JUMP_IF_FALSE 的目标偏移量能告诉你条件跳转的目标是哪条指令,顺着这个追,逻辑链路一目了然。
第二,善用 dis.Bytecode() 写自动化检查脚本。比如你可以写一个脚本,遍历项目里所有函数,找出哪些函数的字节码里包含 LOAD_GLOBAL,帮助定位那些不小心在热循环里访问全局变量的代码。这个我已经在代码审查里用过好几次,效率很高。
第三,遇到不认识的指令,不要慌,直接去查官方文档的字节码章节。文档里针对每条指令都有完整说明,包括操作数栈的变化前后状态。看栈状态的变化是理解一条陌生指令最靠谱的方法。
第四,对于刚开始接触字节码的人,建议从最简单的函数开始,一行代码一个函数地拆,然后在脑子里模拟栈的运行过程。熟练之后你会形成一种直觉,看到一堆指令能快速在脑中还原出源码的轮廓。这种“逆着翻译”的能力对阅读复杂异常栈、分析闭包问题特别有用。
我在实际使用中还有一个体会:不同版本之间的字节码变化,其实是了解 CPython 演进脉络的一条捷径。3.11 引入的 CACHE 指令是为了优化指令缓存,RESUME 指令的出现是为了支持更精细的调试和性能分析,这些设计意图从源码层面很难感受到,但从字节码层面看就非常清楚。初探 dis 模块这件事本身,表面上是学一个工具,实际上是在走进 CPython 的设计世界。如果你有一份 3.11 或更高版本的 Python,现在就可以打开终端跑一下 dis.dis(你的函数),看看那些熟悉的代码在底层到底是什么样子。这种感受,读多少篇文章都不如自己亲手看一次来得真切。
