VSCode Python断点调试需正确配置launch.json、理解断点触发条件及变量作用域；module/file模式影响路径与导入，cwd和PYTHONPATH须匹配；变量仅在当前栈帧可见，Watch比悬停更可靠；args/env/console需协同配置；justMyCode=true默认跳过第三方库。
VSCode 的 Python 断点调试不是“点一下就全懂”，关键在于理解 launch.json 配置、断点触发条件和变量作用域边界。直接开调往往卡在“为什么没停”或“变量显示 undefined”上。
为什么加了断点却不暂停？检查 launch.json 的 module 和 file 模式
VSCode 调试器默认按两种方式启动：作为模块运行（"module": "xxx"）或作为脚本文件运行（"program": "xxx.py"）。两者加载路径、__name__ 值、包导入行为完全不同。
- 用
"module": "myproject.main"时，必须确保myproject/在PYTHONPATH或已安装为可导入包；否则断点会灰掉（未绑定） - 用
"program": "./src/main.py"时，路径必须是相对于cwd（工作目录），且cwd默认是打开的文件夹根目录 —— 如果你在子目录里打开 VSCode，program路径很可能错 - 常见错误：
"program": "main.py"（缺./）→ VSCode 找不到文件，静默失败，断点不生效
调试时变量显示 undefined 或值为空？确认作用域与求值时机
Python 调试器（ptvsd / debugpy）只在当前栈帧中展示局部变量。如果在函数外设断点，却想看函数内部变量，那是看不到的；反之，在循环内设断点，但变量名被循环覆盖（如 item），每次暂停看到的只是当前迭代的值。
- 不要依赖“悬停查看”所有变量 —— 某些动态生成的属性（如
__dict__里的键）、lambda内部变量、C 扩展对象属性可能无法实时读取 - 右键变量 → “Add to Watch” 是更可靠的方式，Watch 表达式支持完整 Python 语法，比如
len(my_list)、response.json().get('data') - 若变量名含点号（如
user.profile.name），Watch 中需写成完整表达式，不能只写user然后点展开 —— 展开有时因延迟或懒加载失败
如何调试命令行参数或环境变量？别只改 args，还要配 env 和 console
args 字段传的是 sys.argv[1:]，但很多脚本依赖 os.environ（比如数据库 URL、密钥）或需要交互式终端（如 input()）。
立即学习“Python免费学习笔记（深入）”；
-
"args": ["--verbose", "--input=data.csv"]→ 对应命令行python main.py --verbose --input=data.csv -
"env": {"DEBUG": "1", "DATABASE_URL": "sqlite:///dev.db"}→ 必须显式声明，继承自系统环境变量的值不会自动带入调试会话 -
"console": "integratedTerminal"或"externalTerminal"→ 否则input()会卡住，因为默认internalConsole不支持标准输入
{
"version": "0.2.0",
"configurations": [
{
"name": "Python: Script",
"type": "python",
"request": "launch",
"module": "myapp.cli",
"args": ["run", "--dry-run"],
"env": {
"LOG_LEVEL": "DEBUG",
"ENV": "test"
},
"console": "integratedTerminal",
"justMyCode": true
}
]
}
justMyCode 开关影响很大，别盲目设为 false
该选项控制是否跳过标准库、第三方包代码。设为 true（默认）时，按 F11 进入函数，如果函数来自 requests 或 numpy，调试器会直接跳出到下一行 —— 这不是 bug，是设计行为。
- 想进第三方库源码？先确认已安装对应包的源码（非 wheel），且
justMyCode设为false；但代价是：你会频繁停在import、logging等底层逻辑里 - 真正需要的往往是“只进我自己的包”，此时应配合
"subProcess": true和"pathMappings"（尤其在 Docker 或远程调试时） - 最易忽略的一点：
justMyCode对eval、exec动态执行的代码无效 —— 那部分永远算作“我的代码”，但变量上下文可能丢失
断点调试不是线性流程，而是反复验证“这里是否如我所想”的过程。很多人卡住，是因为把断点当成了“暂停按钮”，而忽略了它背后依赖的路径解析、作用域链和调试器通信机制。多看一眼 DEBUG CONSOLE 里的报错，比反复重启调试会话更有效。
