核心是复用已存在只读层以跳过解压挂载：需确保基础镜像层物理共享、避免破坏性构建行为、预加载高频层、精简层数、启用Docker 27+轻量启动模式。
核心思路是让容器启动时跳过耗时的镜像解压与挂载环节，直接复用已存在的只读层——分层复用本身不加速启动，但它是所有启动加速技术的前提和基础。
确保基础镜像层真正被共享
不同应用若基于同一基础镜像（如 alpine:3.19 或 debian:bookworm-slim），它们的底层只读层在 /var/lib/docker/overlay2/ 中应物理共存。Docker 默认支持该复用，但需避免以下破坏行为：
- 每次构建都使用随机标签（如
myapp:$(date +%s)），导致 Docker 无法识别语义相同的基础层 - 在 Dockerfile 开头写
FROM ubuntu:22.04@sha256:xxx但每次拉取的 digest 不一致（例如因镜像被覆盖更新） - 混用不同 registry 的同名镜像（如
registry.example.com/alpine:3.19和docker.io/alpine:3.19），其 layer digest 实际不同
主动预加载高频层到本地存储
冷启动慢，常因首次启动时要从网络下载并解压 layer。可在设备初始化阶段就完成这一步：
- 对关键业务镜像执行
docker pull my-adcu-app:2.4.1，确保所有 layer 已落盘且未被 GC 清理 - 配合
docker save | tar -C /var/lib/docker/overlay2/ -x（需 root）将 layer 直接解压进 overlay2 工作目录，绕过运行时解压逻辑 - 在车载或边缘设备上，可将预加载步骤固化进 initramfs 或 OTA 升级包，实现“开机即就绪”
精简层数 + 合并变更，减少挂载开销
OverlayFS 挂载 N 层只读层的时间并非线性，而是随层数增长呈次线性上升；尤其在 eMMC 或 SD 卡上，元数据操作延迟明显：
- 把多个
RUN指令合并为一条（如RUN apt-get update && apt-get install -y curl jq && rm -rf /var/lib/apt/lists/*），避免生成冗余中间层 - 禁用构建缓存无关的指令（如
RUN date > /build-timestamp），防止某一层失效导致后续全量重建 - 多阶段构建中，最终镜像应仅含 1～2 个 layer：1 个基础运行时（如 alpine）、1 个 COPY 进去的二进制文件
启用轻量启动模式（Docker 27+）
Docker 27（Nimbus）引入 --light 标志，本质是利用分层复用能力做更激进的优化：
- 自动跳过未修改层的 inode 重扫描，依赖 eBPF 过滤器快速确认 layer 状态
- 多个同镜像容器共享只读代码段与 config.json 的 mmap 映射，避免重复解析
- 结合 cgroups v2 的
memory.low和io.weight=10，抑制非关键页缓存抢占，保障 namespace 初始化路径低延迟
