根本原因是mysql容器启动时跳过初始化：当/var/lib/mysql非空（如挂载目录存在残留），容器直接复用旧实例而不读取mysql_root_password，导致密码未设置；需清空数据卷、确保目录权限属uid 999并验证日志中“generated root password”出现。
为什么 MYSQL_ROOT_PASSWORD 设置了却没生效？
根本原因不是环境变量写错了，而是 MySQL 容器启动时“跳过了初始化”——它发现 /var/lib/mysql 目录非空（哪怕只是个空文件夹、.gitkeep 或权限残留），就直接启动已有实例，不再读取 MYSQL_ROOT_PASSWORD。此时 root 密码仍是初始随机值（会打印在容器日志里），或压根没设。
常见诱因包括：
- 挂载了本地目录（如
./mysql-data:/var/lib/mysql），而该目录已存在但内容不完整 - Windows/macOS 下 Docker Desktop 的文件系统权限映射异常，导致 MySQL 误判目录状态
- 容器重启后复用旧卷，但上次退出未正常关闭，留下锁文件或半初始化状态
如何确认是否真跳过了初始化？
运行容器后立即查日志：docker logs <container-name></container-name>。如果看到类似以下输出，说明初始化已执行：
Initializing database<br>...<br>GENERATED ROOT PASSWORD: xxxxxxxx
若日志里只有 Starting MySQL... 或直接报错 Access denied for user 'root'@'localhost'，基本可断定跳过了初始化。
进一步验证：进容器执行 ls -la /var/lib/mysql，重点看是否有 mysql、performance_schema 等系统库目录。没有 → 未初始化；有但缺失 mysql.user 表或 ibdata1 文件 → 初始化失败或中断。
快速修复：清空数据卷并强制重初始化
这不是“删库”，而是让 MySQL 重新走一遍安全初始化流程。操作前确保无重要数据，或已备份 /var/lib/mysql 下的业务库目录（如 myapp）。
步骤如下：
- 停容器：
docker stop <container-name></container-name> - 删数据卷（仅限测试/开发）：
docker volume rm <volume-name></volume-name>；若用本地路径挂载，手动清空对应目录：rm -rf ./mysql-data/* - 确保启动命令中明确指定密码：
docker run -e MYSQL_ROOT_PASSWORD=your-secure-pw ... mysql:8.0 - 启动后立刻查日志确认
GENERATED ROOT PASSWORD是否出现 —— 如果出现，说明初始化成功；如果没出现但服务起来了，说明仍被跳过，需检查挂载路径权限（见下一条）
挂载场景下必须处理的权限和路径细节
Linux 主机上，MySQL 容器内默认以 UID 999（mysql 用户）运行。若挂载的本地目录属主是 root 或普通用户，容器内进程会因权限不足无法写入，导致初始化静默失败。
必须执行：
- 创建目录并赋权：
mkdir -p ./mysql-data && chown -R 999:999 ./mysql-data - 避免使用 root 用户启动容器（
--user root）——这会触发 MySQL 启动保护机制直接退出 - 不要挂载
/tmp或/var/run/mysqld到主机路径，除非你同步处理好 socket 和 pid 文件权限；更稳妥的做法是用tmpfs：--tmpfs /var/run/mysqld:rw,exec,uid=999,gid=999
Windows/macOS 用户若仍不生效，优先改用 Linux 虚拟机或 WSL2 运行容器 —— 官方文档明确指出 macOS 上的文件共享层对 MySQL 初始化支持不稳定。
