remote-containers是唯一能将vscode完整开发环境（编辑、调试、终端）运行在容器内的方案；docker插件仅管理镜像/容器，代码仍在本地，无法实现容器内依赖安装、热更新和进程调试。
Remote - Containers 是唯一能真正把 VS Code “运行在容器里”的方案，其他方式只是连进去看日志或查文件——它才是开发态。
为什么不能只靠 Docker 插件启动容器？
VS Code 自带的 Docker 插件（Microsoft 官方扩展）本质是个管理器：能拉镜像、启停容器、看日志，但代码仍在本地编辑，容器只是个“远程服务器”。真正在容器里装依赖、跑 npm install、调试 node 进程，必须用 Remote - Containers。
常见错误现象：
- 修改代码后热更新不生效 → 因为文件没同步进容器，或监听路径不对
- import 报错找不到模块 → 本地 node_modules 被挂载进去了，但容器里没装过依赖
- 断点不命中 → 调试器连的是本地进程，不是容器内进程
如何用 devcontainer.json 启动一个可开发的容器？
核心是项目根目录下建 .devcontainer/devcontainer.json，而不是靠命令行 docker run 手动启。VS Code 读这个文件决定怎么构建、挂载、初始化。
-
image或build二选一：直接复用镜像（如mcr.microsoft.com/vscode/devcontainers/python:3.11），或用Dockerfile自定义（推荐） -
mounts不要写错路径：Windows 用户注意source必须是绝对路径，且驱动器需在 Docker Desktop 设置中勾选共享（如C:\myproject→/workspace） -
postCreateCommand是关键：在这里执行pip install -r requirements.txt或npm ci，确保容器启动时依赖就绪 -
forwardPorts列出需要暴露的端口（如[3000, 5432]），VS Code 会自动做端口转发，不用手动-p
挂载 volume 时容易踩的坑
本地代码和容器内工作目录的映射，不是“复制”，而是实时双向挂载。但默认行为可能破坏容器内原有结构。
- 别用
copy . /workspace在Dockerfile里复制代码 ——devcontainer.json的mounts已经做了，重复操作会导致权限冲突或覆盖 - Node.js 项目慎挂载
node_modules：本地生成的node_modules无法在 Linux 容器里直接运行（二进制不兼容），应让容器自己装 - PostgreSQL 数据目录不要挂到宿主机临时路径（如
/tmp/pgdata）：重启后可能丢失，要用明确路径 +chown -R 999:999 /var/lib/postgresql/data
调试 Python/Node.js 时必须确认的三件事
断点能停住，不等于环境对了。容器里缺东西，调试器照样静默失败。
- 确认容器里装了对应语言的调试支持：Python 需
debugpy，Node.js 需vscode-js-debug（通常Remote - Containers会自动注入，但自定义镜像要手动加） -
launch.json的type和request必须匹配：Node.js 用pwa-node，Python 用python；port要和容器内服务监听端口一致（不是宿主机转发后的端口） - 检查
remoteEnv：某些依赖（如数据库连接串）需在容器环境变量里设置，不能只靠本地.env
复杂点在于：devcontainer.json 的配置项和实际运行时的容器状态不是一一对应的，比如 postAttachCommand 在每次重连时都执行，而 postCreateCommand 只在首次构建时跑——搞混这两者，会导致依赖反复重装或环境变量漏设。
