镜像体积由每层实际写入内容决定，而非指令条数；优化核心是减少无效层、避免残留、合并变更，重点精简run/copy/add指令，结合多阶段构建与轻量基础镜像实现极致瘦身。
镜像体积不是由指令条数决定的，而是由每一层实际写入的文件内容决定的。精简指令的核心，是减少无效层、避免残留、合并变更，让每层只保留运行必需的内容。
只对 RUN/COPY/ADD 指令做层合并
Docker 中只有 RUN、COPY、ADD 三条指令会生成新的只读层；LABEL、EXPOSE、ENV 等不增加体积。所以优化重点必须落在这三类指令上：
- RUN 指令要“装-用-删”一步到位：比如安装编译工具后立即编译并清理缓存，不能拆成多条 RUN。否则中间层残留 apt 缓存、.deb 包等，删除动作只在新层打“白名单”，旧层数据仍在。
- COPY 尽量精准：不要 COPY 整个源码目录再删掉 .git 或 node_modules，而应先在构建上下文里过滤，或用 .dockerignore 排除无关文件。
- 避免 ADD 自动解压行为引入冗余：用 COPY + 显式 tar -xzf 更可控，防止 ADD 把压缩包元信息或临时解压路径带进层。
用多阶段构建跳过构建层
构建工具链（如 gcc、maven、node_modules）完全不需要出现在最终镜像中。多阶段构建能彻底切断它们与运行环境的关联：
OpenClaw Docker Setup
下载
在 Linux 上通过 Docker 运行 OpenClaw，并使用 Tailscale 实现远程访问。⚠️ 涉及 sudo、Docker、Tailscale和凭证挂载——请先查阅安全章节...
- 第一阶段用完整镜像（如 node:18、golang:1.21）完成编译或打包；
- 第二阶段切换轻量基础镜像（如 alpine:latest、distroless），仅 COPY 第一阶段产出的二进制或静态资源；
- 最终镜像不包含任何构建依赖，体积常缩小 80% 以上。
选对基础镜像，从源头控制层大小
基础层是所有后续层的底座，它的体积和内容直接影响上限：
- 优先选用 alpine 或 distroless 镜像替代 ubuntu/debian：前者通常 5–15MB，后者可低至 2MB，不含包管理器和 shell；
- 避免在 RUN 中反复 apt-get update && install，改用官方精简版镜像（如 python:3.11-slim）已预装常用依赖；
- 注意 slim 镜像仍含 apt，distroless 则几乎零工具——选型需匹配调试与安全需求。
利用分层缓存但不被缓存误导
缓存提升构建速度，但容易让人忽略“层是否真的干净”：
- 某层 RUN apt-get install nginx 后没清理 /var/lib/apt/lists，即使下一层 RUN rm -rf /var/lib/apt/lists，该目录仍存在于前一层中；
- 查看层体积可用 docker history
，重点关注 SIZE 列，识别哪几层异常臃肿； - 修改 Dockerfile 时，尽量把易变指令（如 COPY 源码）放在靠后位置，让前面稳定层（如安装系统依赖）能复用缓存。
