核心目标是让配置错误在镜像构建时就失败，而不是等到容器运行才暴露问题；需在Dockerfile中用RUN执行nginx -t，确保配置已复制且路径一致，失败则构建中断。
在 Docker 构建阶段强制执行 nginx -t，核心目标是：**让配置错误在镜像构建时就失败，而不是等到容器运行才暴露问题**。这属于“左移验证”，能避免无效镜像被推送到仓库或部署到生产环境。
为什么不能只靠运行时检查
很多人习惯在 docker run 后手动执行 nginx -t，或者写个启动脚本做校验。但这属于事后补救——镜像已经构建成功、甚至可能已发布。一旦配置语法错误（比如少了个分号、括号不匹配），容器会直接退出，运维要排查日志、回滚版本，效率低且风险高。构建时拦截才是真可靠。
推荐做法：在 Dockerfile 中用 RUN 执行 nginx -t
关键点在于：必须确保 Nginx 配置文件已复制进镜像，且路径与运行时一致。典型流程如下：
- 先
COPY自定义配置（如nginx.conf、conf.d/*.conf）到镜像内对应位置（通常是/etc/nginx/） - 紧接着用
RUN nginx -t做语法校验 - 校验失败时，Docker 构建自动中断，返回非零退出码
示例片段：
COPY nginx.conf /etc/nginx/nginx.conf COPY conf.d/default.conf /etc/nginx/conf.d/default.conf RUN nginx -t
注意：nginx -t 默认读取 /etc/nginx/nginx.conf，所以务必保证该路径下的配置完整可用。如果用了非标路径（比如 -c /app/my.conf），RUN 命令里也要显式指定。
进阶技巧：避免因默认配置干扰而误报
官方 nginx:alpine 镜像自带默认配置，若你只覆盖部分文件（如只改 conf.d/default.conf），但没清理 sites-enabled 下的软链或旧 default 文件，nginx -t 可能因加载冲突配置而失败。
稳妥做法是构建时主动清理或覆盖全部相关配置：
- 用
RUN rm -rf /etc/nginx/conf.d/*.conf /etc/nginx/sites-enabled/*清空默认项 - 再
COPY自己的配置集 - 最后
RUN nginx -t
这样可排除干扰，让校验结果真正反映你的配置质量。
补充说明：不建议用 ENTRYPOINT 或 CMD 拦截
有人试图把 nginx -t && exec nginx -g "daemon off;" 写进 ENTRYPOINT，这看似可行，实则无效——构建阶段不会执行 ENTRYPOINT。它只在容器启动时运行，无法阻止错误镜像生成。真正的拦截点只能是 RUN 指令。
