CMD 默认参数不漂移，但行为受 ENTRYPOINT 形式、运行时传参、基础镜像 shell 差异、多阶段构建及缓存影响：shell 形式 ENTRYPOINT 忽略 CMD；exec 形式则追加；无 ENTRYPOINT 时 docker run 参数完全覆盖 CMD；推荐统一用 exec 形式并显式声明 CMD。
CMD 指令的默认参数本身不会“漂移”，但它的行为表现会因执行上下文、基础镜像、ENTRYPOINT 设置以及运行时传参方式不同而变化，导致看似“参数漂移”的现象。
CMD 与 ENTRYPOINT 的组合决定最终执行逻辑
Docker 中 CMD 的实际作用高度依赖于 ENTRYPOINT 的存在形式：
- 当使用 shell 形式 的 ENTRYPOINT（如
ENTRYPOINT node app.js），CMD 会被完全忽略——此时 CMD 的默认参数根本不会生效 - 当使用 exec 形式 的 ENTRYPOINT（如
ENTRYPOINT ["node", "app.js"]），CMD 会作为参数追加到 ENTRYPOINT 后面，例如CMD ["--port", "3001"]最终执行的是node app.js --port 3001 - 如果未设置 ENTRYPOINT，CMD 才作为容器主进程直接运行；此时若运行容器时带参数（如
docker run myimg --debug），CMD 的默认参数会被完全覆盖，而非合并
基础镜像的 shell 层会影响 CMD 解析方式
不同基础镜像的默认 shell 和 PATH 可能不同，间接影响 CMD 执行结果：
- Alpine 镜像通常用
/bin/sh，而 Ubuntu/Debian 默认是/bin/bash，某些 shell 特性（如数组展开、变量替换）行为不一致 - 如果 CMD 写成
CMD echo $HOME（shell 形式），在 Alpine 中可能输出空值，因为/bin/sh不自动导入所有环境变量，而 bash 会 - 推荐统一使用 exec 形式（方括号语法）避免 shell 解析差异：
CMD ["echo", "$HOME"]不会做变量替换，需改用sh -c 'echo $HOME'显式调用
运行时参数覆盖规则容易被误解
很多人误以为 docker run 传的参数是“追加”到 CMD，默认参数仍保留，实际规则更严格：
-
CMD ["npm", "start"]+docker run myimg --watch→ 执行--watch，不是npm start --watch - 只有当 ENTRYPOINT 是 exec 形式时，
docker run myimg --watch才会把--watch传给 ENTRYPOINT；否则 CMD 被彻底替换 - 若想保留默认行为又支持灵活覆盖，应将可变部分设计为环境变量或配置文件，而非依赖 CMD 参数拼接
多阶段构建中 CMD 容易被意外继承或丢失
在 FROM 多次出现的 Dockerfile 中，CMD 只对最后一个 stage 生效，且可能被中间 stage 的指令干扰：
- 如果前一个 stage 用了
FROM alpine:latest并设置了 CMD，而后一个 stageFROM ubuntu:22.04没有再写 CMD，则最终镜像无 CMD - 构建缓存可能导致某次构建跳过了预期的 CMD 指令（比如因前面某层命中缓存，后续 COPY + CMD 未重执行）
- 建议每个最终运行 stage 显式声明 CMD，并用
docker inspect myimg | grep Cmd验证生成镜像的实际 CMD 值
