Python调试失效主因有三：breakpoint()受PYTHONBREAKPOINT环境变量及优化模式影响；pdb.set_trace()在exec/eval、装饰器、异步函数中因帧上下文丢失而无法访问局部变量；VS Code断点不命中源于debugpy的launch/attach模式配置差异及解释器路径不匹配。
Python 调试不是靠反复加 print() 硬扛出来的，核心在于理解 sys.settrace()、breakpoint() 底层如何接管执行流，以及调试器（如 pdb、ipdb、VS Code 的 debugpy）怎么和解释器协同工作。
为什么 breakpoint() 在某些环境里不生效？
Python 3.7+ 引入的 breakpoint() 并非“万能断点”，它本质是调用 os.environ.get("PYTHONBREAKPOINT", "pdb.set_trace") 指定的可调用对象。常见失效场景：
-
环境变量
PYTHONBREAKPOINT=""（空字符串）会直接跳过断点，什么也不做 - 在 Jupyter 中未安装
ipdb，而PYTHONBREAKPOINT设为"ipdb.set_trace"，会抛出ModuleNotFoundError - 使用
python -O（优化模式）运行时，breakpoint()被编译器直接移除，等价于pass
验证方式：运行
import os; print(os.environ.get("PYTHONBREAKPOINT"))，再检查对应模块是否可导入。
pdb.set_trace() 进入后，为什么看不到局部变量？
典型现象是输入 p x 或 pp locals() 报 NameError: name 'x' is not defined，根本原因是当前帧（frame）上下文没被正确捕获——多见于以下情况：
立即学习“Python免费学习笔记（深入）”；
- 代码在
exec()或eval()动态执行时，未显式传入locals和globals参数，导致pdb无法访问作用域 - 装饰器或异步函数（
async def）中直接调用pdb.set_trace()，因协程未真正进入执行帧，pdb拿到的是包装器的空帧 - 使用了
functools.wraps但未同步__code__或__globals__，造成帧对象元信息错乱
稳妥做法：改用
import pdb; pdb.Pdb().set_trace()，它绕过自动帧推导，强制使用当前栈帧。
VS Code 断点不命中？先查 debugpy 的 attach 模式与 launch 模式区别
VS Code 默认用 debugpy 调试，但 launch（启动新进程）和 attach（接入已有进程）对路径、工作目录、Python 解释器路径的解析逻辑完全不同：
-
launch模式下，"cwd"配置决定sys.path[0]和相对导入起点；若没设，可能从 VS Code 打开目录开始解析，导致模块找不到 -
attach模式依赖目标进程已用debugpy.listen()启动监听，且客户端配置的"host"/"port"必须与服务端完全一致；端口被占或防火墙拦截时，VS Code 控制台只显示 “Connecting…” 无报错 - 混合使用虚拟环境和全局 Python：
"python"路径必须指向实际运行代码的解释器，否则debugpy加载的包路径和你pip install的位置不匹配
快速验证：在代码开头加
import sys; print(sys.executable, sys.path)，对比 VS Code debug 控制台输出和终端
python script.py 输出是否一致。
真正卡住的往往不是“怎么打断点”，而是 trace 函数如何被注入、帧对象怎么被提取、调试协议（DAP）消息怎么序列化——这些细节一旦错位，表现就是“看起来写了断点，却像没写”。
