Dev Containers 的核心是标准化而非单纯镜像化，通过 devcontainer.json 和 Dockerfile 实现可执行、可版本控制的环境定义；image 与 dockerFile 互斥，前者适合快速共享基础镜像，后者适用于需细粒度定制与稳定复现的场景。
Dev Containers 不是“把环境打包成镜像”就完事了，而是通过 devcontainer.json 和可选的 Dockerfile 把环境定义为可执行、可版本控制、可协作复用的配置代码。镜像化只是手段，标准化才是目标——它体现在每次 Reopen in Container 都能拉起完全一致的 remoteUser、PATH、extensions 和 postCreateCommand 执行结果。
devcontainer.json 中 image 与 dockerFile 字段怎么选？
二者互斥，不能同时指定。选错会导致构建失败或行为不可控。
-
image：直接引用已构建好的镜像（如mcr.microsoft.com/devcontainers/python:3.11），适合快速启动、团队共享基础镜像；但无法在项目内做细粒度定制，比如加一个私有 pip 源或特定编译工具 -
dockerFile：指向项目内的Dockerfile，所有构建逻辑受控于版本库；推荐用于需要稳定复现的场景，比如必须固定gcc版本或预装内部 CLI 工具 - 常见错误：误写
"image": "ubuntu:22.04"+"dockerFile": "Dockerfile"→ VSCode 报错Cannot specify both 'image' and 'dockerFile' - 性能影响：使用
dockerFile时，首次打开会触发docker build，耗时取决于镜像层缓存；后续修改只 rebuild 变更层，速度尚可
forwardPorts 和 runArgs 的端口转发逻辑差异
两者都涉及端口，但作用阶段和生效方式完全不同，混用容易导致服务访问失败。
-
forwardPorts：VSCode 运行时自动做的端口映射，仅对本地浏览器/调试器可见；它不修改容器网络配置，也不影响容器内进程绑定行为；适用于前端 dev server、本地调试接口 -
runArgs：直接传给docker run的参数，例如"-p", "5432:5432"；它让容器真正监听宿主机端口，适合需被其他容器或外部服务访问的组件（如 PostgreSQL） - 容易踩的坑：
forwardPorts: [3000]却没在容器内启动服务，或服务绑定了127.0.0.1:3000而非0.0.0.0:3000→ 端口转发成功但访问 404 或 Connection Refused - 兼容性注意：Windows/macOS 上
forwardPorts自动启用；Linux 需确认 Remote-Containers 扩展已启用，并且 Docker daemon 正常运行
postCreateCommand 和 postAttachCommand 执行时机与权限陷阱
这两个钩子常被误用，尤其在涉及文件权限、用户切换或依赖安装时，行为差异直接影响环境可用性。
-
postCreateCommand：容器构建完成、文件系统挂载后、但 VSCode 尚未连接前执行；此时以root用户运行（除非显式设remoteUser），适合chmod、apt install、pip install -e . -
postAttachCommand：VSCode 成功连接到容器后才执行；以remoteUser身份运行，适合npm start、python manage.py migrate这类需用户权限的操作 - 典型错误：把
pip install -r requirements.txt放在postAttachCommand，但requirements.txt在/workspace下，而remoteUser对该目录无写权限 → 安装失败且不报错（因命令返回 0 但实际没装上） - 建议写法：
"postCreateCommand": "pip install --no-cache-dir -r requirements.txt || true"，加|| true避免因缺失requirements.txt导致整个初始化中断
真正难的不是写对配置，而是让 devcontainer.json 在不同操作系统、不同 Docker 版本、不同项目结构下都保持行为一致。比如 mounts 挂载 /var/run/docker.sock 在 macOS 上路径不同，remoteUser 在 Alpine 镜像里默认不存在——这些细节不会报错，但会让环境在某台机器上静默失效。
