本质是MySQL 8.0的caching_sha2_password认证与客户端安全策略冲突，需加allowPublicKeyRetrieval=true（配合useSSL=false）或降级为mysql_native_password，SSL启用虽更安全但依赖证书部署。
这个问题本质是 MySQL 8.0 的 caching_sha2_password 认证机制与客户端默认安全策略冲突，不是连接参数写错或密码不对，而是“握手协议没对上”。最直接有效的解法是加参数或改认证方式，但选哪种得看环境和安全要求。
为什么加 allowPublicKeyRetrieval=true 就能连上？
当用户用 caching_sha2_password 且未启用 SSL 时，客户端需要用服务器的 RSA 公钥加密密码再发送。但 JDBC 驱动默认禁止主动向服务器请求公钥（防中间人攻击），所以报错。加这个参数就是明确告诉驱动：“我信任这个网络环境，允许你去要公钥”。
常见使用场景包括本地开发、DBeaver/SQLark 连接、Spring Boot 启动失败等。
- 必须搭配
useSSL=false使用，否则可能触发其他 SSL 相关错误 - 在 JDBC URL 中直接拼接：
jdbc:mysql://localhost:3306/test?allowPublicKeyRetrieval=true&useSSL=false&serverTimezone=UTC - DBeaver 用户需在“驱动属性”里手动添加键
allowPublicKeyRetrieval，值设为true - Spring Boot 的
application.properties中写成：spring.datasource.url=jdbc:mysql://...?allowPublicKeyRetrieval=true&useSSL=false（注意 & 要转义）
什么时候该改用户认证插件为 mysql_native_password？
当你无法控制客户端配置（比如老旧的第三方工具、嵌入式 JDBC 包、某些 CI 环境），或者团队明确禁用 allowPublicKeyRetrieval 参数时，降级认证插件是最兼容的兜底方案。
执行前需确保你有管理员权限，并能通过命令行或其他可用客户端登录数据库。
- 先确认当前用户用的是什么插件：
SELECT user, host, plugin FROM mysql.user WHERE user = 'your_username'; - 执行修改语句（替换用户名、主机和密码）：
ALTER USER 'your_username'@'localhost' IDENTIFIED WITH mysql_native_password BY 'your_password'; - 立即生效：
FLUSH PRIVILEGES; - 注意：MySQL 9.7 已完全移除
mysql_native_password，此法仅适用于 MySQL 8.x
useSSL=true 是不是更安全？那为什么还推荐前两种？
是的，启用 SSL 才是官方推荐的生产级解法，它绕过了公钥检索环节，全程加密传输，既安全又合规。但落地难点在于证书管理——你需要有合法的服务器证书、CA 配置，且客户端要验证（verifyServerCertificate=true）或跳过验证（不推荐）。
真实项目中，很多测试环境没有部署 TLS，或者运维流程尚未就绪，硬推 SSL 反而卡住开发节奏。
- 若已有证书，连接串应为：
jdbc:mysql://host:3306/db?useSSL=true&verifyServerCertificate=true&serverSslCert=/path/to/ca.pem - 开发机自签证书 +
verifyServerCertificate=false属于“伪安全”，仍存在 MITM 风险，不建议在任何非隔离网络使用 - 云数据库（如阿里云 RDS、腾讯云 CDB）通常提供一键下载根证书功能，优先走这条路
真正容易被忽略的是：同一个 MySQL 实例里，不同用户的认证插件可以混用。也就是说，你可以只把应用账户改成 mysql_native_password，而保留管理员账户用 caching_sha2_password，不必全局降级。另外，所有涉及 allowPublicKeyRetrieval=true 的配置，一旦进入预发或生产环境，必须同步评估网络边界是否可控——内网不一定绝对可信，尤其在多租户或容器化环境中。
