使用buildah构建镜像时缓存机制、参数差异及COMMIT步骤咨询

三类构建参数的差异，以及默认模式不复用缓存的原因 #

buildah bud的三类参数运行逻辑有明确区分：

• --layers：显式开启分层缓存机制。开启后每执行完一条Dockerfile指令，Buildah都会将当前的文件系统、配置变更提交为独立的中间镜像层，持久化存储在本地。后续构建时，只要当前指令内容、父层哈希未发生变化，就直接复用已有中间层，无需重新执行指令，日志中出现的Using cache就是缓存命中的提示。
• 默认模式（不带--layers、--no-cache参数）：默认关闭分层缓存机制。构建过程中产生的所有中间临时容器、临时变更都不会作为独立镜像层持久化存储，仅在全部Dockerfile指令执行完成后，将最终的变更一次性提交为目标镜像。日志中出现的blob复制、签名校验、manifest写入记录，就是最终镜像写入本地镜像存储的流程——由于中间层根本没有持久化保存，自然没有缓存可以复用。
• --no-cache：该参数的设计作用是在分层缓存开启的前提下，强制跳过所有缓存校验，从头执行所有指令、生成全新的镜像层。如果单独使用--no-cache而不开启--layers，实际效果和默认模式几乎一致，因为默认模式本身就不存储中间层、没有可复用的缓存，这也是测试中两种模式表现相似的核心原因。

逻辑总结：默认模式不存储中间层，无缓存可用；--layers模式存储中间层，默认优先复用缓存；--layers --no-cache组合模式存储中间层，但本次构建强制忽略已有缓存，全量重新生成所有层。

构建日志自动出现COMMIT步骤的原因 #

COMMIT是容器镜像构建工具的内置操作，并非供用户写入Dockerfile的指令。
Dockerfile中每条指令（RUN/COPY/ENV等）的执行逻辑，都是基于上一步的镜像启动一个临时运行容器，在容器内完成对应操作后，将容器的当前状态（文件变更、环境变量、启动配置等）固化为可存储的镜像数据，这个固化操作就是COMMIT。

• 开启--layers时，每条指令执行完成后都会隐式执行一次COMMIT生成中间缓存层，因此日志不会单独展示最终的COMMIT步骤，所有提交操作都已经在指令执行、缓存复用的流程中完成。
• 关闭--layers时，中间步骤的临时状态不会被提交持久化，等所有Dockerfile指令执行完毕后，才会执行一次最终的COMMIT，把全量变更一次性固化为最终镜像，因此日志中会单独展示COMMIT步骤，步骤后输出的哈希值就是最终生成的镜像ID。

内容的提问来源于stack exchange，提问作者tran huynhtoi