VS Code 通过 Remote - Containers 扩展将编辑体验投射进运行中的 Docker 容器，需安装扩展、验证 Docker 环境、配置 .devcontainer/devcontainer.json，并注意端口转发、路径映射与环境边界。
VS Code 本身不能直接运行在 Docker 容器里，但你可以用 Remote - Containers 扩展把 VS Code 的编辑体验“投射”进正在运行的容器中——这才是官方推荐、稳定可用的方式。
安装 Remote - Containers 扩展并验证 Docker 环境
这是前提，缺一不可。VS Code 需要能调用本地 docker 命令，并有权限访问 Docker daemon。
- 在 VS Code 扩展市场搜索并安装
Remote - Containers（作者 Microsoft） - 终端执行
docker --version和docker info，确认命令可用且无 permission denied 错误 - Linux 用户常见坑：
docker命令需加入当前用户组（sudo usermod -aG docker $USER），改完要登出重进 - Windows/macOS 用户若用 Docker Desktop，确保它已启动且后台服务正常
用 devcontainer.json 定义开发环境
不是随便写个 Dockerfile 就行——devcontainer.json 才是 VS Code 识别容器开发模式的关键配置文件，必须放在项目根目录的 .devcontainer/ 文件夹下。
-
devcontainer.json中的image或build字段决定基础镜像来源；推荐优先用build+Dockerfile，便于复现和调试 - 务必设置
forwardPorts（如[3000, 8080]），否则容器内起的服务在宿主机浏览器打不开 - 需要持久化数据？用
mounts字段挂载宿主机路径，例如"source": "${localWorkspaceFolder}/data", "target": "/app/data" - 不要在
devcontainer.json里写command启动长期进程（比如npm start），这会阻塞容器启动；改用postCreateCommand或任务配置
打开文件夹时自动进入容器或手动重开
VS Code 不会“自动连接”到任意运行中的容器，它只响应你对某个本地文件夹的操作。
- 首次打开含
.devcontainer/的文件夹，右下角会弹提示：“Reopen in Container”，点它 - 如果已打开普通文件夹，按
Ctrl+Shift+P（macOSCmd+Shift+P），输入Remote-Containers: Reopen in Container - 连接失败时看 VS Code 右下角状态栏：显示
Dev Container且带容器名才算成功；若显示SSH或空白，说明没进去 - 容器启动后，VS Code 的终端、调试器、扩展（如 Python、ESLint）都运行在容器内环境，
which python返回的是容器里的路径
调试、端口与文件同步的典型问题
很多问题不是配置错，而是对“容器内外”边界理解模糊导致的。
- 断点不命中？检查调试器是否装在容器内（不是宿主机），且源码路径映射正确；Node.js 项目注意
outFiles路径是容器内的 - 浏览器访问
localhost:3000404？确认devcontainer.json里forwardPorts已设，且应用监听的是0.0.0.0:3000而非127.0.0.1:3000 - 保存文件后容器内程序没热更新？默认文件同步是单向（宿主机→容器），但大多数语言服务器和 watch 工具能感知变化；若不行，可加
"runArgs": ["--volume", "${localWorkspaceFolder}:/workspace:delegated"]提升性能 - Git 操作异常？容器内没配 Git 用户信息，进容器终端执行
git config --global user.name "xxx"和git config --global user.email "xxx"
真正麻烦的从来不是“怎么连上”，而是连上之后，搞不清当前命令是在容器里执行还是宿主机上执行，以及哪些路径该用容器视角、哪些该用本地视角。多看一眼终端左下角的环境标识，比反复重试更省时间。
