根本原因是客户端无法连接socket文件或认证方式不匹配；需先确认mysqld进程真实运行状态，再核对socket路径一致性及权限，最后检查root@'localhost'的plugin是否为auth_socket并用alter user修复。
根本原因不是密码错，而是客户端连不上 socket 文件，或连上了但认证方式不匹配。
确认 mysqld 进程是否真在运行
systemctl status mysql 显示 active (running) 不代表 mysqld 进程活着。很多情况下它卡在初始化阶段，比如磁盘满、/var/lib/mysql 权限被改成 root:root、或 innodb_log_file_size 与现有日志不兼容。
- 执行
ps aux | grep mysqld | grep -v grep：无输出 = 服务根本没起来 - 若有进程但
mysql.sock仍不存在，说明 mysqld 启动失败但 systemd 没报错，此时查journalctl -u mysql -n 50 --no-pager - 常见错误提示如
Can't change dir to '/data/mysql'或Permission denied，直接指向目录权限或路径问题
核对 socket 路径是否一致且可写
MySQL 客户端默认找 /tmp/mysql.sock 或 /var/run/mysqld/mysqld.sock，但服务器可能按配置写在别处。路径不一致，连接就直接失败——连鉴权环节都进不去。
- 运行
mysql --socket=/var/run/mysqld/mysqld.sock -u root -p测试：能连说明路径错，不能连再查其他 - 查服务器真实 socket 路径：
mysql -e "SHOW VARIABLES LIKE 'socket';"（需先用sudo mysql -u root进去） - 检查
[mysqld]和[client]段的socket值是否完全一致，且对应目录存在、属主为mysql、有写权限 - Homebrew 或源码编译安装时，
mysql_config --socket才是真实路径，改my.cnf可能无效
检查 root@'localhost' 的 plugin 是否为 auth_socket
Ubuntu/Debian 默认把 root@'localhost' 设成 auth_socket 插件，它不校验密码，只认系统用户身份。你输对密码也进不去，因为 MySQL 根本没走密码验证流程。
- 先用
sudo mysql -u root登录（绕过密码），再执行：SELECT user, host, plugin FROM mysql.user WHERE user = 'root'; - 若看到
plugin = 'auth_socket'，就在这里卡住 - 必须用
ALTER USER 'root'@'localhost' IDENTIFIED WITH mysql_native_password BY '你的新密码';，不能UPDATE mysql.user - 注意：必须显式写
@'localhost'，否则默认匹配@'%'；密码要满足当前策略（如 MySQL 8.0 要求至少 8 位、大小写+数字+特殊字符）
避免 localhost 解析混淆
mysql -u root -p 和 mysql -h localhost -u root -p 都走 Unix socket，但 mysql -h 127.0.0.1 -u root -p 强制走 TCP。如果你只有 root@'127.0.0.1' 权限，前者必然失败，后者却能进——这不是 bug，是设计行为。
- 用
mysql -h 127.0.0.1 -u root -p测试：能连说明是 host 匹配问题 - 用
mysql -S /var/run/mysqld/mysqld.sock -u root -p测试：确认是否真走 socket - 临时应急可用
--protocol=tcp，但长期解法是确保root@'localhost'存在且插件可用 - 别依赖
flush privileges：ALTER USER 后立即生效，该命令对权限表变更已无实际作用
真正容易被忽略的是：socket 路径不一致和 auth_socket 插件这两个问题经常同时存在，但排查时容易只盯一个方向。先确认进程在跑、socket 文件存在且路径一致，再查认证方式，顺序错了会浪费大量时间。
