开。–layers 仅在复用中间层、高频构建且基础镜像稳定时才有效；默认不开启，启用后基于指令哈希与文件快照判断复用，但大量小文件会拖慢速度。
buildah bud 的 --layers 到底开不开？
开。但只在需要复用中间层、且镜像构建频次高、基础镜像稳定时才值得开。
默认不开启 --layers，buildah 每次都从头构建整个镜像（类似 docker build --no-cache），干净但慢；启用后会尝试复用上一次构建中未变的 layer，逻辑接近 Docker 的 layer 缓存，但底层机制不同——buildah 是靠比对每层的构建指令哈希 + 文件系统快照来判断是否可跳过。
- 如果
Dockerfile里有COPY . /app且源码经常改，--layers基本无效，因为 COPY 层哈希总变 - 把
RUN pip install -r requirements.txt放在COPY之前，才能让依赖安装层真正被缓存 - buildah 不读取本地已有镜像的 layer 元信息做缓存，它只认自己上次用同一
--storage-driver和同一构建上下文生成的 layer
为什么 buildah bud --layers 有时反而更慢？
因为 layer 哈希计算和快照比对本身有开销，尤其当某一层包含大量小文件（比如 node_modules 或 __pycache__）时，buildah 需要遍历并计算每个文件的 checksum。
这不是 bug，是设计取舍：buildah 优先保证 layer 内容一致性，不像 Docker 那样依赖文件修改时间（mtime）这种不可靠依据。
- 避免在构建上下文中包含无用文件（用
.dockerignore类似逻辑，但 buildah 不直接读该文件；需手动清理或用--context指定精简路径） - 若项目含巨量小文件，考虑先打包成 tar 后
RUN tar -xf，把“一堆小文件”变成“一个大文件”，减少哈希遍历压力 -
BUILDAH_FORMAT=oci下 layer 缓存行为与docker更接近；若用buildah默认的oci-archive格式，layer 复用率可能略低
buildah bud 缓存失效的三个典型错误写法
缓存不是自动生效的，很多看似合理的 Dockerfile 写法会让 --layers 彻底失效。
-
RUN git clone https://…… && cd app && make—— 每次 clone 的 commit hash 不同，导致 RUN 指令哈希总变，后续所有层都无法复用 -
ENV BUILD_TIME=$SECONDS或RUN date > /build-time—— 引入非确定性输入，整条指令哈希不可预测 -
COPY package-lock.json .后紧接RUN npm ci，但没同时COPY package.json—— buildah 检查 layer 输入时发现package.json缺失，无法安全复用 npm 安装层
替代方案：什么时候该放弃 --layers，改用 buildah from + buildah run？
当构建流程复杂、跨阶段依赖多、或者需要精细控制 layer 边界时，声明式 Dockerfile + --layers 反而难调试。
比如 CI 中构建 Go 二进制再塞进 alpine 镜像：用 buildah from golang:1.22 编译，buildah from alpine:3.20 作为目标，再 buildah copy 二进制过去，整个过程 layer 完全可控，也天然规避了 Dockerfile 中 ADD/COPY 顺序引发的缓存断裂。
- 适合多阶段构建中“编译环境”和“运行环境”差异极大、且不想维护两份
Dockerfile的场景 -
buildah run --volume $(pwd):/src可挂载宿主机目录，绕过上下文复制开销，对本地快速迭代更友好 - 注意：
buildah commit生成的镜像 layer 默认不压缩，推送到 registry 前建议加--format oci和--compression gzip
缓存最脆弱的地方不在工具开关，而在你每次 buildah bud 时传进去的那个构建上下文——它是不是真的“最小必要”，有没有隐藏的时间戳、随机数、临时文件。这些细节不会报错，但会让 --layers 形同虚设。
