我还记得，有一次一个初级开发者对比了我们为同一个 Node.js 应用构建的 Docker 镜像后，这样问我。

我们用了相同的基础镜像、相同的依赖、相同的应用。但我的构建结果更轻、更快、也更容易调试。

“秘诀是什么？”

没有魔法。

只有经验。

在本文中，我将展示 5 个真实可用的 Dockerfile 技巧——资深开发者每天都在用的技巧，这些技巧能节省时间、减少膨胀，并让容器更适合生产环境。

每一条都会详细解释，并附带真实可运行的示例。

技巧 1：最小化层（Minimize Layers）

假设你要在基于 Debian 的镜像里安装一些工具：

# Junior way

RUN apt-get updateRUN 

apt-get install -y curlRUN 

apt-get clean

每条 RUN 指令都会新建一个镜像层。这不仅让镜像变大，还会拖慢构建速度和缓存利用率。

资深开发者会这样写：

# Senior way

RUN apt-get update && \   

 apt-get install -y curl && \  

  apt-get clean && \   

 rm -rf /var/lib/apt/lists/*

为什么重要：

• 把命令合并到一条 RUN 里，能减少层数。

• rm -rf /var/lib/apt/lists/* 会清除临时包元数据——省下几 MB。

• && 保证只要有一条命令失败，构建会立刻停止，避免留下不完整状态。

动手试试：

• 分别用两种写法执行 docker build，再 docker images 对比大小。

• 你会发现资深版本明显更小、更干净。

技巧 2：使用 .dockerignore

你不会把 .git 文件夹上传到生产环境——那为什么要把它放进 Docker 构建上下文？

默认情况下，所有文件都会被送进 Docker 守护进程，除非你显式忽略。

问题所在：

# Without .dockerignore

COPY . .

如果本地目录里有：

• node_modules/

• .git/

• logs/

• test data…

它们全都会被复制进去——既拖慢构建，又撑爆镜像。

解决办法：

在项目根目录新建一个名为 .dockerignore 的文件：

node_modules

.git*

.log

Dockerfile

现在只有相关文件会被打包。

高级提示：

执行下面这条命令，看看究竟哪些文件被送进了 Docker：

docker build . --no-cache --progress=plain

你会震惊于没有 .dockerignore 时有多少“垃圾”被复制进去。

技巧 3：多阶段构建，打造干净的生产镜像

这是 Docker 最强大、却常被初级开发者忽略的功能之一。

场景：

• 你在构建 React 应用。

• 你需要 node 来构建，但运行时并不需要它。

初级 Dockerfile：

FROM node:18

WORKDIR /app

COPY . .

RUN npm install && npm run build

CMD ["npx", "serve", "build"]

最终镜像里残留了所有构建工具——无谓的膨胀。

资深 Dockerfile（多阶段）：

# Stage 1: Builder

FROM node:18 as builder

WORKDIR /app

COPY . .

RUN npm install && npm run build

# Stage 2: Production

FROM nginx:alpine

COPY --from=builder /app/build /usr/share/nginx/html

好处：

• 最终镜像体积极小。

• 没有 node_modules、没有源码、没有构建工具。

• 更安全、更快速。

多阶段构建尤其适用于：

• 前端应用

• Java 应用（Maven/Gradle 构建）

• Go 应用（静态二进制输出）

构建并运行：

docker build -t myapp .

docker run -p 80:80 myapp

你的应用将由 nginx 提供，全程看不到 node。

技巧 4：锁定镜像版本（Pin Image Versions）

这一点常常导致生产环境噩梦。

危险写法：

FROM python:latest

今天能跑，可明天 latest 更新后呢？

构建可能失败，应用可能崩溃。

稳妥写法：

FROM python:3.11.6-slim

务必锁定到：

• 具体版本号

• 尽可能用精简变体（slim、alpine）

为什么重要：

docker pull python:latest

docker pull python:3.11.6-slim

对比体积——再想想 CI/CD 时的可靠性。

注意：

别盲目给所有语言都用 alpine——某些库因 musl 兼容性问题会编译失败。务必先测试。

技巧 5：用 HEALTHCHECK 给容器加上自愈能力

资深工程师的标志之一，就是让系统能在故障时自动恢复。

Docker 的 HEALTHCHECK 正好能做到。

初级开发者常忽略：

大多数初级 Dockerfile 只是简单启动应用：

CMD ["node", "server.js"]

可一旦容器跑起来，就没人知道应用是否还活着。

• 应用假死怎么办？

• 抛出异常但进程没退怎么办？

• 启动成功，几分钟后又崩了怎么办？

Docker 会愉快地显示容器“运行中”，即使里面的应用已经坏了。

资深 Dockerfile：

资深开发者会定义 HEALTHCHECK，定期检查应用是否仍然正常。

HEALTHCHECK --interval=30s --timeout=10s \  

CMD curl -f http://localhost:8080/health || exit 1

每 30 秒执行一次 curl：

• 返回 200 → Docker 认为容器健康。

• 失败 → Docker 标记为不健康。

参数拆解：

• --interval=30s：每 30 秒检查一次。

• --timeout=10s：超过 10 秒没响应就判失败。

• --start-period=10s：给应用 10 秒启动时间，期间不计入失败。

• --retries=3：连续 3 次失败才标记为不健康。

• CMD：真正的健康检查命令——这里访问 /health。

实际项目中的价值：

• 开发阶段：及早发现启动时的问题。

• 预发/生产：Docker Swarm、Kubernetes、ECS 会自动重启被标为不健康的容器。

• CI/CD：在运行测试或发布前，更有信心容器真的启动成功了。

如果应用没有 /health 接口，也可以用其他方式：

• 检查某个文件是否存在

• 看端口有没有监听

• 甚至测数据库连不连得通

附加小技巧：进程级健康检查

如果你的应用没 HTTP 接口——比如 CLI 工具、TCP 服务、后台worker——照样能用 HEALTHCHECK，只要盯着进程在不在。

可以尝试：

HEALTHCHECK --interval=30s --timeout=10s \  

CMD pgrep myserver || exit 1

pgrep myserver 查找名为 myserver 的进程。

找到 → 退出码 0，容器健康。

找不到 → 非 0，容器不健康。

适用于：

• 非 HTTP 服务

• 纯二进制或脚本

• 遗留守护进程

真实示例：

Java 应用这样启动：

CMD ["java", "-jar", "myapp.jar"]

健康检查可写成：

HEALTHCHECK CMD pgrep java || exit 1

简单有效，确保主进程没悄悄崩溃。

最后的话

这些 Dockerfile 技巧不是什么高深火箭科学，而是让容器更快、更小、更安全的实用习惯。

快速回顾：

• 合并 RUN 命令，减少镜像层。

• 用 .dockerignore 提速构建。

• 多阶段构建，生成精简生产镜像。

• 锁定版本，避免未来惊吓。

• 加入 HEALTHCHECK，实现监控与自愈。

下次用 Docker 时，挑一两招试试——看看你的配置能干净多少。