要让容器数据不随容器销毁而丢失，关键在于将数据存至容器外并由外部机制管理生命周期；docker提供命名卷（优先用于核心业务数据）、绑定挂载（适用于开发调试）和tmpfs（用于临时数据）三种方式，需按数据类型分层挂载并规范权限与路径。
要让容器数据不随容器销毁而丢失，关键在于把数据存到容器外，并由外部机制管理生命周期。Docker 提供三种挂载方式，但只有选对方案、配对路径、管好权限，才能真正实现可靠性保障。
优先用命名卷（Named Volume）存核心业务数据
命名卷由 Docker 自行管理，路径抽象、权限隔离、跨容器共享都更稳妥，特别适合数据库文件、用户上传内容等关键数据。
- 创建时指定名称，避免匿名卷带来的定位困难： docker volume create app-db-data
- 启动容器时明确挂载： docker run -v app-db-data:/var/lib/mysql mysql:8
- 卷内初始内容会被保留——如果挂载点原目录有配置文件，Docker 会自动复制进去
- 备份简单：用 docker volume inspect 查路径，再 tar 打包对应目录即可
绑定挂载（Bind Mount）只用于可控场景
它直接映射宿主机路径，开发调试或配置热更新很顺手，但生产环境要格外小心路径和权限问题。
- 宿主机目录需提前创建，且权限要匹配容器内运行用户（例如 MySQL 容器常用用户是 mysql，不是 root）
- 挂载命令中可加 :z 或 :Z 让 SELinux 自动打标签，避免权限拒绝： -v /data/config:/etc/app:z
- 绝对路径必须一致，Windows/macOS 路径格式不同，跨平台部署时容易出错
- 不要把整个 /var/lib/docker 或系统目录挂进去，可能引发冲突或安全风险
按数据类型分层挂载，不混用
同一应用的不同数据，生命周期和访问模式不同，混在一个挂载点容易出问题。
- 数据库文件 → 命名卷（如 app-db-data）
- 配置文件 → 绑定挂载（如 -v ./conf:/etc/app），便于人工编辑
- 日志文件 → 单独命名卷或绑定挂载，再配合日志轮转工具
- 临时缓存/会话 → --tmpfs /run/cache，内存存储，重启即清，不占磁盘也不落盘
补救已运行容器的数据持久化
如果容器已在跑但没挂载，别直接删，先迁移再重建。
- 用 docker cp container_id:/path/to/data /host/backup/ 把数据导出
- 停掉容器：docker stop container_id
- 用新挂载参数重新运行，把刚才导出的路径挂进去
- 验证数据是否完整可读，再切换流量
