写好 Dockerfile 的核心是理解每条指令如何生成镜像层：RUN、COPY、ADD 每行新增一层，层数多导致体积大、构建慢、缓存易失效；应合并 RUN 命令、安装后立即清理缓存、用 .dockerignore 精简 COPY、优选 slim/alpine 基础镜像并注意 musl/glibc 兼容性。
写好 dockerfile 不是堆指令，而是理清构建逻辑、控制层叠粒度、规避隐性陷阱。很多问题不是语法错，而是对“每行指令如何影响镜像结构”缺乏感知。
镜像层爆炸：为什么越改越大？
每条 RUN、COPY、ADD 都新增一层只读镜像层。层数多 → 镜像体积大、构建慢、缓存失效频繁。
- 避免拆成多条 RUN：比如分三行安装依赖、清理缓存、复制配置，会生成三层；应合并为一行并用
&&连接 - 安装后立即清理：apt/debian 系用
rm -rf /var/lib/apt/lists/*，apk/alpine 系用--no-cache - COPY 尽量精简：不要 COPY 整个项目目录，用 .dockerignore 排除 node_modules、.git、logs 等无用文件
基础镜像选错：小题大做or踩坑不自知
FROM 不只是起点，它决定了安全基线、libc 兼容性、体积下限和调试能力。
- 优先选语言官方 slim/alpine 镜像（如
python:3.12-slim、node:20-alpine），别直接用ubuntu:latest - 注意 musl vs glibc：alpine 默认用 musl libc，某些预编译二进制（如某些 Rust/C++ 工具）会报
not found错误 - 生产环境慎用
scratch或 distroless：零调试能力，适合已验证稳定的单二进制服务（如 Go 编译产物）
构建失败难定位：日志里藏了关键线索
Dockerfile 执行是线性过程，某一步失败，后续全跳过。错误往往卡在中间，但提示信息可能藏在上几行。
- 看完整构建输出，尤其关注最后一段红色错误前的最后一条成功指令（常是缓存命中点）
- 本地复现时加
--no-cache：排除缓存干扰，确认是否真因指令逻辑出错 - 临时插入调试指令：比如在可疑步骤前加
RUN ls -la / && cat /etc/os-release，快速确认上下文 - 网络类失败（如 apt install 卡住）：在 RUN 中加入重试逻辑，例如用
for i in {1..3}; do apt-get update && break || sleep 5; done
启动就退出：CMD/ENTRYPOINT 配置失当
容器生命周期由主进程决定。CMD/ENTRYPOINT 写错，会导致进程秒退，容器状态变为 Exited(0) 或 Exited(1)。
- CMD 是默认命令，可被
docker run后参数覆盖；ENTRYPOINT 是固定入口，更适合封装服务 - 避免使用 shell 形式 CMD ["sh", "-c", "xxx"] 启动后台服务（如 nginx -g "daemon off;" 必须显式写，否则 sh 退出容器即关）
- 确保主进程前台运行：Python 用
python -u app.py，Node 用node --no-deprecation server.js，避免被信号终止 - 检查 WORKDIR 是否存在、权限是否正确，尤其是 COPY 后文件路径与 CMD 中执行路径是否匹配
