VSCode attach到多进程容器常连错进程，因默认只连单进程，而容器内多进程（如supervisor、gunicorn worker、Node.js cluster）中仅特定子进程启用调试端口，VSCode无法自动识别目标；须通过processName或PID精准匹配，并确保该进程已实际监听调试端口。
为什么 attach 到多进程容器常连错进程
VSCode 的 attach 模式默认只连一个进程，而 Docker 容器里跑着 supervisor、nginx、Python 主进程 + 多个 worker，或 Node.js cluster 模式时，debugpy / dlv / --inspect 往往只在某个子进程上监听——但 VSCode 不知道该连谁，容易连到父进程（没开调试端口）或静默的 worker（还没初始化调试器）。
根本问题不是“连不上”，而是连上了，但目标进程根本没启动调试协议。比如 Python 用 gunicorn 启动，debugpy 只在主进程 listen，worker fork 后没继承 socket；Node.js cluster 中只有 master 监听 --inspect，worker 默认不开启。
- 确认实际监听调试端口的进程：进容器执行
docker exec -it myapp ss -tlnp \| grep :5678或lsof -i :9229 - 避免用
ps aux \| grep python这类模糊匹配——它可能返回多个进程，但只有一个是真正debugpy.listen()的 - 如果用进程名做筛选（如
name: "worker"），确保该 name 在ps输出中真实存在且唯一；否则 VSCode 会随机选一个
launch.json 里怎么指定具体进程（非端口）
端口 attach 适合单进程，多进程必须靠进程 ID 或名称精准定位。VSCode 支持两种方式：processId（需提前知道 PID）和 processName（依赖容器内 ps 输出格式）。
以 Python 为例，若你用 supervisord 管理，且 worker 进程命令行含 myworker.py，可这样配：
MiniMax 图片理解 + 网络搜索 MCP 工具。适配 Docker 环境（极空间等），支持图片 OCR 识别、图像内容理解、网络搜索。API Key 安全存储在本地 credentials 文件，不暴露在代码中。
{
"type": "python",
"request": "attach",
"name": "Attach to worker",
"processId": 0,
"processName": "myworker.py",
"port": 5678,
"host": "localhost"
}
-
processId设为0表示让 VSCode 自动查匹配processName的第一个进程 -
processName必须是ps命令输出的完整 argv[0] 或其子串，比如python3 -m debugpy ... myworker.py中，myworker.py才是可靠匹配项 - Node.js 不支持
processName，只能用port+address，所以必须确保 cluster 中某个 worker 显式启用--inspect-port=9230并绑定0.0.0.0
Docker 启动参数对多进程调试的影响
很多失败不是 VSCode 配错了，而是容器启动时就封死了调试通路。尤其当使用 supervisord、systemd 或 entrypoint.sh 时，几个参数直接决定能否 attach 成功：
-
-p 5678:5678必须显式指定，不能只写-P—— 随机端口会让 VSCode 无法预知目标 -
--init推荐加上：避免僵尸进程干扰ps查询，也防止 supervisor 子进程被 init 收养后丢失调试信号 - 禁用
docker run --restart=always：调试时进程崩溃应立刻退出，方便你重试；设成 always 会导致 VSCode 连上旧 PID 后又瞬间被新进程覆盖 - 如果用
docker-compose.yml，确保stdin_open: true和tty: true开启——某些调试器（如旧版 ptvsd）依赖 TTY 初始化
Python 多 worker 场景下 debugpy 的正确启动姿势
别指望 debugpy 自动注入所有子进程。它默认只在当前 Python 解释器生效，fork 后的 worker 不会自动继承监听 socket。
可行方案只有两个，选其一：
- 让每个 worker 显式启动
debugpy：在 worker 启动逻辑开头加import debugpy; debugpy.listen(5678); debugpy.wait_for_client()，并确保每个 worker 绑定不同端口（如5678 + os.getpid() % 100），再配多个 VSCode attach 配置 - 放弃 worker 级调试，只 attach 主进程：用
gunicorn --preload或uvicorn --workers=1强制单进程，调试通过后再切回多 worker
最常被忽略的一点：debugpy 的 wait_for_client() 是阻塞调用，如果主进程卡在这儿，整个服务就起不来——务必确认你 attach 的时机早于它超时退出，或改用非阻塞的 debugpy.breakpoint() 手动触发断点。
