subProcess: true 必须配合 spawn 启动方式才能启用子进程调试，因 fork 模式下 debugpy 无法注入；需在 if name == '__main__': 中调用 mp.set_start_method('spawn')，worker 函数须定义在模块顶层且可被直接 import。
subProcess: true 必须配合 spawn 启动方法
VSCode 的 Python 扩展在 1.75+ 版本后支持子进程调试，但 subProcess: true 不是万能开关。它只对使用 spawn 启动方式的子进程生效 —— 因为 fork 模式下子进程不重新导入模块，debugpy 无法注入调试逻辑。
Windows 上无需额外操作（默认且唯一支持 spawn）；macOS/Linux 必须显式设置：
-
import multiprocessing as mp后，在if __name__ == '__main__':块内调用mp.set_start_method('spawn') - 避免在子进程中触发
os.fork()或依赖 fork 初始化的库（如某些 NumPy 版本） - 若用
concurrent.futures.ProcessPoolExecutor，确认 Python ≥ 3.8，且未被MP_START_METHOD环境变量覆盖
子进程函数必须可被模块直接 import
断点进不去子进程最常见的原因是函数定义位置错误：VSCode 子进程调试依赖 Python 的 import 机制加载代码，而 if __name__ == '__main__': 块内定义的函数在子进程中不可见。
报错典型提示：AttributeError: module '__mp_main__' has no attribute 'worker'。
- 把 worker 函数移到模块顶层，和
import语句同级 - 不要嵌套在
main()、类方法、闭包或条件块中 - 如果用
"module": "myapp.main"启动，确保myapp.main能直接import worker，路径无相对导入陷阱
launch.json 关键字段必须协同生效
subProcess: true 单独开启无效。它需要终端上下文、调试器可见性、模块路径三者配合才能让子进程真正连上 debugpy。
- 必须设
"console": "integratedTerminal"：spawn 模式下子进程需终端环境，否则静默退出 - 建议加
"justMyCode": false：避免因进入 multiprocessing 启动逻辑（如_bootstrap_parent）跳过断点 - 推荐加
"env": {"PYTHONPATH": "${workspaceFolder}"}：确保子进程能找到本地模块，尤其涉及相对导入时 - 禁用已弃用的
pythonPath字段，统一通过 VSCode 右下角解释器选择器管理
断点失效时优先看调试控制台和进程树
灰色空心断点、控制台无输出、子进程秒退——这些不是配置“没生效”，而是某个硬性条件被绕过了。
- 启动调试后立刻看调试控制台首行：必须含
debugpy version X.X.X；若出现ptvsd或Failed to initialize debugger，说明调试器版本异常 - 子进程启动后立即查进程树：
ps aux | grep python（macOS/Linux）或任务管理器（Windows），确认子进程存在且命令行含--mp标识 - 若子进程存在但无调试日志，检查是否误用了
fork启动方法，或 worker 函数不可 import
spawn + 顶层函数 + integratedTerminal —— 这三个条件缺一不可，任意一个松动，子进程就脱离调试器视野。实际调试中，最容易被忽略的是 macOS/Linux 上忘记显式调用 mp.set_start_method('spawn')，默认 fork 表面运行正常，实则断点完全失效。
