ERROR 1045 不一定是密码错误，需优先检查 user@host 匹配性、authentication_plugin（如 caching_sha2_password 兼容性）、authentication_string 是否为空或异常，以及 skip-grant-tables 是否残留。
Navicat 连接 MySQL 报 ERROR 1045 (28000): Access denied for user 怎么快速定位是不是密码错了
不是所有 1045 都是密码输错——mysql 的认证失败可能卡在用户、主机、插件、甚至密码加密方式上。先别急着重置密码，用命令行快速验证最核心的三要素：user、host、authentication_string 是否匹配。
- 在 MySQL 服务端执行：
SELECT user, host, plugin, authentication_string FROM mysql.user WHERE user = 'your_username';，重点看host是不是%或具体 IP（Navicat 填的地址必须和这里一致） -
plugin字段如果是caching_sha2_password，而客户端（尤其老版本 Navicat）不支持，就会直接报 1045，不是密码问题 - 如果
authentication_string是空，说明密码根本没设；如果是乱码但非空，才值得怀疑密码本身
MySQL 8.0+ 默认插件导致 Navicat 连不上：怎么改回 mysql_native_password
MySQL 8.0 默认用 caching_sha2_password，但 Navicat 12 及更早版本、部分旧驱动压根不认这个插件，连接时连密码校验环节都进不去，直接 1045。
- 临时方案（单用户）：
ALTER USER 'your_user'@'your_host' IDENTIFIED WITH mysql_native_password BY 'your_password'; - 永久方案（新用户默认）：修改
my.cnf（Linux）或my.ini（Windows），在[mysqld]下加一行：default_authentication_plugin=mysql_native_password，然后重启 MySQL - 改完务必执行
FLUSH PRIVILEGES;，否则不生效
Navicat 里填的「主机」和 MySQL 中的 host 不匹配的典型表现
报 1045 但 SELECT 查到用户存在？大概率是 host 对不上。MySQL 认证时会严格匹配 user@host 组合，不是模糊匹配。
- 常见错误：Navicat 填
127.0.0.1，但 MySQL 里用户是'user'@'localhost'——这两个在 MySQL 里是不同账号，localhost走 Unix socket，127.0.0.1走 TCP，不能混用 - 解决方法：要么 Navicat 改用
localhost（仅限本机），要么在 MySQL 里显式创建'user'@'127.0.0.1'并授权 - 远程连接时，千万别只建
'user'@'localhost'，它对任何 IP 都无效
重置密码后还是 1045？检查 skip-grant-tables 是否残留
用跳过权限表方式重置过密码的人容易踩这个坑：改完密码忘了关 skip-grant-tables，或者配置文件里还留着这行，导致 MySQL 启动时完全忽略权限校验——这时反而所有连接都会被拒绝，报 1045。
- 检查
my.cnf或my.ini，确认[mysqld]段中没有skip-grant-tables - 如果有，删掉并重启 MySQL；重启后立刻用
mysql -u root -p登录验证是否恢复权限校验 - 这个配置一旦残留，不仅 Navicat 连不上，所有客户端都会失败，且错误信息毫无提示性
真正卡住人的往往不是密码本身，而是 MySQL 认证链路上某个隐性环节断了——host 匹配、插件兼容、配置残留，任何一个没对齐，都会统一表现为 1045。
