remote-containers扩展是vscode容器化开发的必需组件，它在容器内启动vscode server，实现编辑、终端、调试全链路运行于容器环境；docker插件仅管理镜像与容器，无法替代其功能。
VSCode 本身不运行 Docker 容器里的代码，真正执行的是容器内部的环境；要让编辑、终端、调试全部落在容器里，必须用 ms-vscode-remote.remote-containers 扩展——不是 Docker 插件，也不是手动 docker exec。
Remote-Containers 扩展为什么非装不可
很多人装了 ms-azuretools.vscode-docker 就以为能进容器开发，结果点“Exec in Container”失败、断点不命中、pip install 报错，甚至终端连 /bin/bash 都找不到。这是因为 Docker 插件只管镜像列表、启停容器、看日志，它不启动 VSCode Server，也不挂载工作区、不同步插件、不处理路径映射。
ms-vscode-remote.remote-containers 才是关键：它会在容器里拉起一个轻量 VSCode Server，所有终端命令、Python 解释器、调试器、扩展都来自容器内部，和宿主机完全解耦。
- Linux 用户没加
docker组会静默失败，必须执行sudo usermod -aG docker $USER并完全退出图形会话重登 - Windows/macOS 要确认 Docker Desktop 正在运行，且 Windows 启用了 WSL2 后端，macOS 开启了 “Use Docker CLI from the terminal”
- 在 VSCode 内置终端里运行
docker --version和docker ps必须成功，否则 Remote-Containers 会直接报错Failed to connect to Docker daemon
devcontainer.json 放错位置或字段写错，容器就起不来
VSCode 只认项目根目录下 .devcontainer/devcontainer.json 这个路径和文件名，少一个点、多一个空格、放错层级（比如直接放在项目根而非 .devcontainer/ 子目录），都会导致“Reopen in Container”按钮灰掉或无响应。
新手建议从微软官方镜像起步，别碰 python:3.11-slim 或 node:20-alpine 这类生产镜像——它们缺 git、curl、make，连 pip install 都可能失败。
- 推荐配置：
"image": "mcr.microsoft.com/vscode/devcontainers/python:3.11"，自带基础工具链和vscode-server -
"customizations.vscode.extensions"必须显式列出所需插件，例如["ms-python.python", "esbenp.prettier-vscode"]，容器不会继承你本地装的任何扩展 - 如果要用自定义
Dockerfile，务必基于mcr.microsoft.com/devcontainers/base:ubuntu或显式安装vscode-server，否则容器起来只有黑屏终端
代码在宿主机，但 Python 解释器、断点、端口全在容器里
你编辑的文件物理存在本地磁盘，但 python app.py 是在容器里跑的，默认挂载路径是 /workspaces/your-project。这就带来三个高频问题：
- 调试断点不命中：
launch.json里没配sourceFileMap，调试器找不到宿主机路径对应关系，得加"sourceFileMap": { "/workspaces/your-project": "${workspaceFolder}" } - Python 解释器报错或 pip 权限拒绝：检查
python.defaultInterpreterPath是否指向容器内真实路径，例如/usr/local/bin/python，而不是宿主机路径 - 浏览器打不开
localhost:5000：forwardPorts没写，Flask/FastAPI 服务默认只监听127.0.0.1:5000，必须在devcontainer.json里明确写"forwardPorts": [5000]，VSCode 才会自动做端口映射
虚拟环境别建在宿主机，也别用相对路径硬编码
在容器终端里执行 python -m venv /workspaces/your-project/.venv 是安全的；但如果你在宿主机上用 venv 或 poetry 创建了虚拟环境，再挂进容器，大概率因路径、权限、Python 版本不一致而失效。
同样，requirements.txt 安装后，依赖应固化在镜像层（通过 postCreateCommand）或构建阶段（Dockerfile 中 RUN pip install -r requirements.txt），而不是每次打开容器都重装——否则网络波动或源站变更就会卡住整个开发流。
最易被忽略的一点：容器内服务绑定地址不能写 127.0.0.1，得用 0.0.0.0，否则即使端口转发开了，请求也进不到进程里。
