答案是caching_sha2_password插件不兼容导致认证失败。典型报错包括2054、er_not_supported_auth_mode等；需用select确认用户plugin值，再通过alter user切换插件并flush privileges生效，而非修改my.cnf中的default_authentication_plugin。
认证失败不是密码错了，而是客户端根本认不出 MySQL 8.0 默认的 caching_sha2_password 插件——连握手阶段就卡住，SHOW GRANTS 正常也白搭。
确认是不是 caching_sha2_password 导致的连接失败
别急着改配置，先验证错误是否真源于此。典型报错包括：SQLSTATE[HY000] [2054]、ER_NOT_SUPPORTED_AUTH_MODE 或 Authentication plugin 'caching_sha2_password' cannot be loaded。
用 root 登录后执行：
SELECT User, Host, plugin FROM mysql.user WHERE User = 'your_username';
如果返回的 plugin 是 caching_sha2_password，而你用的是旧版 PHP mysqli、Python MySQLdb、Navicat 12、JDBC 5.x 等驱动，基本就是它了。
注意：SHOW GRANTS 能查出来 ≠ 认证成功——权限语句能输出，但连接根本进不来。
ALTER USER 切换认证插件必须带 FLUSH PRIVILEGES
这是最快见效、无需重启服务的方法，适合开发/测试环境快速验证。
在 MySQL 命令行中执行（把 your_username 和 your_password 换成真实值）：
ALTER USER 'your_username'@'localhost' IDENTIFIED WITH mysql_native_password BY 'your_password';<br>FLUSH PRIVILEGES;
常见踩坑点：
- 漏掉
FLUSH PRIVILEGES：权限变更不会自动生效 -
host不匹配：比如应用连的是'user'@'192.168.1.100'，但你只改了'user'@'localhost' - 用户密码为空或太弱：MySQL 8.0 可能拒绝执行，需先设强密码再改插件
为什么 default_authentication_plugin 在 my.cnf 里改了也没用
这个参数只在实例首次初始化时生效，升级后的已有用户完全不受影响。日志里看不到报错，但问题照旧——这是最容易白忙活的坑。
真正要改的是用户级认证方式，不是配置文件。批量处理多个用户时，可从 mysql.user 视图中查出所有非 mysql_native_password 的账号，生成一批 ALTER USER 语句。
注意：mysql.user 在 8.0 中是视图，不能直接 UPDATE；也不能用 SET PASSWORD 替代 ALTER USER ... IDENTIFIED WITH，后者才真正切换插件。
启动失败时先看错误日志里有没有 mysql.user doesn't exist
这不是权限配置错了，而是底层元数据结构断裂。8.0 启动时会校验系统表是否符合新格式，若仍残留 5.7 的 MyISAM 表或字段不全，就会拒绝加载。
必须用升级后版本的 mysqld --upgrade=FORCE 启动初始化，而不是依赖已废弃的 mysql_upgrade 工具。
执行前确保：
- datadir 所有者是
mysql:mysql - 磁盘剩余空间 ≥ 2GB
- 路径准确，调用的是 8.0 的
mysqld二进制，不是旧版
如果 --upgrade=FORCE 卡在 performance_schema 或 innodb_index_stats，说明升级中途被中断，此时不能重试，状态可能更糟。
