Python代码执行过程全解析：从源码到字节码与虚拟机运行

平时写Python大家都有过这样的好奇：一个一个.py文件，双击或者敲一行python demo.py，屏幕上就出现了结果，看起来毫不费力。可你有没有停下来想过，它到底是怎么被“读懂”的？为什么代码里某个变量能记住上次的值，为什么两个整数相乘那么快，为什么自定义类的方法能在正确的对象上找到数据？这些问题背后的答案，最终都指向同一个主题——Python代码的执行过程。

这篇文章会把这条从“字符串”到“程序运行”的路完整走一遍，从你按下回车那一刻讲起，分拆Python解释器内部最重要的几个环节：词法分析、语法分析、字节码生成、虚拟机执行、运行时对象模型，再到常见的性能问题排查。不管你是刚学Python不久、想搞懂pycache和dis的朋友，还是已经写了一段时间代码、想进一步理解递归栈和GC优化的人，这篇文章都能帮你把这些知识连成一张网。

顺便说一句，看懂执行过程这件事不需要你提前读过什么编译原理，我会尽量用生活中的类比把它讲透，但也会保留该有的专业名词和命令工具。

1. 从源码到运行的完整链条：Python代码的宏观执行路线

1.1 一段代码在被执行前经历了什么

先从最顶层看。你写的所有Python代码，本质上都是一堆文本字符。解释器拿到这堆文本之后，不会直接“读一行执行一行”，它必须先把文本转换成计算机能理解的结构。整个链条大概是这样的：

源码文本 -> 词法分析（生成Token） -> 语法分析（生成AST） -> 编译（生成字节码） -> 虚拟机解释执行。

你可以把整个过程类比成一个翻译流程。源码是原始外语文章，词法分析是分词，把句子拆成单词和标点；语法分析是解析句子结构，判断主谓宾是否成立；字节码相当于翻译成一种人类看不懂但机器很好执行的中间语言；最后虚拟机就是那个把中间语言一条条“演出来”的演员。

注意一个细节：Python虽然是解释型语言，但它内部有完整的“编译”步骤。有人把它叫“编译型”也不是完全没道理，准确的说法是“编译到字节码再解释执行”。这跟C语言直接编译成机器码不一样，因为字节码和机器码之间还隔着一层虚拟机和运行时系统。这也是为什么同一个.py文件在Windows和Linux上通常都能直接跑，前提是两边都装了对应平台的解释器。

1.2 入口：python demo.py之后发生的第一件事

在命令行输入python demo.py时，操作系统会先运行python这个可执行程序，入口一般在cpython源码的Modules/main.c或者更高层的pymain_main中。抛开源码细节，它做的事情很清晰：

• 初始化解释器：读取环境变量、设置编码、初始化内存分配器和垃圾回收机制。
• 解析命令行参数，把demo.py作为主模块路径。
• 调用PyRun_AnyFileExFlags，基于文件名决定是执行文件还是进入交互式REPL。
• 读取文件内容到字符串缓冲区，然后进入编译流程。

这一步有一个容易被忽略但又经常让人困扰的点：源代码文件的编码。Python 3 默认使用 UTF-8 读取源码，但如果你在源码里写了# -*- coding: gbk -*-这样的声明，解释器会用对应编码解析。万一文件和声明的编码不一致，你会在导入时得到一个SyntaxError: Non-UTF-8 code starting with ...或乱码错误。这就是为什么我建议所有项目统一用UTF-8保存源码。

1.3 为什么会有__pycache__和.pyc文件

如果你用过Python，一定见过项目中冒出来的__pycache__目录，里面一堆.cpython-310.pyc之类的文件。很多人觉得它碍眼，但它其实就是“编译到字节码后留下的缓存”。

逻辑是这样的：当某个模块是首次从磁盘加载时，解释器必须完成“源码->Token->AST->字节码”这一整套步骤。如果代码没有改动，下次再导入同一个模块时，解释器发现文件的时间戳和大小都没变，就会直接加载.pyc缓存里的字节码，省去前面编译的开销。这对大型项目启动速度很有帮助。

.pyc文件的命名里通常带着Python版本号，比如xxx.cpython-311.pyc，这也是为了兼容同一台机器上多版本Python共存时互不污染。另外，系统目录里的标准库模块也几乎全部是预先编译好的字节码，你导入json或re时能很快返回，就有这部分功劳。

2. 源码内部长什么样：词法分析、语法树与字节码生成

2.1 词法分析：把字符流拆成Token

词法分析的工作非常“机械”，它逐个字符扫描源码，根据语法规则把连续的字符组合成有意义的词法单元（Token）。Token的类型包括：标识符、关键字、数字字面量、字符串字面量、运算符、分隔符等。

例如这一行代码：

total = 1 + 2 * 3

词法分析阶段会得到类似这样的Token序列：

• NAME（名字）: total
• OP（操作符）: =
• NUMBER（数字）: 1
• OP: +
• NUMBER: 2
• OP: *
• NUMBER: 3

你可能会问：为什么这儿不是先做加法或乘法？因为词法分析不负责运算，它只做“分词”。哪怕你把代码写成非法的1+*2，词法层面可能都看不出问题，因为每个字符都能归到某个Token里。要等到语法分析阶段才能发现+后面不能直接跟*。这就好比查字典时你能查出每个词，但你不一定能判断这句话是不是病句。

2.2 语法分析：构建抽象语法树

语法分析阶段会把Token序列组织成一棵树状结构，这棵树叫抽象语法树（Abstract Syntax Tree，AST）。每个节点对应一个语法结构，比如BinOp（二元运算）、Assign（赋值）、FunctionDef（函数定义）、If（条件分支）。

Python内置的ast模块可以让你以编程方式查看这棵树。比如下面的示例：

import ast code = "total = 1 + 2 * 3" tree = ast.parse(code) print(ast.dump(tree, indent=2))

输出里会看到Module -> Assign -> BinOp的嵌套结构：

Module( body=[ Assign( targets=[Name(id='total', ctx=Store())], value=BinOp( left=Constant(value=1), op=Add(), right=BinOp( left=Constant(value=2), op=Mult(), right=Constant(value=3)))) ])

这里能看到一个非常关键的点：乘法2 * 3在AST里是嵌套在加法里层的。也就是说，语法树本身就反映了运算符优先级，优先级是在语法分析阶段按文法规则处理的，而不是在运行时临时判断的。这也是为什么1 + 2*3算出来是7，而不是9。

理解AST是理解后续所有优化的基础。很多Python代码分析工具（比如静态检查工具、格式化工具、类型检查器）本质上都是先解析出AST，再在上面做遍历和修改。你甚至可以使用ast模块写一个小工具，自动替换某些函数名或者统计代码里出现了多少个if节点。

2.3 从AST到字节码：Code对象与dis反汇编

语法分析之后，编译器会根据AST生成Python字节码。字节码不是机器码，它是专门为Python虚拟机设计的一组指令序列。每条指令通常包含操作码（opcode）和可选的操作数。

在Python 3.11以后，字节码在执行前还会经过一个叫做“自适应特化”（specialization）的优化步骤，解释器会根据实际执行情况调整内部指令格式，这部分感兴趣的话可以查一下PEP 659。普通开发者不需要深入了解，但要知道一点：同一份源码在Python 3.10和3.11里生成的字节码很可能不同，性能表现也有明显差异。

我们可以用dis模块反汇编一个函数，看看字节码到底长什么样。示例：

import dis def add(a, b): return a + b dis.dis(add)

输出类似下面：

2 0 LOAD_FAST 0 (a) 2 LOAD_FAST 1 (b) 4 BINARY_OP 0 (+) 8 RETURN_VALUE

这里的LOAD_FAST表示把局部变量加载到栈上，BINARY_OP表示执行加法运算，RETURN_VALUE表示返回结果。数字0和1是局部变量在帧对象里的索引，不是值本身。看懂这些指令后，你就能理解为什么局部变量访问比全局变量快：对局部变量的加载指令是LOAD_FAST，直接按索引取；对全局变量则是LOAD_GLOBAL，需要去全局命名空间里查名字，多了一次哈希查找。

2.4 Code对象：字节码、常量和名字的“合订本”

当函数定义被编译时，编译器会为该函数生成一个代码对象（code object），源码里的每个函数、类、模块都有一个它对应的代码对象。代码对象里保存着一大堆信息：

• 字节码指令序列
• 常量表（co_consts，包括数字、字符串字面量）
• 名字表（co_names，比如调用的全局函数名）
• 局部变量名表（co_varnames）
• 参数数量、默认参数、闭包变量
• 源代码文件名和首行行号

你可以通过函数对象的__code__属性访问它：

def greet(name): return "Hello, " + name print(greet.__code__.co_consts) print(greet.__code__.co_varnames)

这样做有什么用？调试时，当你想确认一个函数到底拿到了哪些默认值、哪些变量被编译器认为是局部变量时，直接看co_consts和co_varnames非常直观。比如你发现某个变量在函数内改了却报UnboundLocalError，看看co_varnames里有没有那个名字，就能确定编译器把它标记成了局部变量，即便代码里对它的赋值出现在后面。

3. 虚拟机执行阶段：栈帧、操作数栈与运行时变量

3.1 把字节码“演出来”：Python虚拟机模型

Python的核心执行单元是“帧对象”（frame）。可以把它理解成一次函数调用的工作台。帧里包含了：

• 当前代码对象
• 局部变量命名空间
• 全局变量命名空间
• 操作数栈
• 当前执行到第几条指令的指针（f_lasti）
• 上一个帧的引用

每调用一个函数时，解释器会创建新的帧并压入调用栈；函数返回后，帧被销毁，回到上一帧。递归调用层数过深时，栈空间被耗尽，就会抛RecursionError，这就是递归深度限制的底层来源。

帧对象里最核心的小空间是操作数栈。你可以把它想成一个后进先出的盘子架，很多指令先从栈里“取盘子”（弹出值做运算），再把结果“放上去”（压入栈）。比如执行a + b时，解释器会先把a压栈，再把b压栈，然后执行BINARY_OP指令，让解释器从栈顶弹出两个值，计算结果后再压入栈。最终RETURN_VALUE会把栈顶的值取走返回给调用方。

3.2 常用字节码指令对照表

为了帮助你把抽象概念落到具体代码上，我整理了一个最常用的指令速查表：

注意，Python 3.11 及以后版本把CALL_FUNCTION、CALL_METHOD等指令合并成了统一的CALL，指令参数里会携带“是否含关键字参数”等信息。

了解代码被怎样解释执行，最关键的价值在于培养一种直觉：你写的每一条Python语句，最终都会被翻译成几条甚至几十条这样的指令；指令越少、越简单，执行就越快。这也是为什么经验丰富的开发者总强调用sum(list)代替手写for循环累加，因为前者在解释器内部有高效的C实现，而后者则需要走好多条Python字节码指令。

3.3 函数调用机制：压帧、弹帧与递归限制

看一个函数调用链时，比如：

def a(): b() def b(): c() def c(): print("done")

执行过程是：调用a()时创建a的帧，压入栈；a()调用b()，再创建b的帧压入；b()调用c()，再压入c的帧。c()执行完，返回结果给b的帧，同时c的帧弹出。整个过程就像一个“套娃”的展开与回收。

一旦你写出无穷递归，比如：

def f(): return f()

解释器就会不断创建新帧，直到调用栈达到系统设定上限（默认通常是1000层左右）。然后抛出：

RecursionError: maximum recursion depth exceeded

这是保护机制，防止程序直接把内存栈爆掉导致段错误。如果你确实需要一个很深的递归场景，可以调用sys.setrecursionlimit提高上限，但真正遇到这种情况时，更合理的做法是改成迭代、尾递归重构，或者使用栈模拟。

3.4 异常处理在虚拟机中的实现

异常处理也是典型的虚拟机机制。try / except不是只靠语法糖实现的，而是在字节码层面显式控制。解释器为每个带异常处理的代码块维护一个异常处理表，里面记录了异常处理器的起始偏移、结束偏移和处理代码的跳转目标。

当解释器执行过程中遇到错误并抛出异常时，它会沿着当前帧的操作栈往上找：当前帧有没有匹配的处理器？如果没有，就退出当前帧，回到上一帧继续找。所以异常在函数间传播的过程，本质上就是帧弹出、逐层上抛的过程。

知道这一点会对你理解两个现象很有帮助：

• finally里的代码为什么一定执行？因为生成的字节码会在正常返回路径和异常路径里都插入清理代码。
• except Exception和except:的区别：except:会捕获所有异常，包括KeyboardInterrupt和SystemExit，这通常会导致程序无法正常被中断。

3.5 全局解释器锁（GIL）与多线程执行

聊到虚拟机的执行过程，就必须提GIL。CPython解释器内部有一个全局锁，保证同一时刻只有一个线程能执行Python字节码。这个东西常被吐槽，但它其实换来了内存管理上的简单和稳定：不用在每一个对象访问上都加细粒度锁，解释器内部很多操作都因此省心。

GIL的存在意味着，纯Python计算密集型的多线程程序，在多个CPU核心上的加速效果很差。比如你用threading起8个线程做同样的数值计算，总耗时通常不会比单线程快多少，甚至因为切换开销而更慢。但涉及I/O操作（网络请求、文件读写）时，线程会在等待I/O时主动释放GIL，所以多线程做I/O密集型任务仍然有效。

你可能遇到过一个奇怪的现象：某些Python代码跑多线程时CPU占用率能超过100%，但程序总时间并没有下降。这说明解释器在频繁切换线程，GIL竞争消耗了不少资源。这时更好的选择是用多进程（multiprocessing）让每个进程都有独立解释器和GIL，或者把热点计算用C扩展、第三方加速库来解决。

4. 对象模型与内存管理对执行过程的深层影响

4.1 一切皆对象：变量名只是指向对象的标签

很多人刚学Python时，都会听到“万物皆对象”这句话。真正理解它要从执行的角度看：Python中的变量不是一个内存盒子，而是一个指向对象的名字（引用）。对象在堆里，变量名在命名空间里映射到对象。

用代码说明：

a = [1, 2, 3] b = a b.append(4) print(a) # [1, 2, 3, 4]

当b = a执行时，只是把同一个列表对象的引用复制给了b，并没有复制列表本身。因此b.append(4)修改的是同一个对象，a也跟着变。

再比如整数是不可变对象：

x = 1 y = x x = 2 print(y) # 1

这里x = 2并不是把1变成2，而是让x指向另一个整数对象2，y仍然指向1。理解这一点后，你就不会在函数参数传可变对象时踩到“函数里改了参数影响外部”的坑。

4.2 引用计数与垃圾回收

CPython给每个对象维护了一个引用计数字段。当一个对象被创建时引用计数为1；每次有其他变量引用它、放进容器、或者作为参数传递时计数加1；每次引用消失时计数减1。计数变0时对象立刻被回收，内存被释放。

这个设计让内存回收非常及时，但它也有坑。循环引用就是典型场景：两个对象互相引用，或者容器里引用自己，这时它们的引用计数永远不会降到0，于是需要额外的垃圾回收器来回收这类“不可达但还有引用关系”的对象。这就是gc模块存在的意义。

你可以主动查看某个对象的引用计数：

import sys obj = [] print(sys.getrefcount(obj)) # 至少有2，一个来自obj，一个来自getrefcount参数

用gc.collect()可以手动触发一次回收。平时写代码时不必过度关心GC，但有几个建议值得记住：

• 大量创建临时循环引用时，可以考虑及时断开手动引用。
• 在__del__方法里做清理逻辑要小心，可能因为循环引用导致延迟执行。
• 写长期运行的服务时，不要把大对象无限期挂在全局列表里，该清理就清理。

4.3 小整数缓存、字符串驻留与可变默认参数

执行过程中的一个常见性能误读是“整数比较很慢”。实际上CPython提前创建了-5 ~ 256范围内的小整数对象，任何代码里用到这些数字时，都会直接复用缓存对象，不会新建。因此a = 100; b = 100; a is b的结果是True，而a = 257; b = 257; a is b的结果是False。

字符串驻留（intern）也有类似效果，短字符串和看起来像标识符的字符串在CPython中会被复用，但不要依赖is来做字符串比较，官方明确建议必须使用==。

另一个典型的执行陷阱是“可变默认参数”。看这个函数：

def append_item(item, store=[]): store.append(item) return store

函数定义时store=[]这个列表对象只被创建一次。每次调用如果没传store，用的都是同一个列表，于是两次调用会互相影响。这就是因为Python的默认参数是在函数定义时求值并被保存到函数对象里的，不是每次调用时重新创建。正确写法是使用None哨兵值：

def append_item(item, store=None): if store is None: store = [] store.append(item) return store

这种情况之所以容易中招，恰好是执行模型里“一切皆对象、函数也是对象、函数默认值保存在函数对象属性里”的自然结果。理解了执行过程，这类问题就不再是靠记忆踩坑来避开了，而是顺理成章的推论。

5. 实操：用调试工具“看到”执行过程

5.1 用sys.settrace追踪每一行执行

有时候你想知道程序实际跑了哪几行，有没有进某个分支，可以用sys.settrace注册一个追踪函数，每执行一行字节码指令时它就会被回调。下面是一个简单的追踪器示例：

import sys def trace_events(frame, event, arg): if event == 'line': print(f"行号: {frame.f_lineno}, 文件: {frame.f_code.co_filename}") return trace_events def demo(): x = 1 y = 2 z = x + y return z sys.settrace(trace_events) demo()

输出会让你直观看到执行顺序和跳转位置。这个能力也是调试器（比如pdb）的底层实现基础。你自己写小工具时也可以在事件回调里检查局部变量、条件判断，甚至可以在此基础上实现一个极简的“单步调试器”。

注意，追踪回调会影响执行性能，生产环境千万不要全局开着它跑业务代码，只适合小范围研究。

5.2 用dis分析热点函数字节码

如果你的代码里有性能热点，先用dis.dis看看该函数生成的字节码，往往比肉眼猜“哪里慢”更准确。如果一段代码生成了一长串循环相关的指令（FOR_ITER、STORE_FAST、LOAD_FAST），而你又能用列表推导式或C内置函数把其中大部分指令替换掉，那性能提升通常肉眼可见。

举个例子，找出小于n的所有奇数，常见的写法是：

odds = [] for i in range(n): if i % 2 == 1: odds.append(i)

用列表推导式：

odds = [i for i in range(n) if i % 2 == 1]

两者功能等价，但列表推导式在CPython里内部执行结构更紧凑，少了多次LOAD_FAST/STORE_FAST和属性查找操作。用timeit测在大列表上会有明显差距，特别是嵌套循环场景更明显。

5.3 用cProfile找出执行时间分布

想了解整个程序的时间都花在哪个函数上，cProfile是最简单的工具：

python -m cProfile -s cumulative demo.py

它会输出每个函数的累计调用次数、总耗时和单次耗时。看到某个函数占了90%的时间后，再用dis对那个函数做细看，然后针对性优化。这种方式比“感觉某段代码慢”更科学。

5.4 从执行模型出发的性能优化清单

结合前面的解释，我整理一份可落地的优化清单：

• 优先使用局部变量，避免在循环中频繁读取全局变量。
• 多使用内置函数和标准库容器操作，它们用C实现，比自定义Python循环快很多。
• 尽量把数据批量操作交给numpy这类“把计算推到解释器外部”的库。
• 列表推导式和高阶函数（如map、filter）不一定总是最快，建议实测对比。
• 频繁拼接字符串用join，不要用循环里的+。
• 性能测试以timeit和cProfile为准，不要凭直觉。

如果你对执行模型已经比较熟，还可以去看CPython内部的ceval.c和Objects目录，那里是虚拟机真正发生的地方。建议从ceval.c里调研_PyEval_EvalFrameDefault函数，你会看到上百条指令的分发逻辑，这部分可以说是Python“心脏”的核心。

6. 常见异常与执行模型导致的坑

6.1 报错信息背后的执行过程含义

很多初学者在写Python时报错后一头雾水，其实每个错误都对应执行过程中的某个环节：

SyntaxError和NameError的区别特别说明执行过程的意义：前者根本还没跑到“执行”，后者是字节码已经跑起来了、在解析变量名时才暴露的问题。所以当你看到SyntaxError，别急着调试变量值，先去检查语法和缩进。

6.2 一个常见的“无边界局部变量”案例

看这段代码：

x = 100 def func(): print(x) x = 200 func()

直觉上你可能觉得先打印100，然后赋值200。但实际上运行时报：

UnboundLocalError: cannot access local variable 'x' where it is not associated with a value

原因就是编译器扫描整个函数体时，发现x出现在赋值运算符左边，于是把它判定为局部变量。局部变量还没被赋值前，读取它就会报错，哪怕函数外部存在同名全局变量。解决方法是加global x声明，或者避免在函数里混用同名的全局变量。理解编译时“变量作用域由赋值位置决定”这一点以后，就不会再踩这个坑了。

6.3 循环导入为何总会执行一半

两个模块互相导入也是很多项目的经典问题。假设有a.py和b.py，a.py顶部import b，b.py顶部import a。当你执行import a时，解释器先把a放入sys.modules作为“正在导入”的模块，然后执行import b；b的第一行又尝试导入a，此时从sys.modules中拿到的a还是没完成初始化的空模块，于是运行b里的a.something时往往报AttributeError或ImportError。

这个现象同样根植于执行过程：模块是自上而下执行的代码集合，导入只是让解释器找到并运行那个模块的顶层代码。循环导入的本质是“代码在尚未定义完的时候就试图访问另一个未定义完的模块”。解决办法很简单，把公共代码抽到第三个模块，或者在函数内部导入，延迟到真正需要时再执行导入语句。

6.4 调试建议：写代码时长按“解释器视角”思考

根据我的经验，与其死记大量“踩坑笔记”，不如在做性能优化和排查异常时多问自己几个问题：

• 这条语句会被编译成哪几条字节码？
• 这个变量名是在哪里被创建并存储的？
• 这个对象到底有多少个引用？谁拥有它？
• 当下执行到了哪个帧？栈上还有什么？

这几个问题看似抽象，但想明白后，绝大多数Python运行时报错对你来说都会有清晰的方向。因为你对“程序是怎么跑起来的”已经有了整体地图，看到报错能直接定位到地图上的哪一段出了岔子。

结束语：用执行过程知识反哺日常开发

我个人在实际操作中最大的体会是：把执行过程当成一张地图而不是一堆术语。刚学的时候，我也觉得词法分析、字节码、栈帧这些名词离自己很远，后来慢慢发现，越深入越能反哺日常开发。比如我看到一个函数跑了很久，第一反应是先看它的字节码和调用次数，而不是盲目优化；我遇到变量作用域问题，也不再靠猜，而是去看代码对象里的co_varnames；我处理循环引用的内存占用时，会主动gc.get_referrers找引用链。

最后再分享一个小技巧：每当你写完一个比较复杂的功能，可以顺手跑一次python -m trace --trace 你的脚本.py，观察它到底执行了哪些行，这比单步调试更能建立“程序正在逐指令运行”的实感。坚持一段时间以后，你会发现自己看代码时脑子里会自动浮现出那些LOAD_FAST、BINARY_OP、RETURN_VALUE的画面。到那个阶段，Python对你来说就不再是一门“看着能用但内部神秘”的语言了，而是一套逻辑清晰、可以推断、可以驾驭的执行系统。