必须同时设置"subprocess": true和"justmycode": false,否则子线程断点不触发;前者启用对threading.thread等派生线程的监听,后者防止调试器将线程函数误判为第三方代码跳过。

必须同时设 subProcess: true 和 justMyCode: false,否则子线程断点永远不触发——这不是 bug,是 debugpy 的默认行为。
为什么子线程断点不生效
debugpy 默认只注入主线程,所有 threading.Thread 或 ThreadPoolExecutor 启动的子线程完全“隐身”。你看到断点变空心圆、悬停提示 “Breakpoint ignored because no symbols have been loaded”,或者 print 语句执行了但断点没停,基本都是这个原因。
常见误判包括:
- 以为只要升级 VSCode 就自动支持——其实依赖的是底层
debugpy版本和配置 - 只开
justMyCode: false 却漏掉subProcess: true——后者才是开关,前者只是配套兜底 - 断点打在
t = threading.Thread(target=worker); t.start()这一行——断点必须落在worker()函数体第一行可执行语句上
launch.json 关键配置项
在 .vscode/launch.json 的 Python 调试配置中,至少要包含以下三项:
-
"subProcess": true:强制 debugpy 监听所有派生线程(含threading和concurrent.futures) -
"justMyCode": false:避免调试器把线程函数误判为第三方代码跳过(尤其当目标函数嵌套在threading._start_new_thread调用链里时) -
"console": "integratedTerminal":推荐加上,防止多线程输出被 internalConsole 缓冲或丢日志
完整最小配置示例:
{
"name": "Python: Multi-threaded",
"type": "python",
"request": "launch",
"module": "your_main_module",
"subProcess": true,
"justMyCode": false,
"console": "integratedTerminal"
}
调试时怎么看子线程变量
VSCode 不提供“所有线程变量合并视图”,它只显示当前选中的调用栈帧上下文。
- 调试暂停后,左侧
CALL STACK面板会列出MainThread、Thread-1、Thread-2等——点击任一名称,Variables面板立即切换为其局部作用域 - 全局变量(模块级或
global声明的)在任意线程下都可见,但值是最新写入状态,不是快照,注意竞态 - 没暂停的线程(比如卡在
time.sleep(5)中)不会出现在CALL STACK里,这是正常行为 - 如果子线程运行太快(如只做一次计算就退出),debugpy 可能来不及注入钩子——临时加
time.sleep(0.1)延长存活窗口便于验证
最容易被忽略的环境前提
配置再对,环境不对也白搭。最常跳过的其实是两件事:
- 确认调试控制台顶部日志显示
debugpy version 1.6.0+;若出现ptvsd或Failed to initialize debugger,立刻执行:pip uninstall ptvsd和pip install --upgrade debugpy - 每次修改
launch.json后必须重启整个调试会话,热重载不生效
子线程调试不是“开了就能用”,而是“开了才可能用”——它依赖线程生命周期、断点位置、调试器注入时机三者对齐。别指望一次配完就万事大吉,先用三行 threading.Thread 脚本验证环境是否真正就绪。











