容器删除后日志、退出码、挂载状态全丢是默认行为，非操作失误；必须在删除前用docker inspect固化状态、docker logs加时区提取故障窗口日志、docker events捕获生命周期事件，否则关键排错线索永久消失。
容器一删，所有日志、退出码、挂载状态全丢——这不是操作失误，是默认行为。Docker Desktop 里点“删除”或 docker rm 时，可写层、运行时状态、State.FinishedAt 这些关键排错线索就永久消失。必须在重建前完成现场固化。
先停容器，别删，用 docker inspect 抓住配置快照
很多人看到容器卡在 Restarting 就手抖点“删除”，结果连它为什么起不来都查不到。此时容器虽反复崩溃，但 docker inspect 仍能读出最后一次的完整状态。
-
State.Status是exited还是restarting，决定你下一步是进容器还是看日志 -
State.ExitCode不是万能钥匙，但结合State.OOMKilled: true才能确认是否真被杀；单独看到137不能直接断定 OOM -
Mounts字段告诉你配置文件到底来自镜像内、bind mount 还是 named volume——改错的地方可能根本不在容器里 - 执行
docker inspect --format='{{json .State}}' <container_id></container_id>可快速提取状态块，避免翻大 JSON
用带时区的 --since/--until 提取故障窗口日志
只跑 docker logs --tail 100 很容易错过真正出问题那几秒。Docker Desktop 默认日志不带时区，而你的告警时间（比如“15:22 接口超时”）一定带本地时区。
- 把用户反馈时间补全为 ISO 8601 格式，例如
2026-10-23T15:22:00+08:00，再前后各扩 90 秒作为窗口 - 命令必须带
--timestamps，否则日志行没有时间戳，无法对齐事件流 - 别用
-f实时跟踪——你没法保证容器在你盯着的时候恰好崩溃；固定窗口才是可复现的证据 - 如果
docker logs返回空，先检查State.StartedAt是否晚于--since时间，说明容器根本没活到那个时段
用 docker events 补全容器生命周期链
docker logs 是应用层输出，docker inspect 是静态切片，而 docker events 是 Docker daemon 的操作流水账——它记录了谁、什么时候、因为什么触发了 stop/start/kill。
- 运行
docker events --since '2026-10-23T15:20:00+08:00' --until '2026-10-23T15:25:00+08:00' --filter 'container=<id>'</id> - 重点找
kill和die事件，它们的时间戳常比State.FinishedAt更准，且附带信号类型（如signal=9） - 如果看到连续的
start→die→start，说明 restart policy 在生效，不是手动触发的重启 - Docker Desktop 后台可能因 WSL2 异常触发
daemon die，这种全局事件会出现在未加 filter 的 events 流中
真正难的不是命令怎么敲，而是意识到：容器重建不是排错终点，而是起点。所有 inspect 输出、带时区的日志片段、events 流，必须在 docker rm 前存到宿主机目录里——因为一旦容器 ID 消失，这些数据就再不可逆地从 Docker daemon 中蒸发了。
