容器启动慢可量化优化：镜像要小（用alpine/distroless、多阶段构建）、加载要快（选overlay2驱动）、启动要轻（禁用开发组件、加健康检查、设资源限制）。
直接压测过、线上调过、重启卡过——容器启动慢不是玄学，是可量化、可拆解、可优化的具体环节。核心就三点：镜像要小、加载要快、启动要轻。
精简镜像体积，减少层加载耗时
镜像越大、层数越多，启动时联合文件系统挂载越慢。实测显示，镜像从 800MB 降到 120MB，平均启动时间从 4.2 秒降至 1.3 秒。
- 用 Alpine 或 distroless 镜像 替代 full Debian/Ubuntu：Node.js 应用用
gcr.io/distroless/nodejs:18，Python 用python:3.11-slim - 强制多阶段构建：编译环境（builder）和运行环境完全分离，最终镜像只含二进制、配置和必要依赖
- 合并 RUN 指令：把 apt/yum/apk 安装、缓存清理、配置写入等操作合并在一条 RUN 中，避免冗余层
- 加 .dockerignore：排除
node_modules、__pycache__、.git、tests等非运行必需文件
选对存储驱动，加速镜像层挂载
底层存储机制直接影响 layer 加载速度。同一台机器换驱动后，冷启动耗时能差 3 倍以上。
OpenClaw Docker Setup
下载
在 Linux 上通过 Docker 运行 OpenClaw，并使用 Tailscale 实现远程访问。⚠️ 涉及 sudo、Docker、Tailscale和凭证挂载——请先查阅安全章节...
- 确认当前驱动：
docker info | grep "Storage Driver" - 生产环境首选 overlay2（Linux 4.0+ 默认），它支持快速 copy-up 和高效元数据管理
- 避免 aufs（已弃用）、devicemapper（需 loop-lvm，IO 开销高）
- 若用 ZFS/Btrfs，确保启用 dnodes 缓存并调优 recordsize
控制初始化行为，缩短入口进程就绪时间
很多“启动慢”其实不是 Docker 慢，而是应用自己卡在初始化环节：连 DB、拉配置、跑迁移、解密密钥……这些都该异步或懒加载。
- MySQL 容器里删掉
slow_query_log_file、log_error等日志路径配置——Docker 日志走 stdout，文件路径不存在会卡住 - 设
innodb_buffer_pool_size ≤ 容器内存限制 × 0.7，避免启动时内存分配失败重试 - Web 应用禁用自动热重载、开发中间件、调试代理；生产镜像中移除
nodemon、webpack-dev-server - 用健康检查替代盲目等待：
healthcheck中用curl -f http://localhost:3000/health，而非固定 sleep 10s
合理约束资源，避免调度与竞争拖慢启动
没设限制的容器，在宿主机资源紧张时可能被内核反复调度、OOM Killer 干扰，甚至因 CPU 抢占导致 init 进程卡顿。
- 启动时加
--memory=512m --cpus=1.2，让 cgroups 提前划界，减少 runtime 动态协商开销 - 对 IO 密集型服务（如 Elasticsearch），加
--blkio-weight=700提升块设备优先级 - Docker Compose 中用
restart: on-failure+depends_on: [db] condition: service_healthy，避免应用抢在依赖就绪前启动
