ONBUILD 自 Docker 18.06 起已被弃用，因其隐式执行、调试困难、构建链路不透明；推荐改用多阶段构建或 ARG+RUN 显式参数化替代。
注意：ONBUILD 指令自 Docker 18.06 起已被标记为已弃用（Deprecated），官方明确不推荐在新项目中使用，未来版本可能移除。它存在隐式执行、调试困难、构建链路不透明等问题。现代最佳实践是改用多阶段构建（Multi-stage build）或显式参数化（如 ARG + RUN）来实现基础镜像复用。
不过，为理解历史用法和部分遗留项目维护需要，以下说明其工作原理与替代方案：
ONBUILD 的作用机制
`ONBUILD` 不会在构建当前镜像时立即执行，而是将后续指令“注册”为触发器，当该镜像被用作其他 Dockerfile 的 `FROM` 基础镜像时，这些触发器才在子镜像构建阶段自动插入到 `FROM` 指令之后、其余指令之前执行。
典型用法（仅作示例，不推荐新建）
例如，构建一个 Node.js 基础镜像，自动处理依赖安装：
# 父镜像 Dockerfile（node-base:18-onbuild） FROM node:18-slim ONBUILD COPY package.json /app/ ONBUILD WORKDIR /app ONBUILD RUN npm ci --only=production ONBUILD COPY . /app/
子镜像只需：
# 子镜像 Dockerfile FROM node-base:18-onbuild CMD ["node", "server.js"]
构建子镜像时，四条 `ONBUILD` 指令会自动前置执行，完成依赖安装与代码复制。
为什么应避免使用 ONBUILD
- 行为不可见：子镜像 Dockerfile 中完全看不到这些操作，破坏可读性与可追溯性
- 无法控制执行时机：不能加条件判断、跳过某步或修改参数
- 缓存失效风险高：一旦父镜像更新 `ONBUILD` 触发器，所有子镜像重建都会强制重跑对应步骤
- 调试困难：错误日志中不显示 `ONBUILD` 来源，难以定位问题出自父镜像还是子镜像
推荐替代方案：显式复用 + 多阶段构建
用标准指令清晰表达意图，兼顾复用性与可控性：
- 提取公共逻辑为 shell 脚本（如
setup.sh），COPY 进镜像后显式调用 - 利用
ARG定义可变参数，配合RUN实现条件行为 - 使用多阶段构建，将构建环境与运行环境分离，通过
COPY --from=builder复用产物 - 对高频场景，封装为 Makefile 或 CI 脚本统一调用构建逻辑
不复杂但容易忽略：清晰、显式、可验证的构建过程，远比“自动魔法”更可靠。
