vscode 本身不直接运行 docker 容器，而是通过扩展和命令行协同实现高效开发；需安装 Docker 扩展、配置 Dev Container、善用内置终端并理解 Docker 核心机制。
VSCode 本身不直接运行 Docker 容器，它靠扩展和命令行工具协同工作——关键不是“VSCode 运行容器”，而是你能否在 VSCode 环境里高效调用 docker 命令、查看日志、调试服务，并避免手动切终端。
装对扩展：Docker 扩展不是万能的，但没它会更麻烦
VSCode 官方 Docker 扩展（microsoft 发布）是基础依赖，它提供镜像/容器列表、右键操作、docker-compose.yml 语法支持和一键构建。但它不替代 CLI，也不自动启动守护进程。
- 必须确保本地已安装 Docker Desktop（macOS/windows）或
dockerCLI +dockerd（linux），且docker version在终端中可执行 - 扩展不管理 Docker 权限：Linux 用户常因没加
sudo或未加入docker用户组而看到 “Cannot connect to the Docker daemon” 错误 - 扩展的“Run”按钮本质是执行
docker run，参数来自.devcontainer.json或右键菜单预设，无法替代自定义-v、--network等复杂挂载
用好 Dev Container：这才是 VSCode 深度集成 Docker 的核心场景
当你想“在容器里开发”，而不是“在本地跑个容器”，Dev Container 是唯一值得投入的方式。它把整个开发环境（编辑器后端、依赖、端口映射）声明化，重启即还原。
- 初始化方式：打开文件夹 → 按
Ctrl+Shift+P→ 输入 “Dev Containers: Add Development Container Configuration Files…” → 选基础镜像（如node:18）或已有Dockerfile -
.devcontainer/devcontainer.json中的forwardPorts字段决定哪些端口自动在 VSCode ui 显示并可点击打开，比如[3000, 5432]；漏写就看不到链接 - 修改配置后必须重新执行 “Dev Containers: Rebuild and Reopen in Container”，仅重启容器不行——因为 VSCode 的 server 进程也运行在容器内
别绕开终端：VSCode 内置终端才是日常操作 Docker 的主力
扩展 UI 只覆盖简单操作；真正管理镜像生命周期（清理 dangling 镜像、查 layer 大小、导出镜像）、排错网络或 exec 进容器，还是得敲命令。VSCode 终端和系统终端行为一致，只是 cwd 和环境变量可能不同。
- 常用但易错的命令：
- VSCode 终端默认复用 shell 配置（如
~/.zshrc），但某些插件或远程连接场景下 PATH 可能不含/usr/local/bin/docker，此时需在settings.json中设置"terminal.integrated.env.linux": { "PATH": "/usr/local/bin:/usr/bin:${env:PATH}" }
镜像构建失败？重点检查 .dockerignore 和上下文路径
VSCode 扩展点击 “Build Image” 或执行 docker build 报错，80% 出在构建上下文（context）——不是 Dockerfile 写错，而是它带进了不该带的文件，或根本找不到依赖。
-
.dockerignore必须存在且生效：它不支持!否定语法，也不能用绝对路径；常见错误是忘了忽略node_modules或.git，导致构建超慢或失败 - VSCode 当前打开的文件夹 = 构建上下文根目录；如果
Dockerfile在子目录（如./backend/Dockerfile），必须在终端里进到backend再执行docker build -f Dockerfile .，不能只靠扩展右键“Build Image” - 多阶段构建中，
copy --from=builder的 stage 名称大小写敏感，写成BUILDER就报 “stage not found”
真正的难点不在“怎么点”，而在理解 Docker 的分层缓存机制、网络模型和权限边界——VSCode 只是让你更快地暴露这些问题，而不是帮你绕过它们。