技能介绍

为什么需要这份清单

镜像体积失控、构建越来越慢、缓存频繁失效，是容器化项目里最常见的三类慢性损耗。更隐蔽的风险在于：构建上下文里混入了 .git 与 .env，生产镜像里躺着完整的编译工具链，容器进程以 root 身份运行——这些并不会让 CI 立刻失败，却会在后续的漏洞扫描、扩容和安全审计中集中爆发。这份技能的价值不是提供一个新工具，而是把 Dockerfile 与 docker-compose.yml 里容易踩的坑整理成一套可逐条对照执行的约定。

核心要点

1. 多阶段构建，把构建环境与运行环境彻底分离

依赖安装与代码编译放在同一个阶段是反模式。多阶段构建要求把依赖安装、构建、运行拆成独立阶段，最终镜像只保留运行时产物，编译工具链和中间文件不进入交付物。

2. 镜像层优化，让缓存真正发挥作用

合并多条 RUN 命令，减少层数；
按变更频率从低到高排列指令，把不常变动的操作（如安装系统依赖）放在前面，频繁变化的源码拷贝放在后面，这样日常改动不会让整段缓存失效。

3. .dockerignore 不可省略

始终包含 .dockerignore，用于减小构建上下文体积，并防止 .env 等敏感文件意外泄漏进镜像。

4. 明确避开的反模式

容器内以 root 身份运行进程；
在能用 COPY 的场景下使用 ADD（后者会自动解压 tar 包、拉取 URL，行为有隐式副作用）；
在 Dockerfile 里用 ENV 存放密钥；
基础镜像使用 node:latest 这类未固定版本；
生产镜像中安装开发依赖。

5. 逐项核对的检查清单

技能给出了一份可打勾的 Checklist，覆盖非 root 用户与 USER 指令、基础镜像版本固定（如 node:22-alpine）、HEALTHCHECK 定义、docker-compose 中使用 depends_on 并配置健康条件、密钥通过构建 secret 或运行时挂载传递等。

适用边界与注意点

这套清单面向的是以 Dockerfile 为主要交付载体的常规服务镜像，偏工程约束而非运行时治理。它不替代镜像扫描、镜像签名和漏洞告警流程，也不覆盖多架构构建（如 arm64/amd64）、镜像仓库分发与部署编排等更上层的话题。depends_on 的健康条件只能控制启动顺序，不能替代应用层的重试与幂等设计；此外，多阶段构建带来的收益在依赖安装开销远大于编译开销的场景里会比较有限，需要结合实际构建时间评估。