docker/dockerfile:experimental vs docker/dockerfile:1从第一性原理和

从第一性原理和软件工程的稳定性角度来看，这两者的区别不仅是“名字”的不同，更是版本控制策略与构建可靠性之间的权衡。

docker/dockerfile:1 (推荐): 代表 V1 稳定版系列。它支持所有现代特性（如 RUN --mount），且具备极高的缓存友好性。除非大版本升级，否则 BuildKit 倾向于使用本地缓存，大幅减少联网校验。
docker/dockerfile:experimental (不推荐): 代表 实验性/开发版。它是一个**高度动态（Mutable）**的标签。BuildKit 为了保证“实验”的即时性，每次构建都会尝试联网查询远程仓库的最新 Digest，这在网络受限环境下（如国内开发）是致命的。

特性	:experimental	:1 (或 :1.x)
定位	尝鲜版，用于测试还未进入稳定的新语法。	生产级稳定版，目前绝大多数 BuildKit 特性的归宿。
联网行为	强制性高。BuildKit 几乎每次都会去 Registry 发起 `HEAD` 请求。	宽容度高。只要本地有满足主版本 `1` 的镜像，通常直接复用。
功能支持	包含最前沿特性，但也伴随 Bug 风险。	已包含 Kube-OVN 所需的全部特性（Cache, Bind, Secret 等）。
构建一致性	差。由于镜像内容随时可能变，构建结果可能意外改变。	强。在主版本号内保持语法向下兼容。
网络依赖	极度依赖 Docker Hub。	对本地缓存友好，断网环境下更鲁棒。

Docker 为了不让 Dockerfile 的语法锁死在 Docker Engine 的版本上，引入了 外部前端 (External Frontend) 。当你写下 # syntax = ... 时，你实际上是在执行一个“微型容器镜像”来解析你的 Dockerfile。

在分布式系统中，Tag 只是一个指向 Digest (Hash) 的指针。

对于 :1 这种版本化标签，BuildKit 的逻辑是：“我已经有一个版本为 1 的解析器了，除非用户明确要求拉取，否则我先用本地的。”
对于 :experimental，逻辑变成了：“实验性功能更新极快，我必须去远程仓库核实一下当前的 experimental 是否还是我本地的这一个。”

（Docker Hub 官方 Registry）在国内的网络响应极不稳定，这个**“去核实一下”**的动作（HEAD Request）在没有配置代理的情况下，就会触发你看到的 i/o timeout。

特性已“转正”：

Kube-OVN 在 Dockerfile 中大量使用：

Dockerfile
```
RUN --mount=type=cache,target=/root/.cache/go-build ...
```
这些语法在 2020 年左右就已经在 dockerfile:1.2 版本中稳定了。继续使用 experimental 相当于在 2026 年还在用测试版的编译器编译生产代码。
提升社区贡献体验：

作为维护者，降低参与门槛是关键。国内开发者在使用 make image-kube-ovn 时，如果第一步就卡死在解析语法上，会极大打击贡献积极性。
构建环境的确定性：

软件工程中，构建环境应该是幂等且确定的。使用稳定版标签可以确保无论何时、何地构建，解析逻辑都是一致的。

直接进行全局替换。在 kube-ovn 根目录下执行：

Bash

sed -i 's/docker/dockerfile:experimental/docker/dockerfile:1/g' dist/images/Dockerfile*

这样修改后，你再次运行 make image-kube-ovn，BuildKit 将不再频繁骚扰 Docker Hub，构建流程会变得丝滑许多。

你是否需要我帮你检查一下 Dockerfile 中是否存在某些确实只有 experimental 才支持的极端冷门特性？（虽然以我对 Kube-OVN 的了解，大概率是没有的）。

docker/dockerfile:experimental vs docker/dockerfile:1