镜像体积每减少100MB，容器启动时间平均缩短1.2–2.5秒，CI/CD推送耗时下降约30%；多阶段构建必须分离builder（含编译工具链）和runtime（仅运行所需文件）两个阶段，优先选用python:3.12-slim并配合pip wheel预编译、--no-install-recommends及.dockerignore严格管控上下文。
直接说结论：镜像体积每减少 100MB，典型云环境下的容器启动时间平均缩短 1.2–2.5 秒，CI/CD 镜像推送耗时下降约 30%。这不是理论值，而是基于 FastAPI + PyTorch 混合服务在 Kubernetes 集群中的实测数据。
多阶段构建必须拆开 builder 和 runtime 两个阶段
很多人把多阶段当“语法糖”，其实关键在于隔离构建期和运行期的文件系统。builder 阶段需要完整编译工具链（gcc、build-essential），但 runtime 阶段连 apt 都不该存在。
- builder 阶段用
python:3.12-slim而不是python:3.12—— 少掉 400MB 基础系统冗余 - 务必用
pip wheel预编译依赖：RUN pip wheel --no-cache-dir --no-deps --wheel-dir /wheels -r requirements.txt，避免 runtime 阶段触发源码编译 - runtime 阶段只 COPY
--from=builder /wheels和应用代码，不 COPYrequirements.txt或.pyc缓存 - 别在 runtime 阶段执行
pip install—— 这会重新解压 wheel 并写入 site-packages，多出至少 20MB 重复文件
slim 镜像比 alpine 更稳，但必须配 --no-install-recommends
python:3.12-slim 是当前 Python 项目最平衡的选择。它基于 Debian，兼容绝大多数预编译 manylinux wheels；而 alpine 表面体积小，实际常因 musl libc 导致 numpy、psycopg2 等包 fallback 到源码编译，构建时间翻倍、错误难定位。
- 哪怕用了
-slim，也要显式清理 apt 缓存：RUN apt-get update && apt-get install -y --no-install-recommends build-essential && rm -rf /var/lib/apt/lists/* -
--no-install-recommends很关键 —— 它能砍掉默认安装的文档、示例、调试符号等，单次 apt 安装可省 30–80MB - 别信“slim 已经够精简” —— Debian slim 仍保留
vim、ca-certificates等非必需项，这些不会报错，但会悄悄膨胀镜像
镜像层顺序错了，缓存就全废了
Docker 缓存不是“智能识别内容”，而是严格按指令哈希逐层比对。一旦某层失效，后续所有层都重建。Python 项目最常见误操作就是把 COPY . . 放在 pip install 前面。
立即学习“Python免费学习笔记（深入）”；
- 正确顺序永远是：
COPY requirements.txt→RUN pip install→COPY . . - 如果
requirements.txt没变，pip 安装层就复用缓存；但只要改一行代码，COPY . .层失效，后面 CMD、EXPOSE 全重跑 —— 实际上它们根本不需要重跑 - 更激进的做法：用
COPY --chown=nonroot:nonroot显式指定用户，避免后续USER指令触发新层 - 别在 Dockerfile 里写
RUN pip install --upgrade pip—— 这会让 pip 版本成为缓存键一部分，每次升级都强制重建整个依赖层
.dockerignore 不只是锦上添花，而是必须项
构建上下文上传是隐形瓶颈。Docker 默认把 docker build 所在目录全部打包上传到 daemon，包括 __pycache__、.git、venv、node_modules —— 这些文件从不进入镜像，却拖慢构建启动。
- 最小必要
.dockerignore至少含：__pycache__、.git、venv、.pytest_cache、*.pyc - 如果项目混用前端，加
node_modules、dist、build - 特别注意：不要写
**/*.log，某些 Docker 版本会因 glob 性能问题卡住；用具体路径如logs/更可靠 - 验证是否生效：运行
docker build --progress=plain . | grep "Sending build context"，数字应明显小于项目总大小
最后提醒一个容易被忽略的点：PyTorch、TensorFlow 这类带 CUDA 的镜像，瘦身重点不在 Python 层，而在 CUDA 工具链。官方 pytorch/pytorch:2.9-cuda12.1 镜像里，CUDA runtime 占 3.2GB，而实际运行只需 libcudart 和 libcurand 等几个 so 文件。真要极致瘦身，得用 ldd 扫描依赖后手动提取，但这一步已经超出 Dockerfile 范畴，属于定制 base image 的事了。
