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 的函数，反序列化后常丢变量绑定
