改密码后连不上，大概率是 caching_sha2_password 插件未同步重置；mysql 8.0 中密码与认证插件分离，仅执行 set password 或 alter user ... identified by 不会更改 plugin 字段，需显式用 alter user ... identified with mysql_native_password by ... 并 flush privileges。
改完密码后连不上，大概率不是密码错了，而是 caching_sha2_password 插件没跟着一起重置——MySQL 8.0 的 ALTER USER ... PASSWORD EXPIRE 或单纯用 SET PASSWORD 不会动认证插件，旧插件还在那儿卡着连接。
为什么改密码后突然报 caching_sha2_password 错误？
MySQL 8.0 对用户身份和认证方式做了分离：密码值（authentication_string）和认证插件（plugin）是两个独立字段。执行以下任一操作都只改密码，不碰插件：
SET PASSWORD FOR 'user'@'host' = 'newpass';ALTER USER 'user'@'host' IDENTIFIED BY 'newpass';- 在 phpMyAdmin 或宝塔里点“修改密码”按钮（底层常走
SET PASSWORD）
结果就是：密码更新了，但插件仍是 caching_sha2_password，而你的 Navicat、JDBC 驱动或 Python mysqlclient 不支持它，于是连接失败。
正确改密码 + 兼容性兼顾的操作顺序
必须显式指定插件，并带密码重设。漏掉 BY 子句会导致密码被清空，这是高频翻车点。
- 先确认当前状态：
SELECT user, host, plugin FROM mysql.user WHERE user = 'your_user'; - 如果
plugin是caching_sha2_password，且你用的是旧客户端，就执行：ALTER USER 'your_user'@'host' IDENTIFIED WITH mysql_native_password BY 'your_actual_password'; - 注意：
'your_user'@'localhost'和'your_user'@'%'是两个不同用户，要分别处理 - 立即生效：
FLUSH PRIVILEGES;
Navicat / 宝塔 / Docker 场景下的特殊坑
这些环境容易掩盖真实问题：
- 宝塔的 phpMyAdmin 界面把
plugin字段设为只读，直接编辑表无效，必须走 SQL 标签页执行ALTER USER - Docker 启动时用了
MYSQL_ROOT_PASSWORD环境变量，root 用户仍会被初始化为caching_sha2_password，即使你改了my.cnf也没用，得进容器手动ALTER USER - Navicat 连接测试成功 ≠ 权限完整，有些版本能连上但查不到库列表，本质还是插件没切干净，检查
SELECT权限是否真正授予
驱动侧不升级，服务端就得让步
如果你控制不了客户端（比如第三方 SDK、老旧中间件、云厂商 RDS 控制台自带连接器），那就别硬扛 caching_sha2_password：
- 不要只改
my.cnf的default_authentication_plugin—— 它只影响新用户，对 root 或已存在的账号完全无效 - 不要指望加
useSSL=false或allowPublicKeyRetrieval=true就能绕过：JDBC 5.1.x 根本不认识这个插件，参数再全也白搭 - 真正生效的只有
ALTER USER ... IDENTIFIED WITH mysql_native_password BY ...，且必须配FLUSH PRIVILEGES
安全降级是权衡后的务实选择，比反复调试握手流程更可靠。关键在于：改密码时，顺手把插件一起换掉，别留半截。
