VS Code调试Python多进程需手动启用子进程调试：在launch.json中设置"subProcess": true，并在子进程代码开头调用debugpy.listen()和debugpy.wait_for_client()。
VS Code 调试 Python 多进程应用默认不支持子进程断点，因为 Python 的 multiprocessing 模块会启动全新解释器进程，而 VS Code 的调试器只附加到主进程。要让子进程也能被调试，关键在于让每个子进程都主动连接到 VS Code 的调试服务（ptvsd 或 debugpy）。
启用 debugpy 并配置 launch.json
新版 VS Code Python 扩展已弃用 ptvsd，统一使用 debugpy（随 python extension 自动安装）。确保你已在项目中安装了 debugpy：
然后在 .vscode/launch.json 中添加以下配置（重点是 "subProcess": true）：
在子进程中手动触发调试器附加
仅靠 "subProcess": true 不够——它只对通过 multiprocessing.set_start_method("spawn") 启动、且子进程执行路径可被 VS Code 自动识别的场景有效。更可靠的方式是在子进程代码开头显式调用 debugpy.listen() 和 debugpy.wait_for_client()：
立即学习“Python免费学习笔记（深入）”；
import debugpy在子进程函数的最开始插入：
if name == "main":
避免重复监听（主进程不执行这段）
debugpy.listen(5678) # 端口需与 launch.json 中一致（默认 5678）
print("Waiting for debugger attach...")
debugpy.wait_for_client() # 阻塞直到 VS Code 附加
print("Debugger attached!")后续你的业务逻辑...
def worker(): import debugpy debugpy.listen(5678) debugpy.wait_for_client()
✅ 此处打的断点现在可以命中
避免常见陷阱
• 端口冲突：多个子进程不能共用同一监听端口。若需并发调试多个子进程，可为每个分配不同端口（如 5679、5680），并在 launch.json 中配合 "debugPort" 动态指定（需脚本生成配置）；更简单做法是只调试单个子进程，其余跳过调试逻辑。
• Windows + spawn 方法：Windows 默认用 spawn，必须保证子进程入口是 if __name__ == "__main__": 保护块，否则会无限递归创建进程。
• fork 方法不生效：Linux/macOS 默认 fork，子进程继承主进程的调试状态，但 VS Code 无法自动接管 fork 出的子进程。此时仍需手动调用 debugpy.listen()。
• 终端输出干扰：启用 "console": "integratedTerminal" 可看到子进程打印的 Waiting for debugger attach...，方便确认是否进入调试等待。
替代方案：用 attach 模式逐个调试
如果 launch 模式不稳定，可改用 attach 方式：
- 先运行程序（不调试），子进程启动后打印出其 PID 和监听端口
- 在 VS Code 中新增一个 attach 配置，指定对应 PID 或端口
- 手动点击「Attach to Process」选择子进程，或用配置自动连接
这种方式更灵活，适合调试特定子进程，但自动化程度低。
基本上就这些。核心是理解：VS Code 不自动穿透 multiprocessing，得靠 debugpy 主动“暴露自己”并等待连接。配好 "subProcess": true + 子进程里加两行 debugpy 代码，90% 的多进程调试需求就能覆盖。
