Linux Docker 镜像构建优化技巧

docker build 慢的根本原因是 dockerfile 编写不当导致层缓存失效；应分离依赖与代码拷贝、拆分 run 指令、正确使用多阶段构建、配置 .dockerignore、谨慎处理 arg 类型与敏感信息，兼顾缓存、兼容与安全。

为什么 Docker build 慢得离谱？关键在层缓存失效

根本原因不是 CPU 或磁盘慢，而是你写的 Dockerfile 没让 Docker 复用已有镜像层。只要某一层的构建指令（比如 copy . /app）内容变了，它和后面所有层都会重新执行——哪怕只是改了一行日志打印。

• 把 apt update && apt install 和 COPY . /app 写在一起，每次代码变更都会重装全部依赖
• 用 COPY package.json /app/ && npm install 分开写，才能让依赖安装层在 package.json 不变时命中缓存
• RUN 指令越长、越混杂，缓存粒度越粗；拆成多个小 RUN 更利于复用

多阶段构建真能减小镜像体积？但别乱删 /usr/lib

多阶段构建确实能甩掉编译工具链，但常见错误是：第二阶段用 FROM alpine:latest，却硬塞进第一阶段编译出的 glibc 二进制——直接运行失败。

• 第一阶段用 golang:1.22 编译，第二阶段必须匹配运行时环境：glibc 程序选 debian:slim，musl 程序才用 alpine
• 别手动 RUN rm -rf /usr/lib/debug：现代基础镜像（如 debian:slim）已精简，乱删可能破坏动态链接
• 检查最终镜像实际体积用 docker image ls -s，别只信 du -sh 容器内路径

.dockerignore 不只是加速，它决定构建是否可重现

漏写 .dockerignore 会导致本地开发文件（node_modules、.git、__pycache__）被 COPY 进镜像，不仅拖慢构建，还污染镜像内容哈希——CI 中同一 Dockerfile 可能生成不同镜像 ID。

• 必加项：.git、node_modules、__pycache__、.DS_Store、*.log
• 别写 **/node_modules：Docker 不支持 glob 递归语法，只认 node_modules 或 src/node_modules
• 测试是否生效：临时在 Dockerfile 加 RUN find / -name node_modules 2>/dev/NULL || true

构建参数（--build-arg）传错类型？ARG 默认全是字符串

ARG 声明的变量在构建时全按字符串处理，哪怕你传了 --build-arg DEBUG=true，在 shell 判断里写 [ $DEBUG = true ] 是对的，但写 if [ $DEBUG ]; then 就会永远为真——因为空字符串和非空字符串都是“有值”。

• 布尔判断务必显式比对：if [ "$DEBUG" = "true" ];，别依赖非空即真
• 数字参数要转义：RUN echo "limit: ${MAX_CONN:-10}" > /etc/app.conf，否则未传参时会留空变量名
• 敏感值（密码、Token）别用 ARG：它会留在镜像历史里，用 docker build --secret + RUN --mount=type=secret 替代

构建优化的复杂点不在技巧多寡，而在每一步都得同时兼顾缓存行为、运行时兼容、安全边界这三层约束——少盯住一个，就可能在 CI 或生产环境突然冒出来。