要测试应用在容器重启后的恢复能力，关键不是等它“自然崩溃”，而是主动触发不同阶段的生命周期事件，观察应用能否正确初始化、加载状态、重建连接并重新提供服务；需覆盖启动、运行、中断、重启四环节，重点验证数据一致性、依赖连通性和服务可用性，并通过三层状态（容器层、应用层、业务层）及可断言的测试用例进行自动化验证。
要测试应用在容器重启后的恢复能力，关键不是等它“自然崩溃”，而是主动触发不同阶段的生命周期事件，观察应用能否正确初始化、加载状态、重建连接并重新提供服务。整个过程需覆盖启动、运行、中断、重启四个环节，重点验证数据一致性、依赖连通性和服务可用性。
模拟真实重启场景
不能只用docker restart——它跳过了容器销毁重建过程，无法暴露镜像层或挂载卷初始化问题。应组合使用以下命令：
-
docker kill -s SIGTERM <container></container>：模拟优雅终止，检验应用是否响应信号并完成清理 -
docker stop --time=5 <container></container>：设置超时后强制发送 SIGKILL，测试崩溃式退出恢复 -
docker rm -f <container> && docker run ...</container>：彻底重建容器，验证启动脚本、环境变量注入和卷挂载是否可靠 -
systemctl restart docker（宿主机上）：测试守护进程重启后，配置了--restart=unless-stopped的容器能否自动拉起
验证恢复行为是否符合预期
每次重启后，不能只看容器是否“running”，要检查三层状态：
-
容器层：用
docker inspect <c> | grep -A 5 'Status\|Health'</c>确认State.Status为running，且State.Health.Status在几轮检查后变为healthy -
应用层：调用健康端点（如
curl http://localhost:8080/health），确认返回200且含正确版本、就绪时间等字段 - 业务层：执行真实业务操作（如提交表单、查询缓存、写入数据库），验证会话未丢失、ID连续、事务未重复
设计可断言的测试用例
把恢复能力变成可自动化的断言，例如：
- 容器重启后，
/app/logs/app.log中必须包含Started Application in X seconds，且时间戳晚于上次终止时间 - 重启前后，Redis 中的计数器值应保持不变（若应用支持持久化）或按预期重置（若设计为无状态）
- 重启后首次 HTTP 请求响应时间 ≤ 2s，且不返回
503 Service Unavailable - 连续执行 3 次
docker stop && docker start后，数据库连接池仍能正常获取连接，无Connection refused
暴露常见恢复盲区
很多应用在“看似重启成功”下隐藏严重缺陷，测试时要刻意绕过默认保护：
- 禁用健康检查：
docker run --no-healthcheck，验证基础进程是否真能自启，而非靠健康探测“假存活” - 清空临时目录：
rm -rf /tmp/*进容器再重启，检验应用是否容忍缺失临时文件 - 伪造依赖不可用：启动前停掉 MySQL 容器，等主应用因连接失败退出后，再启动 MySQL 并观察其是否自动重连
- 修改挂载卷权限：
chmod 000 /data，测试应用能否优雅降级或报明确错误，而非静默失败
