Docker 构建时如何引用构建上下文之外的文件？
普通本地 COPY/ADD 源受构建上下文限制；COPY --from 与 ADD 远程源有各自支持范围。解法：docker build -f 路径/Dockerfile . 把上下文设为上层目录；或用 BuildKit 的额外上下文（--build-context）、多阶段构建。本文对比各方案。
结论：普通本地COPY/ADD源受构建上下文边界限制；COPY--from可用其他阶段/镜像/命名上下文，ADD还支持特定远程源，这是安全边界，绕不过。但上下文选在哪里是你说了算的**：用 docker build -f docker/Dockerfile . 把上下文设在项目根、Dockerfile 放子目录，就能引用更大范围的文件；BuildKit 还提供 --build-context 具名上下文，直接把另一个目录挂进构建。**
方案一：-f 分离 Dockerfile 与上下文（经典）
项目结构：
project/
├── docker/Dockerfile
├── app/
├── shared-libs/ ← 想引用的目录
└── configs/
docker build -f docker/Dockerfile .
上下文是 project/（命令末尾的点），Dockerfile 里就能 COPY shared-libs /opt/libs。Dockerfile 放哪无所谓，上下文才是关键。
方案二：BuildKit 具名上下文（精准挂载）
docker build --build-context shared=../shared-libs -f Dockerfile .
Dockerfile 里：
COPY --from=shared . /opt/libs
只为所需目录开一扇窗，不扩大主上下文——传输量小、缓存精准。
方案三：多阶段构建复用其他产物
依赖另一个镜像的产物时，不必放进上下文：
FROM myorg/base-builder:latest AS builder
...
FROM runtime
COPY --from=builder /build/dist /app
不要这么干
- ❌ 符号链接指到上下文外：COPY 解析的是上下文内的文件本身，软链出界拷不到真实内容
- ❌
COPY ../shared /app：旧构建器可能报错；BuildKit可能规范化去掉父级跳转并在上下文内查找，仍不能借此读取外部目录
上下文过大的代价
传统构建器通常传整个上下文，BuildKit可按需传输相关文件；过宽上下文仍会增加风险与扫描负担——把上下文设在磁盘根目录之类操作会把巨量无关文件塞进构建，慢且可能泄密。配好 .dockerignore（排除 .git、node_modules、日志）。
常见问题（FAQ）
Q：stdin Dockerfile方式（docker build - < Dockerfile）能引用外部文件吗？
A：那种方式没有本地文件上下文，普通COPY不可用，COPY--from仍可使用；stdin也可提供含文件的tar上下文，两者不同。
Q：compose 里怎么控制上下文？
A：build: { context: .., dockerfile: docker/Dockerfile }，context按Compose项目目录解析，相对dockerfile路径基于所选context解析。
Q：BuildKit 的具名上下文能指向 git 仓库吗？
A：能，--build-context src=https://github.com/org/repo.git，构建时直接拉取。
