VSCode 通过 Remote-Containers 扩展将完整开发环境（含 Server、语言服务器、调试器）运行于 Docker 容器内，本地仅保留 UI；需安装该扩展而非 Docker 扩展，配置 .devcontainer/devcontainer.json，使用 Reopen in Container 启动。
VSCode 本身不运行在容器里，但能通过 Remote - Containers 扩展直接连接并编辑运行中的 Docker 容器——这不是“连上容器敲命令”，而是把整个开发环境（包括 VSCode Server、语言服务器、调试器）都放进容器里，本地只留 UI。
装对扩展：必须用 Remote - Containers，不是 Docker
VSCode 插件市场里有两个名字接近的扩展：Docker（用于构建/推送镜像、管理容器）和 Remote - Containers（用于开发集成）。后者才是关键，它会自动在容器内启动 VSCode Server，并把本地编辑器重定向过去。
-
Remote - Containers依赖 Docker CLI 和 Docker Engine（WSL2 或原生），不支持 Podman 或 rootless Docker - 如果已安装
Docker扩展，它只是辅助，不能替代Remote - Containers - Windows 用户需确认 Docker Desktop 设置中启用了 “Use the WSL 2 based engine”
项目根目录下要有 .devcontainer/devcontainer.json
VSCode 不会自动猜你要怎么配容器。必须手动创建 .devcontainer/devcontainer.json，告诉它拉哪个镜像、挂哪些卷、开什么端口、装什么插件。
- 最简配置只需指定
image字段，例如"image": "mcr.microsoft.com/vscode/devcontainers/python:3.11" - 挂载当前项目到容器内推荐用
"mounts"而非"workspaceMount"，避免 Windows 路径解析失败 - 如果容器要访问宿主机服务（如本地数据库），别只写
host.docker.internal—— macOS 和旧版 WSL2 需显式加"extraHosts": {"host.docker.internal": "host-gateway"} -
postCreateCommand适合装 pip 包或生成配置，但别放阻塞型命令（比如没设超时的npm install），否则容器卡在启动状态
打开方式决定是否真正进容器：用 Reopen in Container，不是 Attach to Running Container
右键 Docker 容器列表选 “Attach to Running Container”，只会打开一个终端；真要获得完整 IDE 功能（智能提示、断点调试、任务运行），必须从本地文件夹出发，用命令面板（Ctrl+Shift+P）执行 Dev Containers: Reopen in Container。
- 首次运行会构建镜像（如有
Dockerfile）、启动容器、安装扩展、执行初始化脚本——全程在后台，状态栏显示 “Opening Remote…” - 如果卡住超过 2 分钟，大概率是网络问题（比如国内拉不到 mcr.microsoft.com 镜像），可提前用
docker pull下好基础镜像 - 改了
devcontainer.json后，必须重启容器（Dev Containers: Rebuild and Reopen in Container），热更新不生效
最难调的往往不是配置语法，而是路径权限和用户 UID —— 比如容器内用 node 用户启动，但挂载的 node_modules 是宿主机 root 写的，就会报 EACCES。这类问题不会报错在 VSCode 界面里，得看 Dev Container 的日志输出（命令面板搜 Remote-Containers: Show Log）。
