dis.dis() 显示函数编译后的CPython字节码（含操作码、参数及源码行号），但不显示运行时栈状态、变量值或JIT优化结果；它能揭示语法糖背后的隐式开销，却无法反映底层实现差异（如in对list/set的不同行为）。
dis.dis() 能看到什么，不能看到什么
直接调用 dis.dis(func) 输出的是函数编译后的 CPython 字节码指令流，包括操作码（如 LOAD_FAST、BINARY_ADD）、参数（如变量索引或常量位置）和对应源码行号（如果有）。它不显示执行时的栈状态、变量实际值或 JIT 优化结果——CPython 3.12 之前没有 JIT，dis 看到的就是最终执行的字节码。
常见误判是把字节码长度等同于性能：少一条 LOAD_GLOBAL 不一定快，但多一层循环嵌套大概率增加 FOR_ITER 和跳转开销。重点看重复出现的高开销指令，比如频繁的 LOAD_ATTR 或未缓存的 CALL_FUNCTION。
对比不同写法的字节码差异
同一逻辑的不同实现，字节码可能天差地别。比如列表推导式 vs map() vs 显式 for 循环：
def f1(): return [x*2 for x in range(10)]
def f2(): return list(map(lambda x: x*2, range(10)))
def f3():
res = []
for x in range(10):
res.append(x*2)
return res
运行 dis.dis(f1) 会看到紧凑的 GET_ITER → FOR_ITER → LOAD_CONST → BINARY_MULTIPLY；而 f2 多出 LOAD_GLOBAL 查找 map 和 list，还有额外的函数调用开销（CALL_FUNCTION）；f3 则包含多次 LOAD_METHOD 和 CALL_METHOD。
立即学习“Python免费学习笔记（深入）”；
- 局部变量访问用
LOAD_FAST（快），全局变量用LOAD_GLOBAL（慢），避免在循环内反复查全局名 -
lambda在字节码里仍生成函数对象，不是“内联”，map还要额外构造迭代器 - 属性访问（
obj.attr）编译为LOAD_ATTR，若在循环中高频调用，考虑提前赋值给局部变量
定位隐藏的隐式调用和开销
有些语法糖背后藏着昂贵操作，dis 是唯一能一眼识破的方式。例如：
字符串拼接：s += 'x' 在循环中会编译出 BINARY_ADD，但若 s 是 str，每次都会新建对象；而 ''.join(list) 对应的是 LOAD_METHOD + CALL_METHOD，只调用一次。
布尔上下文判断：if obj: 编译为 POP_JUMP_IF_FALSE，但触发 __bool__ 或 __len__ 方法调用——如果这些方法本身很重，dis 不会显示，但你可以结合 dis.dis(obj.__bool__) 单独检查。
-
in操作对 list 是CONTAINS_OP+ 循环查找；对 set/dict 是哈希查找，字节码一样，但底层行为不同 -
try/except块本身无开销，但一旦异常抛出，SETUP_EXCEPT后的栈帧构建和回溯收集成本很高 - 生成器函数（含
yield）字节码里有YIELD_VALUE，且整个函数对象带GEN_START标记，与普通函数完全不同
dis 本身不支持跨 Python 版本直接比对
3.11 引入了自适应字节码（adaptive bytecode），相同代码在不同运行时可能生成不同指令（如热点路径插入 ADAPTIVE 前缀）；3.12 进一步调整了部分指令语义。这意味着你在 3.11 上看到的 LOAD_GLOBAL，在 3.12 可能被替换成 LOAD_GLOBAL_ADAPTIVE，甚至合并成单条指令。
所以不要依赖字节码绝对数量做版本间性能断言。更可靠的做法是：
- 固定 Python 小版本（如 3.11.9）再横向比较不同写法
- 用
dis.get_instructions(func)提取指令列表，按opname和argval做程序化分析，而非肉眼数行数 - 配合
timeit实测，字节码只是辅助假设——比如看到大量LOAD_ATTR，就尝试用attr = obj.attr提前缓存，再验证是否提速
真正卡住性能的往往不是单条指令，而是指令组合暴露的模式：反复查找、重复构造、隐式类型转换。dis 不提供答案，但它会准确指出问题藏在哪一行字节码里。
