若容器状态为 exited (1) 或 exited (137)，基本可断定 mysql 进程未启动成功；此时 docker logs 输出常为空或极短，因进程秒退未及刷盘日志。
容器启动后立即退出，怎么确认是不是MySQL进程没起来？
直接看容器状态最省事：docker ps -a 会显示最近一次退出的退出码。如果状态是 Exited (1) 或 Exited (137)，基本可以断定 MySQL 进程根本没跑起来，而不是运行中出错。这时候 docker logs <container_id></container_id> 输出往往为空或只有几行启动日志——因为进程秒退，日志根本没来得及刷盘。
- 用
docker logs --details <container_id></container_id>加上详情参数，有时能多看到一点 stderr 重定向信息 - 如果日志空且退出码是 1，优先检查配置挂载：比如
/etc/mysql/conf.d/下的自定义.cnf文件语法错误，MySQL 启动校验失败会直接退出，不写日志 - 挂载的
data目录权限不对（如宿主机用 root 写入，但容器里 MySQL 以非 root 用户运行），也会静默失败
docker logs 没输出，但容器在反复 restart，怎么强制拉出崩溃前的日志？
Docker 默认用 json-file 日志驱动，进程崩溃太快时日志可能滞留在缓冲区没 flush。临时改用 local 驱动并调小缓冲参数，能提高捕获率：
- 启动容器时加参数：
--log-driver local --log-opt max-size=10m --log-opt max-file=3 - 或在
/etc/docker/daemon.json全局设置（需sudo systemctl reload docker） - 更直接的办法：用
docker run -it --rm mysql:8.0 --verbose --log-error-verbosity=3手动跑一次 MySQL 命令行模式，绕过 init 脚本，直接看报错
常见卡点：MySQL 8.0 默认启用 validate_password 插件，如果通过 MYSQL_ROOT_PASSWORD 设置的密码太简单，容器会启动失败且只在 stderr 打一行提示，docker logs 却因输出未被捕获而看不到。
挂载了自定义配置文件，但容器一直 restart，怎么验证 cnf 是否生效？
MySQL 容器启动时会按固定顺序读取配置：/etc/my.cnf → /etc/mysql/my.cnf → /etc/mysql/conf.d/.cnf → /etc/mysql/mysql.conf.d/.cnf。挂载进来的文件如果路径或后缀不对，根本不会被加载。
在 Linux 上通过 Docker 运行 OpenClaw，并使用 Tailscale 实现远程访问。⚠️ 涉及 sudo、Docker、Tailscale和凭证挂载——请先查阅安全章节...
- 确保挂载目标路径是
/etc/mysql/conf.d/my.cnf（不是/etc/mysql/my.cnf），且后缀必须是.cnf - 在容器内执行：
docker exec -it <container_id> mysql --verbose --help | grep "Default options"</container_id>，看实际加载的配置路径 - 把自定义配置里加上
log_error = /var/log/mysql/error.log和log_warnings = 2，再挂载一个日志目录出来，比依赖docker logs更可靠
注意：MySQL 5.7 和 8.0 的默认 sql_mode 差异很大，如果旧配置里硬写了 sql_mode=STRICT_TRANS_TABLES,NO_ZERO_DATE，在 8.0 上可能触发兼容性拒绝启动，错误只打在 error log 里，docker logs 不会转发。
容器重启间隔越来越短，怎么避免无限 restart 影响排查？
Docker 默认的 restart policy 是 on-failure 或 always，一旦失败就立刻重试，导致你来不及 docker exec 进去查状态。
- 启动时加
--restart=on-failure:1，限制最多重试 1 次，留出手动干预窗口 - 或干脆不用 restart policy，用
docker run -d --name mysql-test ...启动后，观察几秒，docker ps -a看状态，再决定是否删掉重试 - 如果已陷入循环，先
docker stop <container_id></container_id>，再docker rm <container_id></container_id>，否则docker logs可能返回上一轮的日志，不是最新失败那次的
真正麻烦的是 volume 数据目录损坏或权限错乱，这种问题 docker logs 永远不会告诉你“磁盘不可写”，只会显示 MySQL 初始化失败。得进容器里 docker exec -u 0 -it <container_id> sh</container_id>，然后 chown -R mysql:mysql /var/lib/mysql 手动修权限，再试。
