Dev Containers 是将开发环境封装进容器的隔离沙盒，依赖 devcontainer.json 配置，需指定 image 或 build，通过 features 快速扩展工具，插件须在 customizations.vscode.extensions 中声明，服务须监听 0.0.0.0 以支持端口转发，权限、用户和启动命令均需适配容器内开发场景。
VS Code 的 Dev Containers 不是“远程开发”的替代品，而是把开发环境封装进容器里，在本地或远程机器上启动一个隔离、可复用的开发沙盒。它不依赖 SSH 连接，也不需要手动配置 Docker 网络或端口映射——只要宿主机装了 Docker（或 Remote - Containers 扩展支持的容器运行时），就能一键拉起完整环境。
devcontainer.json 是核心配置文件，不是可选的
VS Code 通过 .devcontainer/devcontainer.json（或项目根目录下的 .devcontainer.json）识别 Dev Container 配置。没有这个文件，Remote-Containers: Reopen in Container 命令不会出现。
-
image或build必须指定其一：直接复用公开镜像（如mcr.microsoft.com/vscode/devcontainers/python:3.11），或通过build.dockerfile指向自定义Dockerfile -
features是轻量扩展方式，比如加git、github-cli、node，比写完整 Dockerfile 更快，且自动处理权限和 PATH -
customizations.vscode.extensions装的是容器内生效的插件，不是你本地 VS Code 装的那些；比如ms-python.python要列在这里，否则 Python 支持在容器里不可用 - 挂载宿主机代码时，默认是
workspaceFolder→/workspaces/<folder-name>，不要手动改mounts去覆盖它，否则可能丢掉自动同步逻辑
容器内调试失败？检查端口转发和进程监听地址
常见现象：Debug: Python 启动后没反应、浏览器打不开服务、curl localhost:8000 在容器内通但宿主机不通——本质是服务绑定到了 127.0.0.1（只限容器内访问），而 VS Code 的端口转发默认信任 localhost 绑定。
- Web 服务务必监听
0.0.0.0:8000，不是127.0.0.1:8000 - VS Code 自动转发容器暴露的端口（
ports数组声明的），但仅限localhost访问；如需局域网访问，要加"host": "0.0.0.0"到对应 port 条目 - 某些框架（如 Flask 默认）会禁用重载或调试模式，需在
devcontainer.json的runArgs加--security-opt seccomp=unconfined（仅限 Linux 宿主机测试用）
非 root 用户权限问题最常导致命令失败
官方 Dev Container 镜像默认用非 root 用户（如 vscode），但很多脚本、pip install --user、npm install -g 会因 HOME 目录不可写或 PATH 不包含 ~/.local/bin 报错。
- 在
Dockerfile或features安装工具后，用chown -R vscode:vscode /home/vscode确保用户主目录可写 - 在
devcontainer.json中加"remoteUser": "vscode"显式指定用户，避免 fallback 到 root - 如果必须用 root（如要改系统级配置），设
"remoteUser": "root"，但要清楚这会绕过安全限制，且部分 VS Code 功能（如 Settings Sync）可能异常 -
postCreateCommand和postStartCommand默认以remoteUser身份执行，别假设它们能直接apt-get install
Dev Containers 的关键复杂点不在配置语法，而在理解「容器是开发机」而非「部署目标」——所有开发依赖（linter、formatter、debug adapter、甚至 shell history）都要在容器内就绪；一旦忽略用户权限、端口绑定或扩展作用域，就会陷入“看起来启动了，但实际不能用”的状态。
