为什么同样的服务，你的镜像能到 1.2G
很多个人站长第一次用 Docker 部署自己写的小程序时，都会遇到一个诡异现象：本地代码才 300KB，可 docker images 一看，镜像 1.2GB。传到服务器上要等好几分钟，每次 push 都要重新传一遍。更糟的是，镜像里塞满了编译工具、测试依赖、缓存文件和 .git 目录——这些在生产环境里一个都不该存在，还全都是潜在的安全攻击面。
其实一个 Go 或 PHP 加 Nginx 的小服务，生产镜像完全可以做到 20MB 以内。这篇文章用一个真实的 Node 服务做例子，从 1.2GB 一路瘦到 80MB，把每一步的原理和命令都讲清楚。
先搞清楚：镜像体积是从哪冒出来的
Docker 镜像是分层的，每条 RUN、COPY、ADD 指令都会生成一个只读层，层叠加起来就是最终体积。关键点是：即使是同一个文件，先加进去再删掉，体积也不会减少，因为删除只是在上层打了个"白障"标记，被删的文件仍然留在底层里。这就是为什么很多教程里写的"记得 RUN 里 rm -rf 一下"对外层依赖是有效的，但对你 COPY 进去的东西完全无效。
先跑这条命令给现有镜像做个"体检"，找出谁在占地方：
docker history --no-trunc --human your-image:latest输出的 SIZE 列会按层列出体积，一眼就能看出是不是某个基础镜像（比如 node:20）本身就有 900MB，或者某次 apt-get 没清缓存。
想更精确地定位大文件，可以导出镜像的文件系统层来看：
docker save your-image:latest -o img.tar
mkdir layers && tar -xf img.tar -C layers
# 每一层都是一个 tar，可以逐个解包看内容
for f in layers/*/layer.tar; do echo "$f $(du -sh "$f")"; done第一步：换掉臃肿的基础镜像
最常见的问题就出在基础镜像选型上。node:20 完整版为了兼容各种场景，装了完整的 Debian、编译工具链、npm、yarn、甚至 Python，体积 900MB 起步。而官方提供的 Alpine 变体 node:20-alpine 只有 130MB 左右：
# 改前
FROM node:20
# 改后
FROM node:20-alpineAlpine 用的是 musl libc 而不是 glibc，绝大部分纯 JS 项目切换过去没问题。但要注意：如果你的项目依赖需要编译原生扩展（比如 sharp、bcrypt、canvas），Alpine 缺少 glibc，可能得装 libc6-compat 或改用 node:20-slim。slim 变体基于 Debian，去掉文档和部分工具，体积约 200MB，兼容性最好，是保守选择的甜点区。
第二步：多阶段构建，把编译工具留在"工厂"里
瘦身的核心武器是多阶段构建（multi-stage build）。思路很简单：用一个大镜像专门编译、装依赖、打包，然后把产物 COPY 到一个干净的小镜像里运行。编译器、源码、测试依赖全部留在第一阶段，不进最终镜像。
# ---------- 阶段 1：构建 ----------
FROM node:20-alpine AS builder
WORKDIR /app
# 先只复制依赖清单，利用缓存
COPY package*.json ./
RUN npm ci --omit=dev
COPY . .
RUN npm run build # 如果是纯 JS 可省略
# ---------- 阶段 2：运行 ----------
FROM node:20-alpine
WORKDIR /app
ENV NODE_ENV=production
# 只从 builder 里拿编译好的产物和依赖
COPY --from=builder /app/node_modules ./node_modules
COPY --from=builder /app/dist ./dist
COPY package*.json ./
EXPOSE 3000
CMD ["node", "dist/server.js"]注意一个关键细节：先 COPY package*.json 再 RUN npm ci。因为 Docker 对每一层做缓存，只要依赖清单没变，下次构建就直接复用这一层，不会重新下载依赖，构建速度能快几十倍。这是多阶段构建的配套最佳实践。
第三步：.dockerignore 是你最省事的优化
很多人的构建上下文里混进了 node_modules、.git、.env、日志文件，这些不仅变大，还可能把密钥泄露进镜像。在项目根目录建一个 .dockerignore：
node_modules
.git
.gitignore
.env
*.log
npm-debug.log*
coverage
.nyc_output
dist
Dockerfile
docker-compose.yml
README.md这一步零成本，但常常能省掉几百 MB 的上下文传输——尤其是有 node_modules 的时候。同时它还防止了 .env 里的数据库密码被打进镜像，安全问题一并解决。
第四步：合并 RUN 指令，清掉包管理器缓存
如果你不得不用 apt-get 或 apk 装系统包，一定要把安装和清理写在同一条 RUN 里，否则清理只作用于新层，前面的下载缓存照样留在镜像里：
# 错误：缓存留在了上一层
RUN apt-get update
RUN apt-get install -y curl
RUN rm -rf /var/lib/apt/lists/*
# 正确：一条 RUN 完成安装+清理
RUN apt-get update \
&& apt-get install -y --no-install-recommends curl \
&& rm -rf /var/lib/apt/lists/*Alpine 的对应写法是 apk add --no-cache curl，--no-cache 让 apk 不写索引缓存，一步到位。另外 --no-install-recommends 能挡掉一堆"推荐但非必需"的包，Debian 系里这常常能砍掉一半体积。
第五步：定期清理悬空镜像和构建缓存
瘦身做完，别忘了清理历史垃圾。<none>:<none> 的悬空镜像（dangling images）是构建过程中被新版本顶掉的旧层，日积月累很占磁盘。一条命令搞定：
docker system prune -a # 清理所有未使用的镜像、容器、网络
docker builder prune -a # 单独清理 BuildKit 构建缓存在执行前先用 docker system df 看看能回收多少，避免误删正在用的东西。想更精细可以用 docker image prune --filter "until=168h" 只删一周前的。
结果对比与验证
走完上面五步，一个典型的 Node + 前端构建项目，镜像从 1.2GB 降到 80MB 左右是常态。验证瘦身效果：
docker images your-app
# REPOSITORY TAG SIZE
# your-app latest 82.4MB
# 顺便确认下有没有把敏感文件打进去
docker run --rm --entrypoint sh your-app:latest -c "ls -la /app | head -20"最后提醒一句：瘦身不是目的，可维护和安全才是。Alpine 虽小，但 musl 兼容性问题会让你在半夜 debug；多阶段构建虽好，但两个阶段基础镜像要尽量对齐（都 Alpine 或都 Debian），否则 COPY 出来的二进制可能跑不起来。先保证跑得对，再追求跑得小，这个顺序别搞反。