dockerfile 安全优化核心是明确镜像封装边界：选 slim/alpine 基础镜像并固定小版本；copy 优先于 add；run 合并命令并清理缓存；早设 workdir、后设 user、cmd 用 json 格式。
绝大多数 Dockerfile 写得不安全、不可复现、体积臃肿，根本原因不是语法不会，而是没想清楚“镜像到底该封装什么”。
FROM 选哪个基础镜像才不算埋雷
别直接写 FROM ubuntu:latest 或 FROM python:latest——latest 标签不固定，CI 构建可能突然失败；Ubuntu 镜像默认带大量非运行必需的包（如 man、vim），徒增体积和攻击面。
- 优先用
slim或alpine变体：python:3.12-slim（Debian 基础，兼容性好）或python:3.12-alpine（更小，但注意 glibc vs musl 兼容性） - 明确指定小版本号，例如
node:20.11.1，避免 patch 版本漂移导致行为差异 - 生产环境禁用
scratch（空镜像）直连，除非你真清楚自己在做什么——没有 shell、没有ls、没有调试能力
COPY 和 ADD 到底该用谁、什么时候用
ADD 看似功能多（支持自动解压、远程 URL），但实际场景中几乎不需要它；滥用 ADD 会破坏构建缓存、引入不可控行为（比如自动解压 tar 包可能覆盖已有文件）。
- 一律用
COPY：只做“把宿主机文件/目录复制进镜像”这一件事，语义清晰、可预测 -
ADD唯一合理场景：从远程 URL 下载并解压归档（如ADD https://example.com/app.tar.gz /app/），但更推荐用curl | tar分步控制 -
COPY --chown=user:group要早用：避免后续RUN chown多一层镜像层，也防止权限错误导致容器启动失败
RUN 指令怎么写才能少一层、少一个漏洞
每个 RUN 指令都会生成一个新镜像层，层越多，镜像越臃肿，缓存失效风险越高；同时，把安装、清理拆成两行 RUN，中间层会残留缓存包，白给攻击面。
- 合并操作：用
&&连接命令，末尾加&& rm -rf /var/lib/apt/lists/*（Debian/Ubuntu）或&& apk del .build-deps（Alpine）清理临时文件 - 避免
RUN pip install直接装全量依赖：先COPY requirements.txt，再RUN pip install -r requirements.txt，这样只要requirements.txt不变，pip 安装步骤就能命中缓存 - 禁止在
RUN中写密码、密钥、token——哪怕只是临时变量，也会留在某一层里，用docker history就能看见
容器启动失败？先盯紧 WORKDIR、USER、CMD 这三个指令
很多“本地跑得好，容器里起不来”的问题，根源不在代码，而在这三个看似简单的指令配置错位。
-
WORKDIR必须是绝对路径，且最好在COPY之前就设好，否则相对路径容易出错；它还决定了CMD和ENTRYPOINT的执行上下文 -
USER要在最后设（即所有需要 root 权限的操作完成后），且必须是已存在的用户（adduser或useradd创建），不能只写USER 1001却没建对应用户 -
CMD推荐用 JSON 数组格式：CMD ["python", "app.py"]；避免CMD python app.py（shell 形式）——后者会绕过 ENTRYPOINT，且无法接收信号（如 SIGTERM）
最常被忽略的一点：Dockerfile 不是 Shell 脚本，它的每一行都是独立执行环境；上一行 export PATH=... 对下一行完全无效。所有路径、环境、权限，都得显式声明、显式传递。
