深入理解Python执行原理：从字节码到虚拟机

很多人把Python当成“脚本语言”来用，写个爬虫、跑个量化策略、做个数据分析，很少去想代码在后台到底经历了什么。但问题往往就藏在这层“不用想”里：为什么同样的逻辑，Python比C++慢那么多？为什么多线程在某些场景下反而更慢？为什么改了一个小语法，整个模块就要重新加载？这些问题的答案，全都指向同一个根源——Python到底是怎么执行代码的。

这篇文章不打算写教科书式的流程堆砌，而是按一条实际代码的执行路径，从源码打到字节码，再进虚拟机，把GIL、内存管理、模块导入这些“幕后黑手”一个个揪出来聊清楚。适合两类人看：一是写了段时间Python、想搞明白底层原理的进阶学习者；二是被Python性能问题折磨过、想知道瓶颈到底卡在哪里的开发者。看完之后，你至少能回答一个问题：一行 total = a + b，在CPython里到底经历了什么。

1. 一条Python指令从源码到字节码的旅程

1.1 先澄清一个误解：Python不是纯粹的“解释型语言”

很多教材把编程语言分成“编译型”和“解释型”两类，然后把C语言归为编译型，把Python归为解释型。这个分法在入门阶段没有问题，但如果你真的去追底层，会发现Python的“解释”和shell脚本的“解释”完全是两回事。

Shell脚本是解释器一行行读取源码、一行行执行，中间基本没有“编译产物”这个概念。而Python在执行任何代码之前，都会先进行一次完整的“编译”——把源码变成一种中间表示，这个中间表示叫字节码（bytecode）。之后再有一个虚拟机逐条读取字节码并执行。

换句话说，Python做的事情其实和Java很像：先编译成字节码，再在虚拟机上跑。只不过这个虚拟机不如JVM那么出名，而且Python不要求你显式执行javac那一步，编译过程被设计成透明的、自动的。所以你才会感觉“好像不用编译”。

1.2 从源码到字节码的四道工序

CPython执行一段Python代码，幕后是这么一条流水线：

1. 词法分析：把源码字符串分解成一个个token，比如关键字def、标识符foo、操作符+都是独立token。
2. 语法分析：根据Python文法把token组装成抽象语法树（AST）。这一步如果出错，就是你常见的SyntaxError——树还没建完，后面根本没法走。
3. 编译：遍历AST，生成控制流图，最终输出一个code object，这个对象里包含字节码、常量表、变量名表等元信息。
4. 执行：Python虚拟机读入code object里的字节码，逐个执行。

前三个步骤合起来，就是compile()函数做的事。你甚至可以在代码里手动调用它，把一个字符串编译成code object，再用exec()执行：

python复制source = "def add(a, b):\n    return a + b\n"
code_obj = compile(source, "<string>", "exec")
exec(code_obj)
print(add(3, 5))  # 8

实际开发中很少这么干，但理解了这条链路，你才能理解后面所有性能问题——因为每一步都有开销，特别是语法分析和编译阶段，对同一个函数来说是不可忽略的固定成本。

1.3 你的.py文件到底何时被编译成字节码

如果你在项目里运行过Python，一定见过一个叫__pycache__的文件夹，里面躺着一堆.pyc文件。这些文件就是“编译产物”——字节码的固化形态。

关键问题来了：是不是每次运行都会重新编译源码？答案是分情况：

• 如果Python发现__pycache__里有对应的.pyc文件，且它的时间戳和源码文件匹配，版本也匹配，就直接加载字节码，跳过词法分析、语法分析和编译这三道工序。
• 如果源码被改过，或者.pyc文件缺失，Python就重新走完整流程，生成新的.pyc。

这就是为什么你第一次运行一个大型脚本会觉得“卡一下”，第二次明显快一点的深层原因——第二次省掉的是编译阶段的时间，而执行阶段本身一点没省。

还有个细节容易被忽略：.pyc文件的二进制格式跟Python版本强相关。你用3.11生成的.pyc，放到3.10的环境里是加载不了的。CPython专门把解释器版本号编码进了.pyc文件的magic number里，不匹配就直接判定无效，重新编译。这也就意味着，如果你在团队里共享.pyc文件或者打包发布时不小心带上了.pyc，换环境后很可能白带。

1.4 字节码到底长什么样

文本形式的源码之所以能变成机器能理解的东西，中间的“桥梁”就是字节码。想看一段代码的字节码长什么样，可以用标准库dis模块：

python复制import dis

def add(a, b):
    total = a + b
    return total

dis.dis(add)

输出大概是这样的：

code复制  2           0 RESUME                   0
  3           2 LOAD_FAST                0 (a)
              4 LOAD_FAST                1 (b)
              6 BINARY_OP                0 (+)
             10 STORE_FAST               2 (total)
  4          12 LOAD_FAST                2 (total)
             14 RETURN_VALUE

先别急着被这些指令吓到。你只需要抓住一个核心逻辑：Python虚拟机的执行模型是“栈式”的——先把数据压入一个栈，操作符从栈里弹出数据，算完再把结果压回去。

拿上面的total = a + b来看：

• LOAD_FAST 0：把局部变量a的值压栈。
• LOAD_FAST 1：把局部变量b的值压栈。
• BINARY_OP 0：从栈顶弹出两个值，执行加法，结果压栈。
• STORE_FAST 2：从栈顶弹出结果，存入局部变量total。

这种设计对“动态类型”非常友好：BINARY_OP执行加法时根本不需要关心a和b是什么类型，整数加、浮点加、字符串拼接、列表拼接全都可以由同一套执行机制在运行时动态判断。代价也很明显——每一条字节码都要在虚拟机里做类型检查和分派，这种动态性天然带来开销。

2. CPython虚拟机的运行机制：栈帧与操作码

2.1 一场永不停止的while循环

CPython虚拟机的内核，本质上是一个巨大的while循环。这个循环不断做三件事：取一条字节码指令，解析它，执行它。所有Python代码的执行，最终都落到这个循环里。

C语言写的虚拟机主循环，精简下来大概长这样：

c复制for (;;) {
    opcode = *next_instr++;   // 取指令
    switch (opcode) {
        case LOAD_FAST:
            ...
        case BINARY_OP:
            ...
        case RETURN_VALUE:
            ...
    }
}

这个架构很容易理解：每一条Python语句在执行时都会被翻译成若干条字节码指令，每条指令对应switch里的一个case分支。

说到这里，你可以直观感受到Python和C的性能差距从哪来了。C代码编译成机器指令后，是CPU直接执行的，无数条指令在流水线里并行推进；而Python代码执行时，先是解释器在一个大循环里逐条分派字节码，每条字节码背后还拖着类型检查、引用计数、异常检查等一堆负担。性能差距的本质不是“解释”和“编译”之争，而是“动态分派”和“静态直译”的差距。

2.2 函数调用的灵魂：栈帧（Frame）

如果你在写Python时看到过这样的堆栈信息：

code复制Traceback (most recent call last):
  File "test.py", line 10, in <module>
    process_data()
  File "test.py", line 5, in process_data
    parse_line()

这里的每一行，其实都对应着一个栈帧。

每一次函数调用，Python都会在内存中创建一个新的栈帧对象。这个栈帧保存了：函数当前的执行位置（指令指针）、局部变量、全局变量引用、异常状态等。函数调用结束，栈帧销毁，控制权交还给上一级栈帧。

栈帧是理解Python函数调用机制的核心。比如递归爆栈——RecursionError——真的原因是每个调用都创建新栈帧，而栈空间是有限的。Python默认把递归层数限制在大约1000层，目的就是防止栈帧把内存撑爆，而不是因为什么神秘力量。

栈帧还有一个有趣的影响：闭包和局部变量的访问速度差异。Python访问局部变量时，是从栈帧的“快速通道”（fast locals，实际是固定索引的数组）里取的，所以LOAD_FAST非常快。而访问全局变量要查字典，LOAD_GLOBAL就慢不少。这就是为什么很多人建议“循环里把全局变量赋值给局部变量再用”——这不是玄学，是真的能少查几次字典。

2.3 动态类型给字节码带来的额外开销

用dis再看一个稍微复杂点的例子：

python复制def process(items):
    result = []
    for item in items:
        result.append(item * 2)
    return result

它的字节码里会有FOR_ITER、LOAD_METHOD、CALL等指令。注意其中一个关键点：Python执行item * 2的时候，BINARY_OP指令会先检查item的实际类型，再确定执行整数乘法还是浮点乘法还是序列重复操作。

这个“运行时类型检查”就是动态语言的通用开销。相比之下，Java和C++在编译时就已经确定变量的类型，直接生成对应的整数乘法机器指令，运行时根本不用再判断。

但是往好处想，这正是Python能在同一种语法里兼容无数种数据类型的原因——列表、元组、numpy数组、自定义类，只要实现了__mul__方法，*操作符全都接得住。代价和灵活性总是顺手打包的。

2.4 在Python里直接操作字节码的另类玩法

理解了虚拟机之后，你就会明白为什么Python允许在运行时动态生成和执行代码。比如：

python复制import types

# 手工构造一个code object
code = compile("x + 1", "<string>", "eval")

# 用types.CodeType可以修改参数
new_code = types.CodeType(
    0, 0, 0, 0, 0, 0, b"x\x01",  # 字节码硬编码
    (), (), (), ("x",), "<string>", "", 0, b""
)

这已经属于偏门玩法了，但确实有人拿它在热更新引擎里做“动态补丁”。理解原理之后你会发现，Python的灵活程度远超一般人的想象——因为编译器、虚拟机的接口都暴露给了普通开发者和库作者。

3. 执行背后的基础设施：GIL、内存管理与模块导入

3.1 GIL到底是“锁”还是“设计缺陷”

在CPython里，同一时刻只允许一个线程执行Python字节码，这就是GIL（全局解释器锁）。这个锁的存在让CPython的线程模型变得非常特殊——多线程在CPU密集型任务上不仅不能加速，反而会变慢。

看一段实测代码：

python复制import threading
import time

def count_down(n):
    while n > 0:
        n -= 1

N = 100_000_000

start = time.perf_counter()
count_down(N)
print(f"单线程耗时: {time.perf_counter() - start:.2f}s")

start = time.perf_counter()
t1 = threading.Thread(target=count_down, args=(N // 2,))
t2 = threading.Thread(target=count_down, args=(N // 2,))
t1.start(); t2.start()
t1.join(); t2.join()
print(f"双线程耗时: {time.perf_counter() - start:.2f}s")

我本机跑出来的结果大概是：单线程4.1秒，双线程4.4秒。两个线程不仅没跑快，还因为抢锁和上下文切换多花了时间。

GIL存在的历史原因，本质是为了简化CPython的内存管理——尤其是引用计数器的线程安全，不需要给每个对象单独加锁，只要保证整个解释器全局持有一把锁就够了。这样做的实现成本低，单线程性能更好，但代价就是多核CPU对Python字节码几乎无能为力。

那是不是说Python的多线程就没用了？不是。GIL只锁Python字节码的执行，不锁C扩展里运行的操作。比如I/O操作（文件读写、网络请求、睡眠）在执行系统调用时会主动释放GIL，所以多线程处理爬虫、网络请求、文件I/O这类IO密集型任务依然有效。但CPU密集型的纯Python计算，多线程就是负优化。

如果你真的需要并行计算，实际可选方案是：多进程（multiprocessing）、用C扩展（比如numpy内部会自动释放GIL再并行计算）、或者直接换PyPy这类没有GIL的实现。

3.2 内存管理：引用计数与分代垃圾回收

Python的对象生命周期靠两部分管理：引用计数和垃圾回收器。

引用计数是CPython最基础的内存管理机制。每个Python对象内部都有一个计数器，记录当前有多少处变量引用它。被引用的次数归零，内存立刻被回收。这样设计的最大好处是垃圾回收的时机是确定的——没有“停全局”这种GC pause问题。代价是每增加或删除一个引用，都要做一次加减法操作，这也是Python执行速度慢的一个微小的底层原因。

看个例子：

python复制a = [1, 2, 3]  # 引用计数=1
b = a          # 引用计数=2
del a          # 引用计数=1
del b          # 引用计数=0，列表对象立即被释放

光靠引用计数有一个明显死角：循环引用。比如两个对象互相引用，各自的外部引用都删光了，但内部的引用计数互相拉住，谁都不会变成0，内存就泄漏了。所以CPython还配了一个“分代垃圾回收器”（garbage collector），周期性检测并清理这类循环引用。

分代，就是把对象按存活时间分成三代：年轻代、中生代、老年代。新对象最先进入年轻代，经历若干次垃圾回收仍然存活的对象会晋升到更老的代。垃圾回收器对年轻代扫描最频繁，老年代最少扫描。这样设计是为了平衡回收效率和CPU开销。

理解这个机制后，你会在实际编码里多留一个心眼：大量短生命周期对象，比如循环里频繁创建的临时列表、字典，会给垃圾回收器造成压力。 优化方法通常是复用对象，或者手动关闭自动GC再定向清理，比如gc.disable()和gc.collect()配合使用。不过这个属于极端情况下的性能调优，日常写业务代码不需要这么干。

3.3 import机制：模块到底是怎么加载的

import 是Python开发里最常见的操作，但很多人不知道import背后藏了多少次“执行”。

当Python执行import numpy as np时，发生的事大概是：

1. 在sys.modules里查找numpy是否已经被加载过。加载过就直接拿引用，不再重复加载。
2. 如果没加载，按照sys.path的目录顺序查找模块文件。sys.path的第一个元素通常是当前脚本所在目录，然后是PYTHONPATH环境变量指定的目录，再然后是标准库目录和site-packages。
3. 找到模块文件后，Python会先检查有没有对应的.pyc字节码缓存；没有就执行完整的编译流程。
4. 加载模块，本质上就是从头到尾执行一遍这个模块的代码——包括def语句、class语句和模块顶层的任何一行代码。
5. 执行完成后，把模块对象放入sys.modules缓存。

所以一个常见的坑就很好解释了：为什么循环导入会报错？ 因为A模块刚开始执行，加载到一半时遇到import B，B又要import A，而A还在sys.modules里处于“半成品”状态，从中拿到的可能是还没有定义完的模块对象，导致后续访问出问题。理解了import机制，你就知道循环导入的根源是“执行顺序”问题，而不只是设计规范问题。

还有个小坑：模块顶层的代码不要写耗时操作。因为一旦有人import这个模块，这些代码就会被执行。很多初学者喜欢在校验数据、加载配置这些耗时操作时直接写在模块顶层，结果import这个模块的脚本启动奇慢，还容易被误认为是死循环。

3.4 sys.modules缓存与热重载

正因为有sys.modules缓存，所以你在一轮执行里多次import同一个模块，不会重复执行模块代码。但这也带来一个常见的坑：在交互式开发或者长时间运行的服务里，你改了一个模块的源码，程序不会自动使用新版本，除非重启进程。

有些框架会做“热重载”，原理就是手动从sys.modules里删掉相关模块，然后重新import：

python复制import sys
sys.modules.pop("my_module", None)
import my_module  # 重新执行模块代码

但这种做法在依赖关系复杂时容易踩坑——模块A引用了模块B，你只重载了A，B还是旧版本。实际工程里，除非是做插件系统或者交互式开发工具，否则不建议自己实现热重载，老老实实重启进程最稳妥。

4. 不同Python实现下的执行差异与选型考量

4.1 不只是CPython：PyPy、Cython、Numba怎么改变执行路径

聊到Python的执行原理，很多人默认讨论对象是CPython——也就是官方实现。但Python生态里还有一批改变执行方式的“变体”，各自调整了不同的执行策略，值得认真了解一下：

最关键的区别在于PyPy引入了**JIT（即时编译）**机制。PyPy初始也像CPython一样解释执行字节码，但它会统计哪些代码被反复执行（比如循环体），把这些热点代码在运行时直接编译成机器码，后续执行就不再走“逐条解释”的路了。这有点像Java的HotSpot VM的思路。所以在跑长循环、大量数值计算时，PyPy经常能比CPython快几倍甚至一个量级。

Numba则是另一种思路——它不改变整个解释器，而是用一个装饰器定向编译特定函数：

python复制from numba import jit

@jit(nopython=True)
def compute_sum(n):
    total = 0
    for i in range(n):
        total += i * i
    return total

print(compute_sum(100_000_000))

nopython=True表示强制不退回Python对象模式，尽量把所有数值运算转化为原生机器指令。在量化策略回测、蒙特卡洛模拟这类数值计算场景里，Numba的提速效果有时候能达到几十倍。但它也有使用限制——函数里基本只能用numpy和基础的Python数值类型，不能随便调列表、字典这样的动态对象。

Cython就更“硬核”了，它让你在.pyx文件里写Python风格的代码，必要时加cdef等静态类型声明，然后编译成C扩展模块。好处是兼容CPython生态，坏处是多了一道编译工序，调试和部署都会复杂一点。

4.2 什么情况下需要换实现，什么情况下纯属浪费

我见过很多团队一腔热血把Python项目改用PyPy，结果依赖库不支持（有些C扩展没有PyPy版本），折腾几天又回退了。决策时要先想清楚瓶颈到底在哪。

• 瓶颈在纯Python计算逻辑：比如复杂回测策略、文本解析、递归算法，可以先试试PyPy，成本低，提速明显。
• 瓶颈在数值矩阵运算：比如numpy循环、向量运算、pandas apply，优先考虑Numba或者重写关键函数，而不是换解释器。
• 瓶颈在I/O等待：文件读写、网络请求、数据库查询，换解释器没用，应该调并发模型（多线程、asyncio）。
• 瓶颈在第三方C扩展：比如pandas、opencv内部的运算，这种瓶颈通常已经是C语言层面了，换解释器基本不改变什么。

还有一个现实问题：PyPy对科学计算生态的兼容性一直不太友好，很多依赖C扩展的库（pandas的某些版本、scipy等）在PyPy上要么装不上，要么性能反而下降。所以如果你的项目核心是数据分析、机器学习，老老实实用CPython就能少惹一堆麻烦，真正耗时的地方直接交给numpy这类底层就是C/C++的库去跑。

4.3 量化策略场景里的执行路径选择

热点词里出现了“Python量化交易策略代码”，这里多说一句：量化回测的性能瓶颈，十有八九出在逐bar、逐tick的循环计算上。直接用纯Python for循环写双均线回测，几万根K线数据跑下来可能要几分钟；但同逻辑改成numpy向量化操作，几秒就出结果；再用Numba装饰器优化一下，甚至可以压到几百毫秒。

这种优化能够生效的原因，恰恰是理解了执行原理之后得出的结论：Python的for循环每经过一次迭代，都要创建新的整数对象、走一次字节码分派、做一次类型检查。而numpy的向量化操作把这些循环下沉到C语言层，用一个预编译好的原生循环一次算完。我在自己的策略研究里，通常先把策略用纯Python写成逻辑清晰的版本，确认交易逻辑没有bug，再做numpy向量化改造和Numba加速——这两步完全基于对执行路径的判断，而不是盲目优化。

5. 从执行原理看常见错误与性能瓶颈

5.1 RecursionError的实质：栈帧空间不够了

很多人第一次遇到RecursionError时以为Python不支持递归，其实不是。这个错误是Python虚拟机的栈空间上限被触发了。

默认递归限制大约是1000层，可以用sys.setrecursionlimit()调大，但调大之后只是把问题往后推，真正的风险是栈溢出导致解释器崩溃。CPython的C栈和Python栈是关联的，递归太深最终会压爆C栈，造成段错误（segfault），这种错误比异常更严重，因为进程直接挂掉。

所以处理递归的正确姿势是：要么确认递归深度可控且不大，要么改成迭代实现，要么用显式栈模拟递归。理解了栈帧模型之后，你都应该明白这些建议不是“Python教条”，而是对虚拟机资源模型的基本尊重。

5.2 慢的根源到底在哪：局部变量、属性访问与类型分派

写Python多了之后，我会下意识地规避一些写法。比如循环里频繁访问全局变量：

python复制# 慢
import math

def f1(nums):
    result = []
    for n in nums:
        result.append(math.sqrt(n))
    return result

# 快
import math

def f2(nums):
    _sqrt = math.sqrt  # 局部变量缓存
    result = []
    append = result.append
    for n in nums:
        append(_sqrt(n))
    return result

f2为什么快？从执行原理角度拆解：

• math.sqrt是全局属性访问，实际要经过LOAD_GLOBAL + LOAD_ATTR两步，每步都是字典查询+函数对象查找。
• 缓存到局部变量后，循环里只执行LOAD_FAST，按栈帧里固定索引直接取，速度差一个量级。
• result.append也是同理，把方法查出来放到局部变量，循环体里省掉了每次查方法的开销。

这个优化不是YAGNI，在循环次数达到百万级时，两者的耗时差距肉眼可见。我曾经在本地跑过测试：一千万次循环，f1大约慢30%~50%。逻辑完全一样，只是执行路径里少了几次属性查找而已。

5.3 动态分派开销的最好例子：多态与魔法方法

Python的+号看起来很简单，实际执行时Python会先检查操作数的类型，再查找对应类型里的__add__方法，然后调用它。这个过程每执行一次a + b都会重复一遍。

所以你在Python里写一个大循环逐元素做加法，永远跑不过直接用sum(list)——因为sum这个内置函数整体由C语言实现，循环体在C里跑，不需要每加一个数就重新做一轮类型检查和字节码分派。

这个原则可以泛化：能交给内置函数和标准库的活，不要自己写Python循环。map、filter、itertools、functools.reduce、collections.Counter，这些工具的底层实现几乎都是C，性能远好于手写for循环。很多人嗤之以鼻说“内置函数能比我手写快多少”，实测不用怀疑，就是快——因为你的循环跑在字节码分派器里，它的循环跑在C语言原生指令流里。

5.4 一次真实排查：脚本为什么花了两小时

我之前处理过一个数据分析脚本，逻辑是把几十万条日志按时间分桶，统计每个桶里的关键词频次。最初版本跑了两个小时才出结果，任务进度全靠日志打印。

拿到脚本第一件事，我用cProfile跑了一下，瞬间找到两个热点：一个是在for循环里频繁调用自定义的parse_line函数，函数内部用了正则表达式处理每条日志；另一个是对每个关键词都在全局变量里做了字典查找。

优化改了三个点：第一，把正则表达式对象提到函数外，用re.compile预编译；第二，把热点函数里用的全局字典改成传入参数，用局部变量访问；第三，分桶时用defaultdict(list)替代手动判断键存在。

改完后运行时间从两小时压到了不到四分钟。我没有换机器，没有换语言，没有魔改算法复杂度，只是把执行路径上的浪费消掉了。性能优化最怕的不是不会用工具，而是不懂原理，到处瞎改最后发现改的是无关紧要的地方。 cProfile配合dis模块，是你理解Python执行路径的最佳探针。

6. 理解执行模型后，编码习惯会怎样改变

6.1 不再笼统地说“Python慢”，而是说“慢在哪”

现在我写Python或者评审别人的Python代码时，很少再用“Python慢”这种笼统的判断。看到性能问题，第一反应会拆成这几层去考虑：

• 慢在读源码编译阶段？通常只影响启动时间，不影响运行时。
• 慢在纯Python字节码循环？考虑用内置函数、向量化、PyPy或Numba。
• 慢在频繁属性访问和全局查找？缓存到局部变量就行。
• 慢在动态类型分派和对象创建？减少循环里的临时对象，复用结构。

这个分层判断的能力，只能来自对执行原理的理解。它不是背书背出来的，而是把dis、cProfile、timeit当成日常工具反复用之后的条件反射。

6.2 面向执行效率的编码清单

根据我自己的经验，当你理解了Python执行过程后，以下习惯自然就会形成：

• 循环体里尽量只出现局部变量，全局变量和模块属性提前取出缓存。
• 尽可能使用内置函数和标准库的函数式工具，不用自己写Python小循环。
• 用tuple和list按位置访问，而不是无脑拆包再合成新对象。
• 大量数值计算交给numpy向量化操作，再不行考虑Numba。
• 正则、字符串处理这类重活尽量用标准库的C实现，避免在Python层反复匹配。
• 不到必要时不动态生成代码（eval/exec/大量getattr），这些操作的运行时开销和不确定性都比较高。

6.3 一个额外的体会：阅读dis输出能帮你写出更省指令的代码

我偶尔会把自己写的函数丢给dis.dis()看，不是为了艺术鉴赏，而是为了发现无意义的多余指令。比如早期我写代码喜欢在return前加一行result = result之类的冗余赋值；直到看到字节码里多出一条STORE_FAST和LOAD_FAST才意识到这种写法毫无价值。

再比如，if not x is None和if x is not None，前者在字节码里多了一条UNARY_NOT或COMPARE_OP，语义上还容易误导。看字节码之后，我连if x != None这种写法都完全改掉了，因为is not语义清晰，执行路径还更短。

Python的灵活性和动态性是它容易上手的原因，但也是它执行效率不高的深层根源。如果你真的想用它写出更快、更稳健的程序，花时间搞清楚“代码执行时到底经历了什么”，比背诵任何性能优化教程都更划算。现在你就可以打开一个终端，创建一个临时文件，放几个简单函数，用python -m dis盯一眼字节码，从这里开始，会比看再多原理图都更直接。