凡是"需要构建容器镜像"的业务都会用到docker build，而当业务对构建过程有更高要求时，就需要buildx。下面按场景展开。
只用docker build就够的场景
这类场景的共同点是：单机、单架构、Dockerfile 简单、构建频率低。
- 个人开发/学习：本地写个 Flask 小服务或算法 demo，
docker build -t myapp .打个镜像自己跑，没有跨平台需求。 - 遗留系统维护：老的 CI 脚本、Makefile 里写死了
docker build，Dockerfile 没用新语法，能跑就不动它。 - 应急修补：线上某个镜像缺个工具，临时写两行 Dockerfile 重新 build 一版推上去。
实际上，新版本 Docker 里docker build已经是docker buildx build的别名（底层同样走 BuildKit），所以"只用 docker build"更多是指只用到最基本的功能子集。
需要 buildx 的业务场景
1. 多架构交付（最典型的场景）
产品要同时跑在 x86 服务器和 ARM 设备上：
云原生产品：K8s 集群里混布 x86 节点和 ARM 节点（如 AWS Graviton、华为鲲鹏、阿里倚天），镜像必须提供
linux/amd64+linux/arm64的 multi-arch manifest，一条命令搞定：dockerbuildx build--platformlinux/amd64,linux/arm64-tmyrepo/app:v1--push.边缘计算/嵌入式：这个场景你非常熟悉——软件既要跑在数据中心 x86 GPU 服务器上，又要跑在 Jetson（aarch64）边缘盒子里。Holoscan SDK 从 x86 主机构建 arm64 镜像就是典型例子，传统
docker build做不了这件事。
2. CI/CD 流水线中的构建加速
业务迭代快、每天构建几十上百次时，构建速度直接影响交付效率：
- 缓存外置与共享：
--cache-to type=registry/--cache-from type=registry把构建缓存存到镜像仓库，CI 每次从零启动的干净 runner 也能命中缓存，10 分钟的构建缩到 1 分钟。GitLab CI、GitHub Actions 的官方 Docker 构建 action 用的就是 buildx。 - 并行构建阶段：大型项目的 Dockerfile 有多个 stage（编译 C++、编译前端、打包 Python 依赖），BuildKit 自动并行无依赖的 stage。
3. 依赖重型编译的项目
- C++/CUDA 项目：编译慢，
RUN --mount=type=cache,target=/root/.ccache让 ccache 缓存在多次构建间复用——这是 BuildKit 专属语法，老引擎直接报错。 - 重复装大依赖：pip/conda 环境用缓存挂载，改一行代码重构建时不必重新下载几个 GB 的依赖。
4. 构建过程需要敏感信息
私有 pip 源要 token、内网 git 仓库要 SSH key：
dockerbuildx build--secretid=pip_conf,src=$HOME/.pip/pip.conf.密钥以挂载形式存在于构建过程中，不会留在镜像层里。传统做法是ARG传密钥，会泄漏到镜像历史，安全审计过不去。
5. 构建产物不是镜像
- 交叉编译出二进制/安装包：用
--output type=local直接把编译结果导出到本地目录，容器只当一次性编译环境。比如用 x86 容器交叉编译 ARM 固件、FPGA 上位机软件，产物拿去烧录或分发。 - 分发 rootfs tar 包：
--output type=tar。
6. 企业级构建基础设施
- 远程/共享 builder：
docker buildx create --driver remote或--driver kubernetes，把构建任务卸载到专用的构建集群上，开发机不烧 CPU。大公司（如字节、Google 内部）都有共享构建农场。 - 多节点并行构建 multi-arch：amd64 部分在 x86 节点构建，arm64 部分在 ARM 节点构建，最后合并 manifest——避免 QEMU 模拟的巨大性能损耗，这是
docker-containerdriver 的能力。
对照表
| 业务诉求 | 老docker build | buildx |
|---|---|---|
| 本机构建本机跑 | ✅ | ✅ |
| 同时出 amd64 + arm64 镜像 | ❌ | ✅ |
| 跨机器/CI 共享构建缓存 | ❌ | ✅ |
| 构建期缓存挂载（ccache/pip） | ❌ | ✅ |
| 构建期密钥不落地镜像 | ❌ | ✅ |
| 多阶段并行构建 | 串行 | ✅ 并行 |
| 产物导出为本地文件/tar | ❌ | ✅ |
| 远程/K8s 构建集群 | ❌ | ✅ |
实践建议
对于一开始面向单一环境（x86 主机 + 未来可能的 Jetson/aarch64 边缘端 + CUDA 重型编译依赖），直接在 daemon 层面全面转向 buildx 用法——docker buildx build替代docker build，Dockerfile 里善用--mount=type=cache，需要出 ARM 镜像时提前配好qemu-user-static，这样单机开发和未来 CI 化的路径是平滑衔接的。
