dev containers需满足路径、字段、用户、挂载四要素才生效：.devcontainer/devcontainer.json路径须严格匹配；image与build字段不可共存；wsl2用户须从终端执行code .；shell启动需在postcreatecommand显式source；挂载推荐显式配置workspacemount；用户权限须确保home可写。
Dev Containers 不是点一下“Reopen in Container”就自动好用的功能，它依赖几个硬性条件才能真正接管你的开发环境——路径对、字段对、用户对、挂载对，错一个，容器就只开个终端而已。
devcontainer.json 文件位置和字段必须严格匹配
VSCode 只认 .devcontainer/devcontainer.json 这个路径：开头带点、是目录不是文件、在你打开的 VSCode 工作区根目录下。写成 devcontainer.json（没点）、.devcontainer.json（是文件不是目录）、或者放在 .vscode/ 里，VSCode 都不会识别。
-
image和build字段不能共存，同时出现会报错Invalid devcontainer.json: 'image' and 'build' cannot both be specified - 空文件或只有注释的
devcontainer.json不会触发容器启动逻辑 - Windows 用户若用 WSL2，必须从 WSL2 终端里执行
code .打开项目；用 Windows 版 VSCode 直接双击打开，插件默认不生效
image 和 build 怎么选才不翻车
选错会导致环境缺失依赖或构建失败。判断依据很简单：要不要定制构建过程？
- 纯用公开镜像（如
mcr.microsoft.com/vscode/devcontainers/python:3.11），就只配"image" - 需要装私有 CLI、预置 SSH key、改系统 locale，就必须删掉
"image"，只留"build"，并在Dockerfile里FROM那个基础镜像 -
"build": { "context": ".." }这种跨目录引用要小心：VSCode 构建时工作目录是.devcontainer/，不是项目根目录，相对路径容易错位
容器里找不到 node、conda、git？不是没装，是没加载
Dev Containers 默认以 login shell 启动（例如 /bin/bash --login），但很多工具（conda、nvm、sdkman）的初始化脚本只在交互式 shell 或手动 source 时才加载。
- 在
devcontainer.json中加"postCreateCommand"显式source，例如："postCreateCommand": "source /opt/conda/etc/profile.d/conda.sh && conda activate base" - Git 不可用？大概率是容器内没设
user.name和user.email，加进postCreateCommand或用features自动配置 - 避免在
build里写COPY . /workspace—— Dev Containers 默认会把工作区挂载到/workspace，重复拷贝反而覆盖本地修改
挂载代码和权限问题最容易被忽略
VSCode 默认把工作区挂到 /workspace，但这个行为在符号链接、网络盘、跨 WSL/Windows 路径混用时极不稳定：你改了文件，git status 看不到；保存后内容消失；甚至 ls 都列不出文件。
- 显式声明
workspaceMount比依赖默认更可靠："workspaceMount": "source=${localWorkspaceFolder},target=/workspace,type=bind,consistency=cached" - 官方镜像默认用
vscode用户，但HOME目录可能不可写，导致pip install --user或npm install -g失败 - 在
Dockerfile里加RUN chown -R vscode:vscode /home/vscode，并在devcontainer.json中写明"remoteUser": "vscode"
最常被跳过的其实是 postCreateCommand 的执行顺序和 workspaceMount 的一致性——前者决定工具链是否真能用，后者决定你写的代码是不是真的在容器里。这两个点不调通，其他再怎么配都是假成功。
