缓存命中率提升至89%的关键是优化dockerfile指令顺序：将变动少的指令（如copy requirements.txt、run pip install --no-cache-dir）前置，变动频繁的（如copy . /app）后置，并合并run命令、启用多阶段构建、选用精简基础镜像。
镜像分层不是技术包袱，而是可调度的构建资产。真正拖慢构建的，从来不是层数本身，而是层与层之间不该有的耦合和冗余。
把缓存命中率从32%拉到89%的关键操作
缓存失效往往藏在看似合理的指令顺序里。核心原则是：让变动频率低的指令尽量靠前，变动频繁的尽量靠后。
- COPY . /app 不要放在 RUN pip install 之前——源码一改，所有后续层全重跑；应先 COPY requirements.txt，再 RUN pip install，最后 COPY 其余代码
- 避免未锁定版本的包安装，例如 RUN apt-get install nginx 改为 RUN apt-get install nginx=1.20.1-1ubuntu1~22.04.1 && apt-get clean
- pip 安装务必加 --no-cache-dir，RUN pip install -r requirements.txt --no-cache-dir；同时结尾补上 rm -rf ~/.cache/pip
- 用 && 连写多个命令，而不是拆成多条 RUN 指令——每条 RUN 都是一层，合并能减少层数、提升复用粒度
多阶段构建不是“加个 FROM”就完事
命名阶段（AS builder）和跨阶段复制（--from=builder）只是基础。高阶用法在于精准控制产物传递边界。
- 构建阶段只保留最终二进制或静态资源，不保留 node_modules、go.mod、.git 等中间产物
- 运行阶段不继承构建阶段的环境变量、用户权限、shell 配置，避免隐式依赖泄露
- 可设中间验证阶段：比如在 builder 后加一个 test 阶段，用 alpine+curl 验证编译产物是否可执行，失败则整个构建中止
- 对大型前端项目，可拆出 build 和 postbuild 两个构建子阶段：前者生成 dist，后者压缩、替换 CDN 地址、注入指纹，再交付给 nginx 阶段
用 Dive 工具揪出“看不见的膨胀”
镜像体积大，未必是文件多，很可能是同一份文件在不同层反复出现，或删了但没真正消失。
- 运行 dive myapp:latest，左侧看层列表，右侧看文件树，重点关注标红的“deleted”文件——它们只是被白障（.wh.*）屏蔽，并未释放空间
- 观察“Layer Efficiency”得分，低于 85% 就值得深挖：点开某一层，看它新增了什么、删除了什么、修改了什么
- 常见陷阱：RUN yum install && yum clean all 分两行写，clean 操作会新建一层，但上层的 /var/cache/yum 仍残留；必须写在同一 RUN 中才能真正清理
- 配合 docker history --no-trunc myapp:latest 查看每层对应指令，再对照 Dive 的文件变化，快速定位冗余来源
基础镜像选型直接影响安全与启动速度
别再无脑用 ubuntu:latest。轻量不是妥协，而是收敛攻击面的主动设计。
- Go/Java/C++ 类静态编译应用，优先考虑 distroless 镜像，如 gcr.io/distroless/base，仅含 ca-certificates 和最小运行时，大小约 2MB
- 需调试工具（curl、sh、ps）的场景，用 alpine:3.20，但注意 musl libc 兼容性，某些 C 扩展可能报错
- Python 应用推荐 python:3.11-slim-bullseye，比 latest 小 40%，比 full 少 70% 无关包，且基于 Debian 稳定版，兼容性好
- 所有基础镜像必须带具体标签，禁止使用 :latest —— 它不可重现、不可审计、无法回滚
