验证Docker容器重启后数据一致性，关键在于确认业务数据（如数据库记录、文件内容）是否完整，而非仅检查容器是否重启成功；必须结合持久化存储（如命名卷）与三步实测法：写入→重启→查询比对，否则即使配置always策略，/var/lib/mysql等路径数据仍会丢失。
要验证 docker 容器在重启策略下的数据一致性，关键不是只看容器是否重启成功，而是确认应用状态、文件内容、数据库记录等业务数据在重启前后是否完整未丢失。这需要把“容器生命周期管理”和“存储持久化机制”两个层面结合起来测试。
明确测试目标：重启 ≠ 数据完好
容器配置了 restart: always 或 unless-stopped，只能保证进程被拉起，不能保证 /var/lib/mysql 里的表还在、日志没截断、或挂载卷里的 JSON 文件没被覆盖。很多数据丢失问题，根源是存储没配对，而不是重启策略失效。
用三步法实测数据是否真正一致
这是工程师现场验证最可靠的方式，不依赖日志猜测，直接读写比对：
- 启动带持久化存储的服务（必须用命名卷或正确绑定挂载）
services: db: image: mysql:8.0 volumes: - mydata:/var/lib/mysql # 命名卷，非 ./data environment: MYSQL_ROOT_PASSWORD: test restart: always - 在容器内写入可验证的数据
docker exec -it myapp-db sh -c "mysql -uroot -ptest -e 'CREATE DATABASE IF NOT EXISTS testdb; USE testdb; CREATE TABLE t1(id INT); INSERT INTO t1 VALUES(42);'"
- 手动触发重启（不删卷），再检查数据是否存在且未变
docker restart myapp-db sleep 5 docker exec -it myapp-db sh -c "mysql -uroot -ptest -e 'SELECT * FROM testdb.t1;'" # 输出应为：id ↵ 42
如果输出为空或报错 Unknown database 'testdb'，说明数据没落盘——问题出在存储配置，不是重启策略。
区分两类常见失败场景
有些“数据不一致”看似重启引起，实则是设计误用：
容器内路径写入 + 无挂载 → 每次重启都是新容器，数据从零开始
比如程序默认往/app/output/log.txt写日志，但没挂-v mylogs:/app/output，那每次docker restart后该文件就消失了。多个容器共享同一卷但无并发控制 → 重启后数据被覆盖或损坏
例如两个 worker 容器都往/data/queue.json写队列状态，没加文件锁，一个重启时另一个正在写，就可能产生脏数据。
补充建议：让一致性可自动化验证
- 在 CI/CD 流程中加入数据校验脚本，每次部署后自动执行写入→重启→查询→比对
- 对数据库类服务，用
mysqldump --no-data检查 schema 是否保留；用SELECT COUNT(*)核对关键表行数 - 避免用
COPY或ADD在 Dockerfile 中塞初始数据并指望它“可修改”，那是只读层，运行时改不动
不复杂但容易忽略。
