容器从 created 变为 running 的延迟主因是启动初始化阻塞，需精简 entrypoint/cmd 同步操作、优化 volume 挂载、减小镜像体积、合理配置 healthcheck 及调优 dockerd 存储驱动与 ulimit。
容器从 Created 状态变为 Running 的延迟，通常不是 Docker 本身的问题，而是启动过程中的初始化环节拖慢了节奏。关键在于识别并精简容器启动时的阻塞点。
检查 ENTRYPOINT/CMD 是否存在同步阻塞操作
很多应用镜像在启动脚本中执行耗时操作（如配置生成、依赖下载、健康检查等待），导致容器卡在“创建完成但未就绪”阶段。Docker 将其标记为 Created，直到主进程真正 exec 并持续运行才转为 Running。
- 用
docker inspect <container> | jq '.State.Status'</container>确认状态变化时机 - 临时改用
sh -c "sleep 10"替换原有 CMD，验证是否仍卡住——若秒级启动，则问题出在原启动逻辑 - 将长耗时初始化（如证书拉取、DB 连接池预热）改为异步或延迟执行，主进程尽快
exec到实际服务二进制
避免使用 volume 挂载时的权限/初始化等待
挂载宿主机目录或命名卷时，若目标路径不存在、权限不足，或使用了需要初始化的驱动（如 local-persist），Docker daemon 可能阻塞容器启动流程。
- 确认挂载路径在宿主机已存在且权限匹配（尤其使用
--user或非 root 用户时） - 对只读挂载加
:ro显式声明，减少运行时校验开销 - 避免在容器启动时通过 volume 挂载执行脚本或初始化数据——改用构建阶段
COPY或 init 容器预处理
精简镜像层与 HEALTHCHECK 干扰
虽然 HEALTHCHECK 不影响容器状态切换，但部分编排工具（如 Docker Compose v2.20+）默认等待健康检查通过才认为服务“就绪”，造成主观上的“启动慢”错觉；同时臃肿镜像会延长 docker run 的元数据准备时间。
- 确认你观察的是
docker ps中的Status字段（真实状态），而非应用就绪状态 - 移除镜像中无用的安装包、缓存和调试工具（多阶段构建 +
apt clean/apk cache del） - 若必须用 HEALTHCHECK，设置合理
--start-period，避免刚启动就触发失败重试
启用 dockerd 的 live-restore 和优化存储驱动
在高负载或使用 overlay2 配合大量小文件的场景下，容器启动时的元数据加载、inode 分配可能成为瓶颈。
- 确保
/etc/docker/daemon.json启用"live-restore": true，避免 daemon 重启导致容器状态重建延迟 - 使用
overlay2（推荐）而非aufs或devicemapper，并在 SSD 上部署 Docker 根目录 - 限制容器启动并发数（
--default-ulimit nofile=1024:1024）可减少资源争抢，尤其在 CI/CD 批量拉起场景下有效
