Python 字节码在执行阶段的作用

python字节码是cpython虚拟机专用指令集，非cpu直接执行的机器码，依赖代码对象完整元数据，跨版本兼容性差，手动修改极易失败。

Python 字节码不是解释器直接执行的“机器指令”

CPython 解释器运行时，真正调度和执行的是 PycCodeObject 结构里的字节码序列（co_code），但它从不直接当 CPU 指令用。字节码是 CPython 虚拟机（PVM）的指令集，每条指令对应一个 C 函数（如 PyEval_EvalFrameEx 中的 case POP_TOP: 分支）。你看到的 .pyc 文件只是缓存，加载后会被反序列化成内存中的代码对象，执行时走的是纯 C 的跳转逻辑。

• 字节码长度固定为 2 字节（操作码 + 参数），但参数是否使用、如何解码，取决于操作码本身（比如 LOAD_CONST 用 2 字节参数索引 co_consts，而 POP_BLOCK 无参数）
• 不要试图用 dis.dis() 输出去“手写字节码”——操作码常量（如 100 对应 LOAD_CONST）在不同 Python 版本间不保证一致，opcode.opmap 才是唯一可信映射
• 字节码里没有变量名、注释、空行信息；所有符号都已解析为索引（co_names、co_varnames），调试时看到的行号来自 co_lnotab（或 3.10+ 的 co_linetable），它和字节码是分离存储的

为什么改字节码通常不如重写函数来得可靠

有人想 patch 字节码绕过校验或注入逻辑，但实际落地极容易失败。因为字节码不是独立可执行单元，它强依赖所属代码对象的全部元数据：栈深度（co_stacksize）、局部变量数量（co_nlocals）、常量/名字表结构。哪怕只改一条 LOAD_CONST 的参数，若新常量不在 co_consts 里，运行时抛 SystemError: unknown opcode 或更隐蔽的 IndexError。

• types.FunctionType(code, globals(), name) 可以动态构造函数，但传入的 code 必须是合法的 codeobject，不能是 raw bytes；用 marshal.loads() 反序列化自己拼的字节流大概率触发 ValueError: bad marshal data
• 装饰器或 sys.settrace 在多数场景下比字节码 patch 更安全——前者在 Python 层拦截调用，后者只影响当前线程且开销明确
• Python 3.11 引入自适应字节码（adaptive bytecode），某些指令（如 BINARY_OP）会在运行时被 PVM 替换为更快的专用版本（BINARY_OP_ADD_INT），此时你 patch 的原始字节码可能根本不会被执行

调试时看字节码，重点盯三处位置

用 dis.dis(func) 不是为了背指令，而是快速定位执行瓶颈或语义歧义点。重点关注：co_firstlineno（源码起始行）、co_stacksize（最大栈深）、以及跳转指令的目标偏移（JUMP_IF_TRUE_OR_POP 后面的数字）。这些值直接影响性能和异常行为。

• 循环体字节码重复出现？检查是否无意中写了 for x in range(1000): func() 而非 func() 一次——CALL_FUNCTION 开销远高于纯计算指令
• 同一行源码编译出多条字节码？比如 a.b.c = d 拆成 LOAD_NAME → LOAD_ATTR → LOAD_ATTR → STORE_NAME，中间任意一环抛异常，traceback 显示的都是同一行，但实际失败点可能在第二个 LOAD_ATTR
• RETURN_VALUE 前有没有 POP_BLOCK 或 POP_EXCEPT？这关系到 finally 块是否能正确执行——字节码层面 finally 是靠显式插入的清理指令保障的，不是语法糖

字节码兼容性比想象中脆弱

不同 Python 小版本之间，字节码格式可能静默变更。比如 Python 3.7 废弃了 SETUP_LOOP，3.11 把 CALL_FUNCTION 和 CALL_METHOD 合并为 CALL。这意味着用 3.10 生成的 .pyc 文件，在 3.11 下无法加载，报错是 ImportError: bad magic number，而这个 “magic number” 就藏在 .pyc 文件头前两个字节里，对应 py_compile.PYC_MAGIC_NUMBER。

立即学习“Python免费学习笔记（深入）”；

• 跨版本分发二进制模块？别打包 .pyc，老老实实发源码或用 pyoxidizer / cx_Freeze 打包整个解释器
• 用 compile() 动态生成代码对象时，明确指定 flags 参数（如 ast.PyCF_ONLY_AST）比依赖默认值更可控；省略 filename 参数会导致 co_filename 变成 '<String>'</string>，影响日志和 profiling 工具识别
• 字节码对象的 __reduce__ 方法不可靠——它不保证返回可安全 unpickle 的结果，尤其含闭包或 cellvar 的函数，反序列化后常丢变量绑定

事情说清了就结束。字节码不是黑箱，但它的边界比多数人想的窄：它只对 CPython 有效，只在代码对象生命周期内有效，且每一处改动都要同步校验所有关联元数据。真要动它，先问自己是不是非得绕过 Python 层不可。