Dev Container模式下Node调试连通的关键是：Node进程必须监听0.0.0.0:9229（而非127.0.0.1），devcontainer.json中配置"forwardPorts": [9229]，且sourceFileMap需精准映射容器内路径（如/app）到本地工作区，差一个字符断点即失效。
直接用 Remote-Containers 扩展启动 Dev Container 是最稳的方式，能绕过 90% 的路径错位、端口不通、断点不命中问题；手动 attach 到已有容器容易卡在 --inspect 绑定地址或 sourceFileMap 配置上。
Dev Container 模式下怎么让 Node 调试器真正连上？
关键不是“能不能连”，而是容器里 Node 进程是否对外暴露调试端口，且 VSCode 知道代码在哪。
-
CMD ["npm", "run", "debug"]必须搭配"debug": "node --inspect=0.0.0.0:9229 server.js"—— 漏掉=0.0.0.0就只监听127.0.0.1，容器内其他进程都连不上，VSCode 更不可能 attach -
devcontainer.json中的"forwardPorts": [9229]是必须项，它让 VSCode 自动把宿主机随机端口转发到容器9229，不用手写-p 9229:9229 - 别依赖自动推断
remoteRoot：Dev Container 默认挂载路径是/workspace，但如果你在Dockerfile里写了WORKDIR /app，就得在devcontainer.json里显式加"workspaceFolder": "/app"
为什么断点永远不命中？
不是代码没跑，是 VSCode 调试器看到的文件路径和 Node 进程加载的真实路径对不上。
- 容器里报错显示
/app/server.js:42，你就得在launch.json或devcontainer.json里写清楚："sourceFileMap": { "/app": "${workspaceFolder}" } - 如果项目用了 TypeScript 或构建工具（如 Vite、Webpack），源码路径更复杂，
sourceFileMap得映射到dist或.vscode/.tmp下的真实输出路径，而不是原始src/ - 用
console.log(__filename)在服务启动时打印真实路径，比猜配置靠谱得多
attach 到已有 docker-compose 容器时最容易错哪？
不是配置 launch.json，而是容器根本没按调试模式启动。
- 检查容器内是否真监听了
0.0.0.0:9229：进容器执行lsof -i :9229，输出必须含*:9229，若只有127.0.0.1:9229就失败 -
docker-compose.yml里得有ports: - "9229:9229"，且服务启动命令明确带--inspect=0.0.0.0:9229，光写--inspect默认绑127.0.0.1 -
launch.json的"address": "localhost"指的是宿主机，"port": 9229必须和docker-compose.yml里- "9229:9229"左边那个端口一致
最常被忽略的其实是 WORKDIR 和 workspaceFolder 的一致性——差一个斜杠、多一层目录，断点就静默失效，而错误提示里根本不会提这事。
