根本原因是VSCode调试器因容器共享默认网段（如172.17.0.0/16）导致端口转发冲突、remoteRoot映射错乱，甚至attach到错误容器；需为各服务配置独立子网、显式绑定宿主机调试端口、精准设置remoteRoot/localRoot路径并清理旧网桥。

为什么微服务容器里断点总不命中？

根本原因不是代码或 launch.json 写错了，而是 VSCode 调试器压根连不上你实际运行的 Node 进程——因为多个容器共享同一 Docker 默认网段（如 172.17.0.0/16），导致端口转发冲突、remoteRoot 映射错乱、甚至调试器 attach 到了别的容器里。

检查容器网络是否真冲突

先确认是不是网段撞车：在宿主机执行 docker network inspect bridge，看 Subnet 字段；再进每个微服务容器跑 ip addr show eth0，比对 IP 是否都落在同一个 172.17.x.x 段。如果全是，那调试器根本分不清哪个是你的 target 服务。

• 别只看 docker-compose.yml 里有没有自定义 networks —— 即使写了，若没显式指定 subnet，Docker 仍可能复用默认网段
• docker-compose up 启动后，用 docker ps 看各容器 IP，差异小于 /24 就大概率冲突
• VSCode Remote-Containers 日志里出现 Connection refused 或反复重试 localhost:9229 却无响应，基本可锁定网络层

强制隔离容器网络 + 正确映射调试端口

解决核心是让每个服务独占子网，并把调试端口从容器内精确暴露到宿主机唯一端口，避免 VSCode 自动转发时“张冠李戴”。

用于自动切换项目中适合的node 版本

根据 package.json 中的 engines 字段自动检测 Node.js 版本需求，未安装 nvm 时自动安装并切换至对应版本。支持 Windows、macOS、Linux。适用于 Node.js 项目开发、版本切换和环境配置。

下载

• 在 docker-compose.yml 的 networks 下为每个服务定义独立子网：
  

  "networks": {
    "svc-a-net": { "driver": "bridge", "ipam": { "config": [{ "subnet": "172.20.0.0/24" }] } },
    "svc-b-net": { "driver": "bridge", "ipam": { "config": [{ "subnet": "172.21.0.0/24" }] } }
  }

• 每个服务的 ports 必须显式绑定宿主机非默认端口：
  ports: ["3001:3000"]（服务监听 3000）和 ["9230:9229"]（调试端口）——千万别写成 ["9229"] 让 Docker 随机分配
• launch.json 中 address 改为宿主机 IP（不是 localhost），port 对应你刚绑定的宿主机端口：
  "address": "192.168.1.100", "port": 9230（假设宿主机 IP 是这个）

remoteRoot 和 localRoot 必须按容器视角写

很多人照抄文档写 "remoteRoot": "/workspace"，但实际容器里项目路径可能是 /app 或 /src。VSCode 一旦映射错，断点就永远停在 file:/// 空白页上。

• 进目标容器执行 pwd 和 ls -l，确认代码真实挂载路径（比如 /home/node/app）
• remoteRoot 填这个绝对路径，localRoot 填你本地工作区根目录（${workspaceFolder}）
• 如果用了 volume 挂载，确保 devcontainer.json 或 docker-compose.yml 里 mounts 的 source 和 target 与 remoteRoot 一致
• 验证方式：在调试控制台执行 console.log(__filename)，看输出路径是否匹配 remoteRoot + 文件名

真正麻烦的不是配置本身，而是所有容器共享网络时，VSCode 的自动端口转发和路径映射会静默失效——它不会报错，只会让你盯着空心断点发呆。动手前，先 docker network prune 清掉旧网桥，再重跑 compose，比调 launch.json 有效十倍。