临时密码未写入预期日志的最常见原因是log_error配置缺失或拼错，导致密码输出至控制台而非.err文件；若datadir非空则初始化静默跳过密码生成。
不是初始化卡住了，是临时密码根本没写进你正在看的日志文件里——它被输出到别处了，或者压根没生成。
mysqld --initialize 后日志里搜不到 “temporary password”
最常见原因：配置文件中 log_error 被注释或拼错（比如写成 log_erro），导致 MySQL 初始化时把临时密码直接打到控制台 stderr，而不是写入 .err 文件。你关掉终端就没了。
- Linux 下检查：
sudo mysqld --verbose --help | grep "log-error"，确认真实路径；若无输出，说明没配置，MySQL 会 fallback 到默认路径（如/var/log/mysqld.log或/var/log/mysql/error.log） - Windows 下注意：
C:\ProgramData\MySQL\MySQL Server 8.0\Data\是隐藏目录，文件名是你的计算机名（如DESKTOP-ABC.err），不是localhost.err - 如果
datadir目录非空（残留旧数据），mysqld --initialize会静默跳过密码生成，不报错也不输出
执行 mysqld --initialize 后控制台也没输出密码
说明初始化过程被中断或权限不足，常见于：
- Linux：没加
--user=mysql，导致进程以 root 身份启动但无法写入datadir（属主为 mysql:mysql） - Windows：没用管理员身份运行 CMD/PowerShell，
mysqld无法在ProgramData下创建或写入日志 - 磁盘满、SELinux 拦截、AppArmor 限制等系统级问题，也会让日志写入失败，且错误信息可能藏在系统日志里（
dmesg或journalctl -u mysqld）
为什么用 --initialize-insecure 反而更麻烦
它确实不生成临时密码，但会触发另一个隐性卡点：
- MySQL 8.0+ 默认启用
validate_password插件，后续任何ALTER USER设密码操作都会校验强度 - 你设一个简单密码（如
'123'），立刻报ERROR 1819；想禁用插件又得先登录，陷入“没密码登不进，登不进又改不了”的循环 - 除非你提前在配置文件里加
validate_password.policy = LOW或skip-validate-password，否则不如老实用--initialize+ 查日志
真正容易被忽略的细节
第一次初始化后的那个 .err 文件，必须在启动 mysqld 服务前就查完。服务一旦启动，日志可能被轮转覆盖、清空，或因多次重启而归档——你后来翻半天的 mysqld.log.1 或 error.log.2.gz，其实早不是最初那条密码所在的文件了。
