Devcontainer 代理配置

问题：容器里的开发环境也被网络挡住

在团队协作中，开发容器（Devcontainer）已经成为常见的隔离手段：一个项目配好 Dockerfile，新人拉下来就能得到一致的工具链。但当项目依赖外部资源时，网络问题会立刻暴露——npm、pip、Go modules 的拉取可能超时，公司内网的自建服务也无法访问。根本原因是容器没有继承宿主机的代理配置，所有出网请求都要裸奔或者干脆被墙。

手动在每个容器里 export http_proxy=... 是一次性方案：下次重建就失效，团队成员的配置也各写各的，很难审计。真正需要的是把代理写进 Devcontainer 的配置里，让它随环境一起分发。

这个技能做了什么

核心思路是把代理配置做成 Devcontainer 生命周期的一部分，而不是事后补救：

• 统一注入：利用 postCreateCommand 等生命周期钩子，在容器创建完成后自动写入代理环境变量，重建容器也不会丢。
• 复用 devcontainers CLI：通过 devcontainer run-user-commands 这类命令触发钩子执行，不额外引入一套自建脚本体系。
• 覆盖常见场景：开发容器内运行应用、分离代码库所需的工具与运行时环境时，出网策略保持一致。

工作流大致是：先确定镜像与变体参数，再用 docker build 构建容器镜像；镜像启动后由 CLI 拉起生命周期命令，代理配置在这一步落地。整个过程与官方 Devcontainer 规范兼容，不需要替换现有工具链。

适用边界与注意点

• 依赖 Docker 与容器构建能力。没有 Docker 守护进程的本机跑不起来，CI 里也需要可用的 Docker 环境。
• Node.js 环境要求按上游区分：npm 包安装需要本机具备 Python 和 C/C++ 编译链来构建一个原生依赖；如果走上游提供的独立安装脚本，会捆绑下载 Node.js 运行时，则无需预先安装，且仅支持 Linux 和 macOS（x64 与 arm64）。
• 代理只解决容器内出网。宿主机自身的代理、镜像构建阶段的网络请求（如基础镜像拉取）不在这套流程覆盖范围内，需要单独处理。
• 配置要随代码库分发。代理地址如果含内网凭据，不要明文提交；建议引用环境变量或 secret 管理。

总的来说，这套方案的价值在于把「能访问网络」变成开发容器定义的一部分，而不是每个人在 ~/.bashrc 里各写一份。适合网络受限、又强依赖容器化开发的团队。