命令行能连但Navicat报1045，说明问题在host或plugin不匹配：localhost≠127.0.0.1，需确认mysql.user表中root对应host是否一致；若plugin为caching_sha2_password而Navicat≤15.x，则必须改用mysql_native_password插件并勾选“使用原生密码”，且须检查authentication_string是否为空、skip-grant-tables是否残留、远程连接是否创建了对应'@%'或具体IP的用户。
命令行能连上，但Navicat报1045，先看host和plugin
这说明mysql服务本身没问题，问题出在连接上下文匹配上。navicat填的「主机」必须和mysql.user表里对应用户的host字段完全一致——localhost ≠ 127.0.0.1，这是两个独立账号。
进MySQL执行：SELECT user, host, plugin FROM mysql.user WHERE user = 'root';
- 如果Navicat填的是
127.0.0.1，但查出来只有'root'@'localhost'→ 需建'root'@'127.0.0.1'或改Navicat填localhost - 如果
plugin是caching_sha2_password，而Navicat版本≤15.x → 必须换插件，改密无效 - Navicat连接配置里要勾选「使用原生密码」（Native Password），否则即使插件已改，客户端仍可能用错协议
改密前必须确认authentication_string是否为空
authentication_string为空，代表该用户根本没设密码；如果是*开头的哈希值，才说明有密码且可能输错。别一看到1045就重置，空密码时你输啥都错。
执行：SELECT user, host, authentication_string FROM mysql.user WHERE user = 'root';
- 结果为
NULL或空字符串 → 密码未设置，直接ALTER USER 'root'@'%' IDENTIFIED BY 'xxx';即可 - 结果是
*6BB4837EB7432C105EEF65E88A66715A7D9B272F这类哈希 → 才值得怀疑密码本身 - 注意：MySQL 8.0+不认
password()函数，用ALTER USER ... BY 'xxx'，别用UPDATE mysql.user硬改
skip-grant-tables残留会导致改密后仍1045
跳过权限验证改过密的人最容易踩这个坑：配置文件里还留着skip-grant-tables，或者MySQL启动参数里带了它，会导致服务启动时完全忽略所有认证逻辑——此时你连ALTER USER都白做，因为权限系统压根没加载。
检查方式：
- Linux：
grep -i skip-grant /etc/my.cnf /etc/mysql/my.cnf 2>/dev/null - Windows：打开
my.ini，搜skip-grant-tables，确认已删除或注释 - 查启动参数：
ps aux | grep mysqld（Linux）或sc qc mysqld（Windows），看是否有--skip-grant-tables - 改完必须重启MySQL服务，不是只
FLUSH PRIVILEGES;
远程连接必须显式创建'username'@'%'或'username'@'具体IP'
'root'@'localhost'对任何远程IP都无效，这是MySQL设计使然。Navicat填服务器公网IP或内网IP时，必须在MySQL里存在对应host的账号。
安全做法（非root）：
- 建新用户：
CREATE USER 'appuser'@'192.168.1.100' IDENTIFIED WITH mysql_native_password BY 'StrongPass!2026'; - 授最小权限：
GRANT SELECT, INSERT ON mydb.* TO 'appuser'@'192.168.1.100'; - 如需通配，用
'appuser'@'%'，但务必配合防火墙限制来源IP段 - 执行
FLUSH PRIVILEGES;后，再试Navicat
host字段写%看似方便，但容易被忽略网络层拦截——3306端口没开、云服务器安全组没放行、宝塔面板没开远程访问，都会卡在第一步，连认证环节都进不去。
