dis.dis() 看不到完整字节码是因为默认不递归展开嵌套函数、闭包或装饰器逻辑，且延迟编译代码（如lambda、eval）无法静态分析；应传入func.__code__并配合dis.show_code()查看元信息以准确定位问题。
dis.dis() 为什么看不到函数内部的完整字节码？
直接对函数调用 dis.dis(func) 有时只显示顶层指令，尤其当函数含嵌套定义、闭包或装饰器时。Python 会把部分逻辑延迟到运行时生成（比如 lambda 或 eval 中的代码），dis.dis() 默认不递归展开。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 确认目标对象是已编译的代码对象：用
func.__code__替代func，确保传入的是code object - 对嵌套函数，需单独获取其
__code__，例如inner_func.__code__ - 装饰器包装后的函数，
__code__可能属于装饰器逻辑而非原函数，优先用functools.wraps保留原始__code__
如何对比不同写法的字节码差异？
字节码差异直接影响性能和行为，比如 for i in range(10) 和 for i in [0,1,2,3,4,5,6,7,8,9] 看似等价，但字节码完全不同——前者用 GET_ITER + FOR_ITER，后者多出构建列表的 BUILD_LIST 指令，且占用更多内存。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 用
dis.Bytecode(func).dis()获取结构化字节码对象，便于程序化比对 - 关注关键指令：如
LOAD_GLOBAL（查全局变量）、LOAD_FAST（查局部变量）、CALL_FUNCTION（函数调用开销） - 注意 Python 版本差异：3.11 引入自适应字节码（adaptive bytecode），同一段代码在不同运行阶段可能被 JIT 优化为不同指令
dis 模块无法反向还原源码，那它能帮你定位什么问题？
dis 不是反编译工具，但它能暴露隐性行为。比如你怀疑某个 if 判断没进分支，实际可能是短路求值导致条件表达式根本没执行；又或者 list.append(x) 被写成 list += [x]，后者会触发 INPLACE_ADD 并尝试调用 __iadd__，而列表虽支持，但元组不支持——这时字节码里会出现 BINARY_ADD 回退，影响性能。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 遇到“明明写了却没执行”的逻辑，先看对应条件表达式的字节码是否被跳过（检查
POP_JUMP_IF_FALSE/POP_JUMP_IF_TRUE的目标偏移） - 排查属性访问慢：若频繁
obj.attr出现大量LOAD_ATTR，考虑缓存为局部变量（attr = obj.attr），字节码会从LOAD_ATTR变成LOAD_FAST - 注意
dis不显示 C 扩展调用细节，如numpy.array()内部全是一条CALL_FUNCTION，无法进一步拆解
为什么 dis.show_code() 比 dis.dis() 更值得习惯性使用？
dis.show_code(func) 会打印函数名、参数个数、常量、变量名、自由变量等元信息，这些对理解字节码上下文至关重要。比如看到 co_freevars = ('x',) 就知道有闭包变量 x，对应字节码中会出现 LOAD_DEREF 而非 LOAD_FAST；又比如 co_consts 里出现 None 和整数，说明函数内有字面量，但没字符串——这可能暗示日志或错误信息被删减了。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 每次分析前先跑一遍
dis.show_code(func)，建立符号表映射关系 - 结合
co_varnames和字节码中的LOAD_FAST参数索引，快速定位变量作用域 - 如果
co_nlocals == 0却有LOAD_FAST指令，说明代码对象可能来自exec或compile动态生成，此时需检查编译模式（mode='exec'vs'eval'）
INSTRUCTION，而是把字节码指令流、符号表、运行时栈状态三者串起来——比如一条 CALL_FUNCTION 前的几个 LOAD_* 是怎么压栈的，返回值又落在哪。没有调试器辅助时，dis 提供的是线索，不是答案。 
