VS Code调试Python多进程需手动启用子进程调试：在launch.json中设置"subProcess": true，并在子进程代码开头调用debugpy.listen()和debugpy.wait_for_client()。
VS Code 调试 Python 多进程应用默认不支持子进程断点，因为 Python 的 multiprocessing 模块会启动全新解释器进程，而 VS Code 的调试器只附加到主进程。要让子进程也能被调试，关键在于让每个子进程都主动连接到 VS Code 的调试服务（ptvsd 或 debugpy）。
新版 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 debugpyif 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" 动态指定（需脚本生成配置）；更简单做法是只调试单个子进程，其余跳过调试逻辑。
大家都知道，在进行J2EE项目的开发过程中，在调试阶段如果只是修改了页面是不需要重启应用服务器的，比如不需要重启Tomcat。只需要在浏览器中 进行页面刷新即可。其实之所以不用重启Tomcat等应用服务器，其根本原因是因为我们可以在应用服务器的配置文件中设置虚拟目录，这样就可以知道web 项目所在的目录，于是就可以省去打包、然后再重新发布到服务器的步骤。感兴趣的朋友可以过来看看
0
• Windows + spawn 方法：Windows 默认用 spawn，必须保证子进程入口是 if __name__ == "__main__": 保护块，否则会无限递归创建进程。
• fork 方法不生效：Linux/macOS 默认 fork，子进程继承主进程的调试状态，但 VS Code 无法自动接管 fork 出的子进程。此时仍需手动调用 debugpy.listen()。
• 终端输出干扰：启用 "console": "integratedTerminal" 可看到子进程打印的 Waiting for debugger attach...，方便确认是否进入调试等待。
如果 launch 模式不稳定，可改用 attach 方式：
这种方式更灵活，适合调试特定子进程，但自动化程度低。
基本上就这些。核心是理解：VS Code 不自动穿透 multiprocessing，得靠 debugpy 主动“暴露自己”并等待连接。配好 "subProcess": true + 子进程里加两行 debugpy 代码，90% 的多进程调试需求就能覆盖。
以上就是在VS Code中调试Python的多进程应用的详细内容，更多请关注php中文网其它相关文章！
每个人都需要一台速度更快、更稳定的 PC。随着时间的推移，垃圾文件、旧注册表数据和不必要的后台进程会占用资源并降低性能。幸运的是，许多工具可以让 Windows 保持平稳运行。
广告Copyright 2014-2025 https://www.php.cn/ All Rights Reserved | php.cn | 湘ICP备2023035733号
744
收藏
