VS Code 默认不调试子线程，需在 launch.json 中设置 "subProcess": true 和 "justMyCode": false 才能使 threading.Thread 中的断点生效。
VS Code 默认无法在子线程中命中断点，必须显式启用多线程调试支持，否则 threading.Thread 启动的代码会直接跳过断点。
为什么断点在子线程里不生效
Python 的 debugpy（VS Code Python 扩展默认调试器）默认只附加到主线程。子线程由 threading 模块创建后，调试器不会自动监听其执行上下文，导致断点灰色、无响应或直接跳过。
这不是代码写错了，是调试器配置缺失。常见现象包括：
- 断点显示为空心圆（未绑定），悬停提示 “Breakpoint ignored because no symbols have been loaded”
- 主线程能停，
target函数里的断点完全不触发 - 加了
import time; time.sleep(1)也抓不到——不是执行太快，是根本没被调试器接管
必须在 launch.json 中启用 subProcess 和 justMyCode
VS Code Python 调试依赖 debugpy 的子进程调试能力。仅靠 "justMyCode": false 不够，必须同时开启 "subProcess": true，才能让调试器注入并跟踪所有线程。
正确配置片段如下（放在 .vscode/launch.json 的对应配置中）：
php版微信js-sdk支付接口类
php版微信js-sdk支付接口类
{
"name": "Python: Multi-threaded",
"type": "python",
"request": "launch",
"module": "your_module", // 或用 "program" 指向脚本
"console": "integratedTerminal",
"subProcess": true,
"justMyCode": false,
"env": {
"PYTHONPATH": "${workspaceFolder}"
}
}
-
"subProcess": true是关键开关，它让debugpy监听所有派生线程（含threading.Thread和concurrent.futures.ThreadPoolExecutor） -
"justMyCode": false避免调试器跳过非当前文件的调用栈帧（比如threading内部调度逻辑），否则可能卡在底层而无法进入你的target函数 - 不要设
"stopOnEntry": true，它只对主线程有效，反而干扰子线程断点捕获
验证是否真正生效：用最小可复现脚本测试
别依赖已有项目直接开调，先写一个三行脚本能确认环境就绪：
import threading import timedef worker(): time.sleep(0.1) print("break here") # ← 在这行打断点 return 42
t = threading.Thread(target=worker) t.start() t.join()
操作步骤：
- 在
print("break here")前加断点 - 用上面配置的 launch 配置启动调试
- 若断点实心且能停住 → 配置成功；若仍跳过 → 检查
subProcess是否拼写为subprocess（错误小写）或被其他配置覆盖 - 注意：首次启用
subProcess后，控制台输出可能变慢（因调试器注入开销），属正常现象
进阶注意：ThreadPoolExecutor 和 daemon 线程的差异
ThreadPoolExecutor 底层仍走 threading.Thread，同样受 subProcess 控制；但 daemon=True 的线程在主程序退出时会被强制终止，可能导致断点“看起来没命中”——其实是线程被杀掉了，不是调试失败。
- 调试期间避免设
daemon=True，改用t.join()或executor.shutdown(wait=True)确保线程完成 - 如果用了
asyncio.to_thread()（Python 3.9+），它内部封装的是线程池，同样适用上述配置 -
multiprocessing是另一套机制，需要"subProcess": true+ 单独启用"multiprocess": true（且要求 Python ≥ 3.8）
真正卡住人的地方往往不是语法或逻辑，而是调试器根本没看到那个线程——配错一个字段，就白等十分钟。每次换环境（比如新装 WSL 或切换 Python 版本），都值得重跑一遍那个三行 worker 脚本确认。