结论是：绝大多数团队应禁用 build 字段，强制使用带语义化标签的预构建镜像（如 ghcr.io/your-org/base-dev:2024-q3），仅保留 "image" 字段；避免硬编码 Dockerfile 或依赖本地构建，以防环境漂移。
直接说结论：用 devcontainer.json + 预构建镜像 + postCreateCommand 是目前最可控、最易落地的团队沙盒方案，硬编码 Dockerfile 或依赖本地构建反而会放大环境漂移风险。
devcontainer.json 中该用 image 还是 build？
绝大多数团队应该禁用 build 字段，强制使用预构建镜像。官方镜像如 mcr.microsoft.com/vscode/devcontainers/javascript-node:18-bullseye 虽方便，但存在两个隐患：一是标签 :18-bullseye 实际指向不定（可能随上游更新悄悄变更），二是不同项目依赖的 Node 版本、Python 工具链、CLI 工具版本不一致时，无法复用。
实操建议：
- 统一基础镜像必须带语义化标签，例如
ghcr.io/your-org/base-dev:2024-q3，且只读权限托管在私有 registry -
devcontainer.json中只保留"image": "ghcr.io/your-org/base-dev:2024-q3"，彻底删掉build字段 - 若确需定制（如加私有 npm registry 配置），应通过
features引入，而非改写Dockerfile
端口冲突怎么破？forwardPorts 不够用
forwardPorts 只负责自动打开浏览器和转发，但不解决多个开发者同时启动服务时的主机端口占用问题。比如两人本地都跑 localhost:3000，第二个会失败，错误信息通常是 listen EADDRINUSE: address already in use :::3000。
正确做法是让容器内服务监听 0.0.0.0:3000，再由 VSCode 动态分配主机端口：
- 在
devcontainer.json中写"forwardPorts": [3000]即可，不要填hostPort - 确保应用代码里绑定的是
0.0.0.0（不是127.0.0.1），否则 VSCode 无法代理 - VSCode 启动后会在右下角显示实际映射的主机端口，例如
3000 → 44921
环境就绪校验为什么总被跳过？
postAttachCommand 在容器已运行、VSCode 已连接后才执行，此时很多工具可能还没装完；而 postCreateCommand 才是在容器刚创建完、挂载前执行，适合做环境完整性检查——但很多人误配成 postStartCommand（根本不存在）或漏写 /bin/bash -c 导致脚本不执行。
关键点：
- 检查脚本必须放在
.devcontainer/下，且路径写全，例如"postCreateCommand": "/bin/bash -c '. /workspace/.devcontainer/check-env.sh'" -
check-env.sh开头加#!/bin/bash，并设为可执行：chmod +x .devcontainer/check-env.sh - 校验失败必须
exit 1，否则 VSCode 认为成功，继续进入环境
多人协作时 extensions 总不一样？
靠个人手动装插件行不通。customizations.vscode.extensions 列表只是“推荐”，不是强制安装。真正生效要靠 extensions 字段配合 remote.extensionKind 设置，且必须指定 marketplace ID（不是 display name）。
例如 Go 插件正确写法是：
"customizations": {
"vscode": {
"extensions": [
"golang.go"
]
}
}
注意：golang.go 是 ID，不是 “Go for Visual Studio Code”。ID 错一个字符，VSCode 就不会自动装。
复杂点在于，有些插件（比如 Prettier）需要配合特定语言服务器或格式化命令路径，这些路径在容器内外不一致，容易导致“插件装了但不生效”。这类问题通常得靠 settings 里显式指定二进制路径，例如 "prettier.prettierPath": "/usr/local/bin/prettier"。
