必须同时设置"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 调试配置中，至少要包含以下三项：

VSCode

避免常见的 VSCode 错误——设置冲突、调试器配置和扩展冲突。

下载

• "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 脚本验证环境是否真正就绪。