vscode+docker做node开发的正确方式是通过remote-containers扩展启动专属容器，每个项目用独立dockerfile指定node版本、非root用户、workdir及端口转发，实现环境隔离与调试可用。
能直接在容器里写代码、装依赖、跑调试，且每个项目用的 Node 版本互不干扰——这才是 VSCode + Docker 做 Node 开发的正确打开方式。
Remote-Containers 扩展是唯一入口
VSCode 本身不运行在容器里，也不“连接”已存在的容器；它靠 Remote-Containers 扩展，在你指定的镜像或 Dockerfile 基础上启动一个新容器，并把 VSCode Server 注入进去。这个过程自动完成三件事：挂载当前项目目录、复用容器内的 node/npm、加载你配置的扩展（比如 ESLint）。
常见错误现象：
- 点了 “Reopen in Container” 没反应 → 检查
docker --version和docker info是否正常，Linux 用户常因没加docker用户组失败 - 右下角显示 “SSH” 或空白 → 没成功进入 Dev Container，而是连了别的远程环境
- 终端里
which node还是宿主机路径 → 容器根本没起来，或者devcontainer.json的workspaceFolder路径写错了
devcontainer.json 必须配对 Dockerfile 使用
只写个 image: "node:18-slim" 看似简单，但实际开发中几乎不可行：缺 Git、没 yarn、权限不对、工作目录混乱……这些问题全靠 Dockerfile 显式控制。
实操建议：
Zenlink - Node SDK for ZenHeart
下载
ZenHeart zenlink 与 zenlink-mcp 为 OpenClaw，涵盖安装、MCP 注册、钩子接线、入站轮询及升级维护。
- 用
build字段指向Dockerfile，别依赖现成镜像；devcontainer.json中写"build": { "dockerfile": "Dockerfile" } -
Dockerfile里用USER node（不是 root），否则 VSCode 启动后文件权限会出问题 - 务必加
WORKDIR /workspace，并和devcontainer.json中的"workspaceFolder": "/workspace"对齐 - 需要
nvm？在Dockerfile里装，别指望进容器后再手动装——postCreateCommand只适合轻量初始化
端口转发和调试必须显式声明
容器内 npm start 跑在 3000，不代表你在宿主机 localhost:3000 就能访问。VSCode 不自动暴露端口，得靠 forwardPorts 配置打通。
关键点：
-
"forwardPorts": [3000, 9229]——9229是 Node.js 调试端口，漏掉就断点无效 - 如果用
docker-compose.yml启动多服务，devcontainer.json要写"dockerComposeFile": "docker-compose.yml"和"service": "app"，不能只靠image - Node.js 调试时，
launch.json的outFiles路径必须是容器内路径，例如"/workspace/dist/**/*.js"，不是宿主机的${workspaceFolder}/dist
多个 Node 版本项目共存的关键是隔离而非切换
不要在同一个容器里用 nvm use 16 切版本来适配不同项目——这违背容器化初衷，也容易污染环境。每个项目应有独立的 .devcontainer/ 配置，对应专属镜像或 Dockerfile。
例如：
- 项目 A 的
Dockerfile写FROM node:16-bullseye - 项目 B 的
Dockerfile写FROM node:20-bookworm - 两者都用各自
.devcontainer/devcontainer.json，VSCode 打开哪个文件夹，就进哪个环境 - 容器退出后，所有依赖、全局模块、甚至
nvm安装记录全部销毁，彻底干净
最容易被忽略的是：devcontainer.json 里的 mounts 和 postStartCommand 很少被用，但一旦项目需要本地缓存（如 yarn cache）或数据库初始化，它们就是唯一可控的持久化入口。别等到第一次 npm install 花十分钟才想起来该挂载缓存卷。
