根本原因是层缓存失效和无用文件残留；应清理apt缓存、用.dockerignore、多阶段构建、固定基础镜像；exit 137是oom killer所致，需限制内存并配置jvm/python适配；容器时间不准源于宿主机时钟未校准；depends_on不保证服务就绪，须加健康检查和重试。
容器镜像体积太大，docker build 慢还占空间
根本原因常是层缓存失效 + 无用文件残留。比如 RUN apt-get install 后没清理 /var/lib/apt/lists，或 copy . . 把 node_modules、.git 全塞进镜像。
实操建议：
- 用
apt-get install -y --no-install-recommends装包，装完立刻&& apt-get clean && rm -rf /var/lib/apt/lists/* -
COPY前写好.dockerignore，至少包含node_modules、.git、*.log、tmp/ - 多阶段构建（
multi-stage build）：编译环境用golang:1.22，最终镜像只COPY --from=0 /app/binary /usr/local/bin/ - 别用
latest标签做基础镜像，固定为debian:12-slim或alpine:3.20，避免某天latest变成不兼容版本
docker run 启动就退出，日志里只有 Exit 137
Exit 137 不是程序报错，是被系统 OOM killer 杀掉的——容器内存超限了。尤其在 CI 环境或小内存机器上高频出现。
实操建议：
- 启动时加
--memory=512m --memory-swap=512m显式限制，比默认不限更可控 - 用
docker stats实时看实际内存峰值，不是看应用自己打印的“已用内存” - JVM 应用必须传
-XX:+UseContainerSupport -XX:MaxRAMPercentage=75.0，否则 JVM 看不到 cgroup 限制，按宿主机内存算堆大小 - Python 应用注意
psutil或Resource.getrusage()获取的是宿主机值，不能用来判断容器内可用内存
容器内时间不准，date 和宿主机差几分钟
不是 NTP 问题，是容器默认共享宿主机的 clock_gettime(CLOCK_REALTIME)，但若宿主机时钟没校准，或用了 chronyd + makestep 大幅跳变，容器内 syscall 返回值可能短暂滞后。
实操建议：
- 不要在容器里跑
ntpd或chronyd—— 容器不是 VM，时间源应由宿主机统一提供 - 确保宿主机已启用
systemd-timesyncd或配置了可靠 NTP server，并检查timedatectl status中System clock synchronized: yes - 若业务强依赖毫秒级时间一致性（如金融对账），改用
CLOCK_MONOTONIC做间隔测量，它不受系统时钟跳变影响 - 排查时用
docker exec -it <container> date -u; date -u</container>对比，确认是否真偏差，而非只是时区显示问题
docker-compose up 启动顺序靠 depends_on 不靠谱
depends_on 只控制容器启动顺序，不等服务就绪。比如 postgresql 容器起来了，但 postgres 进程还没 listen，应用连接就直接报 Connection refused。
实操建议：
- 删掉
depends_on的condition: service_started—— 它毫无意义，Docker 不检查端口或健康状态 - 在应用启动脚本里加重试逻辑：用
until nc -z db 5432; do sleep 2; done或更稳妥的pg_isready -h db -U postgres - 数据库类服务务必配
healthcheck：test: ["CMD-SHELL", "pg_isready -U postgres"]，再配合restart: on-failure - 微服务间依赖，优先用服务发现 + 重试 + 熔断（如
resilience4j），别指望编排工具解决运行时依赖
真正麻烦的从来不是怎么写 Dockerfile，而是当 docker stats 显示内存稳定在 85%，但 curl 开始超时，又找不到对应日志时——那大概率是某个 C 库的内存池没适配 cgroup v2，或者 ulimit -n 在容器里被静默截断了。