宿主机目录必须为空，因MySQL官方镜像首次启动时检查/var/lib/mysql是否为空，非空则跳过初始化，导致MYSQL_ROOT_PASSWORD等环境变量失效、容器启动失败或卡在“Starting MySQL”。
直接用 -v 挂载宿主机目录到数据库容器的默认数据路径（如 /var/lib/mysql、/data），是最简单有效的持久化方式；但必须确保宿主机目录为空、权限正确、路径为绝对路径，否则容器大概率启动失败或数据不生效。
挂载 MySQL 容器时，宿主机目录为什么必须为空？
MySQL 官方镜像在首次启动时，会检查 /var/lib/mysql 是否为空。如果不为空（比如已有残留文件、旧数据、甚至只是隐藏的 .git 目录），它会跳过初始化流程——这意味着 MYSQL_ROOT_PASSWORD、MYSQL_DATABASE 全部失效，容器可能卡在 “Starting MySQL” 或直接退出。
- 务必在运行容器前执行：
mkdir -p /mydata/mysql，且不要往该目录里放任何东西 - 如果已误写入内容，用
rm -rf /mydata/mysql/*清空（注意不是rm -rf /mydata/mysql，避免删错父目录） - Windows 上通过 Docker Desktop（WSL2 后端）使用时，路径要写成 WSL2 内部可识别的形式，例如
/mnt/wsl/mydata/mysql，而不是C:\mydata\mysql
Redis 容器挂载后仍丢失数据？检查 AOF 和 appendonly.aof 权限
Redis 默认不开启持久化，即使挂载了目录，若没启用 AOF 或 RDB，重启后照样丢数据。更隐蔽的问题是：挂载目录权限不对，导致 Redis 进程（uid 999 或 redis 用户）无法写入 appendonly.aof 文件。
- 启动命令中必须显式开启 AOF：
--appendonly yes，或挂载自定义redis.conf并设appendonly yes - 宿主机挂载目录需赋予写权限：
chmod 755 /mydata/redis，必要时加:z标签（Linux SELinux 环境下）：-v /mydata/redis:/data:z - 验证是否生效：进容器执行
redis-cli info persistence | grep aof_enabled，返回aof_enabled:1才算真正启用
ClickHouse 容器一启动就退出？重点看 /var/lib/clickhouse 和 listen_host
ClickHouse 对挂载路径和配置耦合度高。常见崩溃原因不是数据目录本身，而是挂载后容器内用户无法创建子目录（如 /var/lib/clickhouse/store），或监听配置未放开外部访问。
- 宿主机目录必须存在且可写：
mkdir -p /mydata/clickhouse && chmod 777 /mydata/clickhouse（ClickHouse 启动用户较复杂，宽松权限更稳妥） - 必须挂载并覆盖默认配置，尤其
<listen_host>0.0.0.0</listen_host>，否则容器内服务只监听127.0.0.1，外部连不上 - 推荐用命名卷替代绑定挂载：
docker volume create clickhouse-data，再-v clickhouse-data:/var/lib/clickhouse，避免路径和权限双重踩坑
Docker Desktop for Windows 下，挂载路径容易错在哪？
Windows 用户最常栽在路径语义混淆上：Docker Desktop 底层是 WSL2，所有 -v 路径实际由 WSL2 解析，不是 Windows 文件系统直通。
-
-v C:\mydata\mysql:/var/lib/mysql❌ 无效，Docker 会静默忽略或报错“invalid mount config” - 正确写法是 WSL2 中的路径，例如：
-v /mnt/wsl/mydata/mysql:/var/lib/mysql（需先在 WSL2 里sudo mkdir -p /mnt/wsl/mydata/mysql） - 或者改用命名卷（
-v mysql-data:/var/lib/mysql），完全绕过宿主机路径问题，适合开发环境快速验证
真正的麻烦往往不出现在命令敲完那一刻，而是在你删掉容器重试三次之后，才意识到挂载目录里早就有个 .DS_Store 或 Thumbs.db ——这些看似无害的文件，足以让 MySQL 拒绝初始化。动手前，先 ls -a 看一眼目标目录。
