构建上下文是docker构建效率、镜像体积与安全性的核心瓶颈；必须通过.dockerignore精简上传文件、按变更频率分层copy依赖与源码，并借助buildkit多上下文机制优化传输。
构建上下文是 Docker 构建过程中最常被低估、也最容易出问题的环节。它不是“可选配置”，而是决定构建速度、镜像体积和安全性的底层约束。优化它，不靠玄学，而靠明确控制哪些文件进、哪些不出、何时用、怎么传。
精简上下文：从 .dockerignore 开始
默认情况下，docker build . 会把当前目录所有内容打包上传给守护进程——包括 node_modules、.git、logs/、dist/ 等完全不需要的文件。这直接拖慢构建、浪费带宽、增大缓存压力。
- 必须创建
.dockerignore文件，按需排除（语法同.gitignore） - 常见应排除项：
**/node_modules、.git、README.md、tests/、*.log、*.tmp - 避免使用
**全局通配，易误删；优先用显式路径或前缀匹配 - 可通过
docker build --no-cache -t test .后检查日志中 “Sending build context” 的大小，验证是否生效
分层设计：让 COPY 指令更聪明
COPY 的位置和粒度直接影响缓存复用效率。Docker 缓存只在指令内容和对应文件未变时才命中——如果把代码全量复制放在依赖安装之前，每次改一行代码都会导致 RUN pip install 层失效。
- 先 COPY 依赖清单（如
requirements.txt、package.json），再 RUN 安装 - 再 COPY 其余源码（
COPY . .或更细粒度路径） - 对 Python 项目，用
pip install --no-cache-dir -r requirements.txt避免缓存干扰 - 对 Node.js 项目，优先用
npm ci（而非npm install）确保锁定版本并跳过 devDependencies
多上下文支持：突破单目录限制
传统构建只能传一个本地目录，但实际项目常需跨位置引用：比如配置模板在 ../configs，证书在 /etc/secrets，甚至远程 CI 产物在 S3。BuildKit v0.8+ 支持多上下文，让这事变得可控。
- 启用 BuildKit：
DOCKER_BUILDKIT=1 docker build .或设环境变量永久开启 - 用
--build-context指定额外上下文，例如：docker build --build-context app=./src --build-context conf=../configs -f Dockerfile . - Dockerfile 中通过
COPY --from=app或COPY --from=conf引用对应上下文 - 远程 URL 也可作为上下文：
--build-context data=https://example.com/data.tar.gz，适合静态资源或预编译产物
上下文传输优化：大项目别硬扛
当上下文超过 50MB，本地构建可能卡顿；CI 中频繁上传更是瓶颈。这时应主动拆分或换传输方式。
- 对超大静态资源（如前端 dist、模型权重），改用
ADD https://...直接下载，不纳入上下文 - Kaniko 等无守护进程构建器支持云存储上下文：
--context=gs://bucket/path/context.tar.gz - CI 流水线中，可先压缩上下文：
tar -C ./app -czf context.tgz .，再上传至对象存储，最后由构建器拉取解压 - 避免在上下文中放二进制大文件（如数据库 dump、视频），它们不会进入镜像，却白白拖慢构建
