应选用轻量基础镜像如node:16-alpine或python:3.9-slim，配合多阶段构建、合并RUN指令即时清理、配置.dockeringore文件，可显著减小镜像体积。
选错基础镜像，1GB 就没了
很多人的镜像一构建就超 1GB，根源往往在第一行：FROM node:16 或 FROM python:3.9。这类官方完整镜像自带 shell、包管理器、文档、调试工具，但生产环境根本用不上。比如 node:16 约 300MB，node:16-alpine 仅约 5MB；python:3.9 超 1.2GB，python:3.9-slim 约 100MB，python:3.9-alpine 还能压到 50MB 左右。
注意：Alpine 使用 musl libc，某些 C 扩展（如 numpy、psycopg2）需重新编译或换用 slim 镜像；Node.js 应用若依赖 node-gyp 构建的原生模块，也建议先试 slim 再切 alpine。
不写多阶段构建，等于把整个开发机打包进容器
传统写法把 npm install、npm run build、源码、node_modules 全塞进一个镜像，结果镜像里既有编译器又有调试日志，体积翻倍还带安全风险。多阶段构建才是解法：
- 构建阶段用完整镜像（如
node:16）装依赖、跑构建 - 运行阶段用极简镜像（如
node:16-alpine），只COPY --from=builder编译产物和必要依赖 - 关键点：别漏掉
RUN npm ci --production或--only=production，否则devDependencies会偷偷混进去
常见错误：在运行阶段又执行 RUN npm install —— 这会让 node_modules 重复安装，且可能拉下开发时才需要的包。
RUN 指令乱堆叠，层数爆炸还清不干净
Docker 每个 RUN 指令都生成一层，哪怕只是 apt update 后没清理缓存，那一层就永久存在。更糟的是，如果写成：
RUN apt-get update RUN apt-get install -y curl RUN rm -rf /var/lib/apt/lists/*
前两层的缓存文件根本删不掉，第三层只清了自己这一层的缓存目录。
正确做法是合并 + 即时清理：
RUN apt-get update && \
apt-get install -y curl && \
rm -rf /var/lib/apt/lists/*
同理，npm install 后别忘了 && npm prune --production（删 dev 依赖）；Go 构建后加 && strip myapp 可进一步减小二进制体积。
.dockerignore 是被严重低估的“隐形瘦身开关”
很多人以为只靠 Dockerfile 就能控大小，其实构建上下文（build context）传给 daemon 的文件，早就在 COPY 前决定了体积上限。默认 . 会把 .git、node_modules、dist（如果已存在）、*.log 全传进去——即使 Dockerfile 里没 COPY 它们，也会拖慢构建速度，还可能意外触发缓存失效。
务必配好 .dockerignore：
.git node_modules npm-debug.log dist *.md *.txt Dockerfile .dockerignore
特别注意：不要忽略 package-lock.json 或 yarn.lock —— 它们必须存在才能保证 npm ci 精确还原依赖。
真正难的不是知道这些技巧，而是每次写 Dockerfile 时都记得检查：基础镜像是否最小可用？构建和运行是否彻底分离？每一层是否在创建的同时就清理了中间产物？.dockerignore 是否覆盖了所有本地冗余？这些动作不难，但漏掉任意一个，100MB 就白扔了。
