断点没反应最常见的原因是调试配置与Python解释器不匹配，需通过Python: Select Interpreter选择正确解释器并确保launch.json中python字段一致；多进程需启用"subProcess": true；修改代码后应重新启动而非继续。
为什么断点没反应？检查调试配置是否匹配Python解释器
VSCode 调试 Python 失效，最常见原因是 launch.json 中指定的 Python 解释器路径和当前终端/虚拟环境不一致。VSCode 不会自动继承你在终端里激活的 venv 或 conda 环境，必须显式配置。
- 打开命令面板（
Ctrl+Shift+P），运行Python: Select Interpreter，选中你项目实际使用的解释器（比如./venv/bin/python或~/miniconda3/envs/myenv/bin/python） - 确认
.vscode/launch.json中的python字段值与之匹配；若未生成该文件，点击左侧调试图标 → “创建 launch.json” → 选择 “Python File”，VSCode 会自动生成基础配置 - 如果用的是 Poetry 或 PDM，需手动将
"python"改为"poetry run python"或对应命令，否则断点加载失败且无报错提示
如何在函数内部快速跳转并查看变量？善用调试控制台与悬停提示
比起反复加 print()，VSCode 的调试控制台（Debug Console）和变量悬停更高效，但很多人忽略它的交互能力。
- 断点暂停后，直接在 Debug Console 中输入变量名（如
data）回车，可实时求值；支持完整 Python 表达式，比如len(data)、data[:3] - 鼠标悬停在变量上会显示类型和简略值；对复杂对象（如
pd.DataFrame、嵌套字典），点击右侧「▶」可展开查看结构 - 右键变量 → “Add to Watch” 可持续监控其变化；Watch 面板支持表达式，例如
response.status_code == 200会动态显示布尔结果
调试多进程/多线程脚本时为什么只停在主进程？启用子进程调试需额外配置
默认情况下，VSCode 的 Python Debugger（ptvsd / debugpy）仅附加到主进程，子进程中的断点会被忽略，尤其影响 multiprocessing 或 concurrent.futures 场景。
- 在
launch.json中添加"subProcess": true（debugpy ≥ 1.6.0 才支持） - 若使用
multiprocessing，确保子进程启动方式为spawn或forkserver（Windows 必须用spawn），fork模式下子进程可能无法被正确附加 - 对 Flask/FastAPI 等 Web 服务，启动时加上
--no-reload参数，避免热重载 fork 出的新进程绕过 debugger
为什么修改代码后 F5 重启仍运行旧逻辑？留意调试缓存与模块导入路径
这不是 VSCode 的 bug，而是 Python 模块缓存机制导致的——即使你改了源码，已导入的模块不会自动重载，调试器仍执行旧字节码。
立即学习“Python免费学习笔记（深入）”；
- 每次修改关键逻辑后，务必点击调试工具栏的「重新启动」（而非「继续」），确保从头加载模块
- 避免在调试会话中用
importlib.reload()手动重载，容易引发状态不一致；更适合的做法是把待测逻辑封装成函数，在 Debug Console 中直接调用新版本 - 检查
sys.path是否包含多个同名模块路径（比如当前目录和 site-packages 都有utils.py），调试器可能导入了错误位置的文件
真正卡住调试效率的，往往不是功能不会用，而是解释器不一致、子进程未启用、模块缓存未清这三类隐性问题。它们不报错，但让断点形同虚设。
