凌晨两点被一条构建流水线的红灯叫醒日志里只有孤零零一行docker: Error response from daemon: no command specified.——这种报错最让人抓狂的地方在于它不告诉你缺的是什么命令、该由谁提供、是镜像的问题还是命令行的问题。我自己第一次遇到时下意识以为是网络拉取失败或者 daemon 抽风重启了一圈服务才发现根本不是那回事。这条报错的本质非常朴素docker run把要运行的镜像和要执行的命令这两件事分开处理当你既没在命令行给命令、镜像自身又没带默认命令时daemon 就卡在我到底该启动什么进程这一步直接把请求打回来。它跟镜像能不能跑、依赖装没装、端口通不通完全无关纯粹是一个启动指令缺失的问题。这篇内容适合三类人看一是刚接触容器、被这条报错拦住的新手二是自己写 Dockerfile 打包、偶尔踩到多阶段构建坑的开发者三是维护 CI 流水线、需要把这类错误挡在发布之前的工程同学。我会把这条报错拆到参数传递的层面讲清楚镜像里那两个决定跑什么的配置字段是怎么工作的再给出从应急救火到根治的完整路径以及我自己踩过的几个反直觉的坑。1. 先把这条报错的字面含义嚼碎daemon 到底在等什么1.1 从 docker run 的参数传递链路说起很多人把docker run当成启动一个镜像来看这个心智模型是错的。它实际做的事是读取镜像的配置元数据把镜像自带的两段指令入口点和默认参数与你在命令行尾巴上追加的内容做一次拼接运算拼出来的结果非空才交给容器运行时去执行。这条链路里任何一环算出来是空就会得到no command specified。用一个生活化的类比镜像就像一份套餐说明里面写着本店默认上什么菜入口点和默认配什么小料默认参数。docker run就是你在柜台点单。如果你说来一份套餐店家看说明就能上菜如果你说来一份套餐但小料换成辣椒店家也能上可如果这份套餐说明上默认菜品那一栏是空白你自己又没说要点什么柜台就只能告诉你没指定要做什么。对应到命令上这三种写法结果完全不同# 写法一镜像自带 CMD直接跑 docker run my-image:1.0 # 写法二镜像没 CMD命令行补一个 docker run my-image:1.0 /bin/sh # 写法三镜像没 CMD命令行也没给 —— 就是报错现场 docker run my-image:1.0写法一和写法三在键盘上只差一个镜像标签行为却天差地别。这也是为什么很多人觉得昨天还能跑的镜像今天报错了——其实是昨天用的是带 CMD 的那个 tag今天换成了构建脚本产出但忘了写 CMD 的新 tag。理解这一点之后排查方向就非常明确了不要去查网络、不要去查存储驱动、不要去重启 daemon直接去看镜像的元数据里那两个字段是不是空的。1.2 为什么有些镜像天生就没有默认命令新手常有的困惑是官方镜像都能直接跑为什么我自己做的就不行原因在于默认命令不是镜像的必备属性而是构建者主动写进去的可选属性。基础镜像的维护者通常会在 Dockerfile 末尾写一行CMD让镜像开箱即用。但一旦你基于某个基础镜像做二次构建或者用完全自定义的方式产出镜像这行CMD就可能丢失。最典型的几种天生没命令的情况用FROM scratch从零构建只COPY进去一个静态编译的二进制没写CMD多阶段构建最后一段只COPY --frombuilder拷贝产物忘了补CMD用docker import把一个 rootfs 压缩包导入成镜像这种方式根本不解析任何构建指令元数据全空用docker commit从一个已经退出的容器提交镜像提交时容器配置里的命令字段本身可能就是空的使用某些极简的、连 shell 都不带的裁剪版基础镜像其设计意图就是我不预设你怎么跑。这里有个容易被忽略的点FROM scratch这类镜像是没有任何可执行文件环境的连/bin/sh都没有。所以当它报no command specified时你随手补一个/bin/sh也跑不起来会变成另一个报错。这一点后面会专门讲。注意报错信息里的 no command specified 是 daemon 侧返回的说明请求已经到达了守护进程、镜像也已经存在本地。如果镜像不存在报的会是 Unable to find image ... locally 之类。看到这条报错就说明镜像拉取和权限这两块可以先排除。2. 三类没命令镜像的来源画像与判定手法2.1 用 docker image inspect 一眼定性排查第一步永远是取证不要靠猜。最直接的命令是docker image inspect my-image:1.0 --format {{json .Config.Entrypoint}} {{json .Config.Cmd}}这条命令只输出两个字段比翻完整 JSON 高效得多。你会看到几种典型结果输出结果含义能否直接 runnull null两个字段都没设不能必报错null [/app/start.sh]只有默认命令能直接跑[/app/entrypoint.sh] null只有入口点能入口点单独执行[/app/entrypoint.sh] [--port,8080]两者都有能拼接后执行[] []显式设置成空数组不能必报错注意最后一行。空数组[]和null在行为上等价但成因不同——空数组通常意味着构建时写了CMD []或者被某个构建工具的模板覆盖成了空值。我在一个自动生成 Dockerfile 的脚手架里就见过这种情况模板里有个% cmd %变量某个服务的配置没填渲染出来就是CMD []语法合法、构建通过、运行直接炸。顺便说一句docker history也能间接帮你定位但它展示的是层的历史对于这条 CMD 到底被哪一层覆盖掉了这种问题帮助有限。真正有用的是看构建日志——如果你保留了完整的构建输出能看到每一步的执行记录包括 CMD 那一步有没有真的执行。2.2 docker import 出来的 rootfs 镜像必然为空这是新手最常踩的坑之一。很多人手里有一个 tar 包可能是从别的环境导出的文件系统也可能是别人给的产物想把它变成镜像顺手就用了docker import rootfs.tar my-image:1.0命令成功了docker images也能看到一切看起来正常。但一docker run就报no command specified。原因是docker import做的事情只有一件——把 tar 包解压成一层文件系统。它完全不解析CMD、ENTRYPOINT、ENV、WORKDIR、EXPOSE这些元数据全是空的。对比一下docker load它加载的是docker save导出的完整镜像归档包含所有层和全部配置元数据所以命令字段会被完整保留。这两个命令名字很像行为差别巨大混淆的代价就是一次深夜排查。如果你必须用docker import正确的补法是导入时用-c参数指定配置docker import \ -c CMD [/app/server,--config,/etc/app/config.yaml] \ -c WORKDIR /app \ rootfs.tar my-image:1.0-c后面跟的是 Dockerfile 语法的指令字符串可以写多条。这样导入出来的镜像就带上了默认命令。不过说实话-c的写法可读性很差容易写错引号。我的习惯是能用 Dockerfile 就别用 import实在要用就写一个只有三行的 DockerfileFROM一个临时 tag再把CMD补上构建出来的镜像干净、可复现、可审计。2.3 多阶段构建最后一段只 COPY 不写 CMD多阶段构建是这条报错的第二大来源。看一个最常见的错误写法FROM golang:1.22 AS builder WORKDIR /src COPY . . RUN go build -o /out/server ./cmd/server FROM alpine:3.19 WORKDIR /app COPY --frombuilder /out/server /app/server # 到这里就结束了没有 CMDdocker build一路绿灯没有任何警告。因为从语法上讲Dockerfile 不要求必须有CMD。但产出的镜像就是跑不起来。我第一次写多阶段构建时就栽在这里当时还傻乎乎地以为是 alpine 基础镜像有问题换了三个基础镜像才反应过来是自己漏了一行。补法很简单FROM alpine:3.19 WORKDIR /app COPY --frombuilder /out/server /app/server CMD [/app/server]这里有个值得说清楚的取舍为什么用CMD而不是ENTRYPOINT在镜像就是一个单一可执行程序的场景下两者都能工作。区别在于覆盖成本——CMD可以被docker run image 别的命令直接覆盖调试时很方便ENTRYPOINT则需要用--entrypoint才能改。对于自建的、单纯跑一个服务的镜像我倾向于用CMD把灵活性留给命令行对于这个镜像就只干这一件事的工具型镜像用ENTRYPOINT更合适。另一个细节如果你的产物是一个需要用 shell 展开变量的启动脚本别写成CMD /app/server --port $PORT这种形式原因在第 3 章会详细展开。2.4 docker commit 提交的镜像继承了谁docker commit的语义是把一个容器的当前状态固化成镜像。它继承的是那个容器的配置包括启动命令。所以问题变成这个容器当初是怎么启动的如果容器是用docker run -it my-image /bin/bash启动的那提交出来的镜像CMD就是[/bin/bash]。这不算没有命令但显然不是你想要的——镜像跑到生产环境里会直接弹出一个 bash然后因为没有 TTY 立刻退出。这种情况不会报no command specified而是容器启动后立刻 Exited排查思路完全不同。真正会报no command specified的是容器本身是用--entrypoint 加上空的命令启动的或者容器配置被某些工具改过。这种情况相对少见但如果你在用一些自动化脚本做镜像固化就要留意它们有没有动过Config.Cmd。更普遍的教训是docker commit本质上是一种不可复现的构建方式你不知道镜像里到底有什么也不知道元数据是怎么来的。除了临时调试我不建议用它产出任何需要长期维护的镜像。老老实实写 Dockerfile命令字段清清楚楚摆在文件里谁都能看懂。3. ENTRYPOINT 与 CMD 的四种组合搞不清就会反复踩3.1 exec form 与 shell form 的实质差别这两个字段各自都有两种写法很多人只记住了要用方括号但不知道背后的原因于是在需要 shell 特性的场合又改回去反复横跳。exec form推荐CMD [/app/server, --port, 8080]Docker 直接把方括号里的第一项当作可执行文件去 exec后面的项作为参数原样传入。进程在容器里的 PID 是 1能直接收到SIGTERMdocker stop能干净地优雅退出。shell formCMD /app/server --port 8080Docker 会把它包装成/bin/sh -c /app/server --port 8080来执行。这时候容器里的 PID 1 是那个 shell你的服务进程是 shell 的子进程。后果有两个一是docker stop发的SIGTERM只到了 shellshell 未必转发给子进程于是十秒超时后 Docker 发SIGKILL强杀你的日志里看不到任何优雅退出的痕迹二是某些精简镜像根本没有/bin/shshell form 直接启动失败——而且报的错跟本文这条还不一样容易让人更懵。判断自己用的是哪种形式很简单看元数据里第一项是不是/bin/sh。docker image inspect my-image:1.0 --format {{json .Config.Cmd}} # 输出 [/bin/sh,-c,/app/server --port 8080] 就是 shell form还有一个隐蔽的坑exec form 里不会做变量展开。CMD [/app/server, --port, $PORT]传给进程的就是字面量$PORT不是环境变量的值。如果你需要变量展开正确的做法是写一个入口脚本在脚本里展开然后用 exec form 调用这个脚本。3.2 组合矩阵与覆盖规则ENTRYPOINT和CMD的组合规则是理解为什么我明明写了 CMD 还是报错的关键。这张表我建议直接背下来ENTRYPOINTCMD最终执行命令行追加参数后空空报错用命令行内容执行空[a,b]a b用命令行内容替换 CMD[e]空ee 命令行内容[e][a,b]e a be 命令行内容CMD 整体被替换[e,a][b]e a be a b 命令行内容关键认知有两条第一CMD 在 ENTRYPOINT 存在时角色是默认参数而不是命令。所以当 ENTRYPOINT 为空、CMD 也为空时就真的什么都没有了这正是报错的条件。第二命令行追加的参数会整体替换 CMD但会追加到 ENTRYPOINT 后面。这就是为什么很多工具型镜像的 Dockerfile 写成ENTRYPOINT [/app/cli]然后你docker run image --help就能用——--help追加到 ENTRYPOINT 后面变成/app/cli --help。回到报错本身如果你在 Dockerfile 里只写了ENTRYPOINT而没写CMD其实是能跑的表里第三行。反过来说如果你只写了CMD没写ENTRYPOINT也能跑。唯独两个都不写才会撞上这条报错。所以在排查时docker image inspect必须同时看两个字段只查一个可能得出错误结论。3.3 --entrypoint 的空字符串陷阱这是一个反直觉的场景镜像本身好好的能跑但你在命令行加了点东西之后反而报错了。# 镜像本身 CMD 是 [/app/server]能正常跑 docker run my-image:1.0 # 加了这个参数报 no command specified docker run --entrypoint my-image:1.0原因--entrypoint 会把 ENTRYPOINT 显式置为空字符串。按照上面的组合规则这时候 ENTRYPOINT 为空、你也没在命令行给命令那 CMD 本该生效——但实际行为是--entrypoint这个参数会连带把 CMD 的清空逻辑触发最终两边都空直接报错。对应的正确写法是必须同时给出命令docker run --entrypoint my-image:1.0 /app/server我用--entrypoint 的典型场景是临时绕过镜像的入口脚本直接进容器排查。比如镜像的 ENTRYPOINT 是个会做一堆初始化的脚本你想跳过它直接执行shdocker run -it --entrypoint my-image:1.0 /bin/sh这个组合是有明确目的的不是随手乱加。所以每次敲--entrypoint的时候我养成的习惯是只要写了它后面一定跟着要执行的命令绝不单独使用。4. 修复方案从临时救火到根治4.1 命令行补命令的应急姿势线上出了问题第一优先级是让服务先跑起来这时候改 Dockerfile 重新构建太慢。应急手法就是直接在docker run尾巴上把命令补上# 知道镜像里有什么可执行文件直接指定 docker run -d --name app my-image:1.0 /app/server --port 8080 # 不确定里面有什么先探一下 docker run --rm --entrypoint my-image:1.0 /bin/ls -la /app第二条命令的思路值得单独讲先用一个临时容器把文件系统翻一遍确认可执行文件到底在哪、叫什么名字。我见过太多人凭直觉猜路径猜了七八次都猜错其实花三十秒ls一下就能确定。如果镜像连 shell 都不带FROM scratch构建的/bin/sh和/bin/ls都试不了。这时候只能从构建侧确认产物路径或者用docker create加上docker export把文件系统导出来看docker create --name tmp my-image:1.0 docker export tmp -o rootfs.tar tar -tf rootfs.tar | head -50 docker rm tmpdocker create在这个场景有个额外好处它只创建容器不启动所以即使镜像没有命令某些情况下也能创建成功方便你排查。应急修完之后一定要记一笔——命令行补命令是治标Dockerfile 才是治本。否则下次别人用同一个镜像还是会在同一个地方摔一次。4.2 Dockerfile 里补 CMD/ENTRYPOINT 的正确写法根治方案是在 Dockerfile 里把命令写清楚。但写清楚有讲究不是随便加一行就行。第一位置必须在最后。Dockerfile 里只有最后一条CMD会生效前面写的全被覆盖。我见过有人在中间写了一条CMD后面又加了几行RUN结果完全没意识到那条CMD其实还生效因为没有第二条覆盖它但一旦某个RUN步骤引入了新的CMD比如某些基础镜像的构建片段就会莫名其妙失效。把CMD死死钉在文件末尾是最省心的纪律。第二参数拆分要正确。exec form 的每一个元素是一个独立的参数不要图省事写成CMD [/app/server --port 8080]——这样会把整个字符串当成一个可执行文件名去找找不到就报 no such file or directory又是一个新的坑。正确写法是每段分开CMD [/app/server, --port, 8080, --config, /etc/app/config.yaml]第三环境变量要走 ENV 或者入口脚本。前面说过 exec form 不展开变量。如果你的端口需要可配置正确做法是ENV APP_PORT8080 # 这样不行CMD [/app/server, --port, $APP_PORT] # 要么用入口脚本要么用 shell form但牺牲信号处理第四注释写清意图。这一条看起来是废话但在多人协作的仓库里极其有用# 该服务无外部依赖唯一入口是编译产物 /app/server # 不接受位置参数所有配置通过 --config 传入 CMD [/app/server, --config, /etc/app/config.yaml]半年后接手的人一眼就能看懂为什么这么写不会随手改成ENTRYPOINT试探。4.3 用 init 脚本加 exec $ 做入口当启动前需要做一些准备工作——渲染配置模板、等待依赖就绪、初始化数据目录、处理信号转发——单靠一行CMD就不够了需要一个入口脚本。这是我认为最值得掌握的一个模式也是最容易写错的一个模式。错误写法脚本最后不用 exec#!/bin/sh set -e # 渲染配置 envsubst /etc/app/config.tpl /etc/app/config.yaml # 启动服务 /app/server --config /etc/app/config.yaml问题在于脚本是 PID 1服务是子进程。docker stop发的信号到了脚本脚本没有转发逻辑服务收不到只能等超时被强杀。日志里缺少优雅退出的记录数据库连接可能被硬断。正确写法用 exec 替换进程#!/bin/sh set -e # 渲染配置 envsubst /etc/app/config.tpl /etc/app/config.yaml # exec 让服务进程直接接管 PID 1 exec $配合 DockerfileCOPY entrypoint.sh /usr/local/bin/entrypoint.sh RUN chmod x /usr/local/bin/entrypoint.sh ENTRYPOINT [/usr/local/bin/entrypoint.sh] CMD [/app/server, --config, /etc/app/config.yaml]这里exec $的作用是把脚本收到的参数也就是 ENTRYPOINT 后面拼接的 CMD 内容原样执行并且用新进程替换掉当前 shell 进程所以服务的 PID 就是 1信号直达优雅退出正常工作。这个组合还有个额外好处ENTRYPOINT固定为脚本CMD是默认参数用户docker run image --help时会变成entrypoint.sh --help脚本做完初始化后exec --help——当然这会失败所以工具型镜像不要这么套服务型镜像这么套最合适。如果镜像里没有 shellscratch 构建就没法写 shell 脚本了。这时候要么在构建阶段用静态编译的 init 程序要么干脆放弃初始化逻辑把所有准备动作放到构建期完成。这也是我为什么倾向于给应用镜像保留一个最小 shell 环境——省下的几兆空间换来的可维护性差距很大。4.4 docker import 场景怎么补再说回docker import。除了前面提到的-c参数还有一种更可控的做法写一个包装 Dockerfile。FROM scratch ADD rootfs.tar / CMD [/app/server]ADD会自动解压 tar 包到根目录CMD补上默认命令。这么做的好处是构建过程被记录下来了镜像有历史可查任何人看 Dockerfile 就知道架构是 scratch 还是 alpine、有哪些元数据不用去翻脚本里那串引号嵌套的-c参数。代价是镜像层结构会变多了一层但对于把已有产物重新打包成镜像这个需求这点代价完全可以接受。5. 一次完整的排查复盘从报错到定位到验证5.1 现场信息收集的顺序我处理这类问题的固定顺序是这样的几乎不会漏第一步确认报错原文。是不是真的no command specified而不是executable file not found或者permission denied。这三个错误看起来都像命令有问题但根因完全不同前者是没有命令中者是命令存在但路径不对后者是命令在但没有执行权限常见于 Dockerfile 里COPY了脚本但忘了chmod x。第二步确认镜像有没有被换过。对比一下docker images里同一个仓库名下有哪些 tag是不是 CI 刚推了新版本。这一步能解决大量以前能跑现在不行的悬案。第三步查元数据。docker image inspect image --format Entrypoint{{json .Config.Entrypoint}} Cmd{{json .Config.Cmd}}第四步如果是空判断镜像怎么来的。看docker history有没有构建层有构建层的说明是docker build出来的去翻 Dockerfile只有一层且体积巨大的多半是import进来的。第五步验证修复。修完之后不要只看报错消失要确认进程真的按预期跑起来了。# 确认容器状态不是立刻退出 docker run -d --name verify my-image:1.0 sleep 3 docker ps --filter nameverify # 确认 PID 1 是目标进程不是 /bin/sh docker exec verify ps -o pid,comm -p 1 # 确认信号能正常接收 docker stop verify docker logs verify | tail -20第三步到第五步这三条验证命令我强烈建议做成肌肉记忆。尤其是查 PID 1 那条它能一次性暴露 shell form 的问题比事后分析日志高效得多。5.2 逐步收敛到根因的过程说一个我印象比较深的具体案例。某次一个新服务的镜像在测试环境跑得好好的上了预发布就开始报no command specified。同一个版本号、同一个仓库行为却不一样这种情况特别容易让人怀疑是环境问题。排查过程是这样的先比对两边镜像的摘要值。docker image inspect --format {{.Id}}打出来发现两个环境的镜像 ID 不同。说明仓库里同一个 tag 被推了两次两边拉到的不是同一个东西。再查本地镜像的元数据发现预发布那台的镜像Cmd是[]而测试环境那台是[/app/server]。最后追到流水线这个服务的构建脚本里有个可选参数控制是否使用轻量构建模式。测试环境的分支没启用走的是常规 Dockerfile有CMD预发布分支启用了走的是另一个精简版 Dockerfile末尾漏了CMD。两边 tag 都打成latest互相覆盖所以看起来同一个 tag 行为不同。这个坑的教训有两条都很实在一是不要用同一个 tag 推不同内容。现在我们的规范是每次构建带 git 提交短哈希latest只作为当前推荐版本的别名不允许覆盖推送。二是环境差异的怀疑要放在最后。90% 的环境问题最后都证明是环境里的制品不一样。先比制品再比环境。5.3 修复之后怎么防止复发问题修好之后我在那个仓库里加了一个极简的检查脚本放在构建流水线的最后一步#!/bin/sh set -e IMAGE$1 CMD$(docker image inspect $IMAGE --format {{json .Config.Cmd}}) EP$(docker image inspect $IMAGE --format {{json .Config.Entrypoint}}) if [ $CMD null ] [ $EP null ]; then echo FAIL: $IMAGE 既没有 CMD 也没有 ENTRYPOINT无法直接运行 exit 1 fi echo OK: $IMAGE 元数据检查通过十几行跑一次不到一秒但它把构建成功但跑不起来这一类问题全部挡在了流水线内。后来我又在里面加了一条如果Cmd的第一项是/bin/sh打一个警告——提示这个镜像可能用的是 shell form需要注意信号处理。这个警告救过我们一次因为有个服务重启时总是超时十秒才退出看到警告才反应过来是 shell form 的问题。6. 把这类错误挡在 CI 之外6.1 元数据校验之外还该检查什么光检查命令字段非空只能挡住最粗心的情况。实际用下来我认为还有几个检查项性价比很高检查项判定方法挡掉的问题命令字段非空Config.Cmd与Config.Entrypoint不同时为 null本文这条报错命令首项不是 shellConfig.Cmd[0] ! /bin/shshell form 的信号问题可执行文件存在起临时容器跑一次test -x路径写错、脚本没 chmod短时启动不退跑 3 秒后容器仍在运行启动即崩、依赖缺失端口声明一致Config.ExposedPorts与文档一致配置漂移第三条在 scratch 镜像上做不了没有test命令可以退化成构建期在 builder 阶段检查产物路径。第四条是最有价值的它不检查元数据直接检查行为——命令字段写得再对容器起来三秒就退出照样是废的。6.2 上线前的快速启动验证这条我建议所有自建镜像的项目都加成本极低#!/bin/bash set -e IMAGE$1 CONTAINERsmoke-$$ docker run -d --name $CONTAINER $IMAGE /dev/null sleep 3 STATUS$(docker inspect --format {{.State.Running}} $CONTAINER) EXIT_CODE$(docker inspect --format {{.State.ExitCode}} $CONTAINER) docker rm -f $CONTAINER /dev/null if [ $STATUS ! true ]; then echo FAIL: 容器启动后退出exit code$EXIT_CODE exit 1 fi echo OK: 快速启动验证通过sleep 3这个值不是拍脑袋定的。太短会误判有些语言运行时启动就要两秒以上太长会拖慢流水线。我的经验是三秒能覆盖绝大多数服务的启动阶段对于明确要做长时间初始化的服务把这个脚本里的等待时间单独配长一点。另外记得在docker run里把-p端口映射去掉验证阶段不需要暴露端口避免端口冲突导致误判。还有一个容易被忽略的细节这个脚本用完必须保证容器被删掉不管成功失败。上面的写法用了带 PID 的容器名加强制删除基本不会残留。我见过流水线跑多了之后宿主机上堆了几百个残留容器把磁盘撑爆的排查起来又是一场噩梦。6.3 长期维护上的几个习惯最后说几个我认为最有价值的长期习惯都是踩坑换来的。第一把镜像能不能跑当成构建产物的验收标准而不是构建命令有没有返回 0。这两个指标经常不等价尤其是 Dockerfile 里写了CMD []或者漏写的时候构建永远是成功的。流水线的最后一步必须是真的把它跑起来看看。第二给每个服务写一行启动契约注释。在这行注释里写清楚这个镜像的入口是什么、接受哪些参数、哪些参数会被命令行覆盖。放在 Dockerfile 的CMD上方二十个字就够。它的价值在于阻止别人随手把CMD改成ENTRYPOINT或者在多阶段构建里合并阶段时删掉那一行。第三基础镜像升级要重新跑一遍验证。有些精简镜像在新版本里改了默认命令或者移除了某些工具升级之后行为就变了。这类变化不会体现在任何变更日志里只能靠验证脚本兜底。第四遇到no command specified先别急着改 Dockerfile。先用docker image inspect看清事实再决定改哪里。我就见过有人为了修这个报错在 Dockerfile 里加了三行RUN装依赖、改了基础镜像最后发现问题只是流水线跑的是旧的 tag。做了半天无用功原因是排查顺序反了。这套东西用下来我现在看到这条报错基本能在两分钟内定位。它的难点从来不在技术本身——参数拼接规则就那么两条——而在于大部分人第一次遇到时不知道往哪个方向看容易把镜像缺命令误判成环境有问题。把docker image inspect那两个字段刻进排查肌肉记忆里剩下的都是水到渠成的事。
