Dockerfile中&&与set -ex的执行差异及场景疑问

这两种写法都能实现合并命令以减少镜像层数的目的，但在错误处理逻辑和调试便利性上有明显区别，我来拆解清楚：

1. 错误处理的逻辑差异 #

&&串联写法 #

这是Docker官方最佳实践的标准写法，核心逻辑是短路执行：只有前一个命令执行成功（返回码为0），后面的命令才会被触发。比如如果apt-get update失败（比如源不可达），后续的apt-get install和清理命令都不会执行，构建会直接终止，避免生成一个依赖更新失败的坏镜像。

set -ex; 分号写法 #

这里的set -ex是Shell的内置选项，作用分别是：

• e：开启errexit模式，任何命令执行失败（返回码非0）时，整个Shell脚本立刻退出；
• x：开启xtrace模式，执行每个命令前都会打印命令本身，方便调试。

用分号分隔命令时，默认是顺序执行，但因为加了set -e，所以效果和&&的“失败即终止”类似，但有个关键区别：如果没有set -e，分号会无视前命令的失败，继续执行后续命令——这会导致构建可能成功，但镜像里存在未完成的操作（比如更新失败却执行了安装），这非常危险。而&&写法不需要额外开启set -e，天然就有短路保护。

另外，set -e的错误判断规则比&&更复杂：比如在管道命令、条件判断里，set -e的行为会有特殊处理，而&&就是简单的“前命令成功才继续”，逻辑更直观。

2. 调试体验差异 #

set -x会在构建时打印每个执行的命令，比如：

+ apt-get update
+ apt-get install -y curl
+ rm -rf /var/lib/apt/lists/*

这在排查构建失败问题时非常有用，能清楚看到哪一步出了问题。而&&写法默认只会输出命令本身的执行日志（比如apt的下载日志），不会打印命令行内容，调试时需要额外加参数。

3. 最佳实践场景建议 #

• 日常构建：优先用&&串联的写法，逻辑清晰、符合官方推荐，能确保只有前一步成功才继续，避免无效操作和坏镜像；
• 调试排查：如果构建失败原因不明，可以临时换成set -ex;分号的写法，通过set -x的输出定位问题，排查完成后再切回&&写法。

内容的提问来源于stack exchange，提问作者Borek Bernard