2003错误本质是Navicat未触达MySQL进程，需逐层验证：先telnet测端口连通性，再查云安全组、系统防火墙、MySQL监听地址（是否为0.0.0.0:3306而非127.0.0.1），最后确认用户权限与host匹配。
Navicat 连接报 2003 错误：根本没通到 MySQL 服务
看到 phpMyAdmin 能登录、还能改用户权限，就以为“远程访问已开”，这是最典型的误判。2003 错误（Can't connect to MySQL server）意味着 Navicat 根本没触达 MySQL 进程，连认证环节都没进入。此时改 mysql.user 表、在宝塔点“所有人”、甚至重置密码，全无效。
必须逐层验证网络通路：
- 本地执行
telnet your-server-ip 3306—— 若连接超时或拒绝，说明卡在网络层 - 检查云厂商安全组（阿里云/腾讯云控制台）是否放行了入方向
TCP:3306，授权对象不能只写0.0.0.0/0测试用，生产环境建议填你本地公网 IP - 宝塔「安全」→「系统防火墙」里也得手动添加端口
3306，仅开放宝塔面板端口（8888）不等于开放数据库端口 - 确认服务器上 MySQL 实际监听的是
*:3306而非127.0.0.1:3306：netstat -tuln | grep :3306，若输出含127.0.0.1:3306，说明bind-address = 127.0.0.1仍生效，需修改/www/server/mysql/my.cnf并重启mysql
Navicat 报 1045 错误：密码对但被拒绝，大概率是认证插件不兼容
MySQL 8.0+ 默认用 caching_sha2_password 插件，而多数旧版 Navicat（尤其 v12 及更早）只认 mysql_native_password。即使用户名密码完全正确，也会触发 1045 Access denied。
验证方式：SELECT User, Host, plugin FROM mysql.user WHERE User = 'your_user';
立即学习“PHP免费学习笔记（深入）”；
若 plugin 列显示 caching_sha2_password，执行以下修复：
ALTER USER 'your_user'@'%' IDENTIFIED WITH mysql_native_password BY 'your_password';FLUSH PRIVILEGES;- 注意：不要只改
'root'@'localhost'，Navicat 连接时来源 IP 会被识别为'root'@'x.x.x.x'，host 必须匹配
phpMyAdmin 的「所有人」权限 ≠ MySQL 用户的远程权限
宝塔数据库管理页点“所有人”，只是放开该数据库在 phpMyAdmin 界面的访问控制，它修改的是宝塔自己的权限映射表，和 MySQL 底层的 mysql.user 表完全无关。这个操作对 Navicat 连接零影响。
真正起作用的只有 MySQL 命令行授权语句：
CREATE USER 'naviuser'@'%' IDENTIFIED BY 'strong_pass';GRANT SELECT, INSERT, UPDATE ON mydb.* TO 'naviuser'@'%';FLUSH PRIVILEGES;- 避免直接授
ALL PRIVILEGES ON *.*给 root 或任意用户，最小权限原则优先
连接参数细节常被忽略：Host 值大小写、localhost 和 127.0.0.1 不等价
MySQL 认证时严格比对 User + Host 两个字段。常见坑点：
-
'root'@'localhost'允许通过 Unix socket 或localhost字符串连接，但不允许127.0.0.1IP 方式；反之亦然 - Navicat 连接时若填 Host 为
127.0.0.1，MySQL 就查'root'@'127.0.0.1'，若该记录不存在，哪怕有'root'@'%'也会失败（因为'%'不匹配127.0.0.1的精确 host） - 推荐统一用
%作为 host，或明确创建'user'@'your-pc-public-ip'；测试阶段可先用'user'@'%'，上线前收紧 - Navicat 连接设置中关闭 SSL（除非你真配了证书），否则可能因 SSL 握手失败静默拒连
四个层面——网络通路、服务监听、用户认证、Host 匹配——缺一不可。改完任何一项都必须验证对应环节，而不是一口气全改完再试。最容易漏的是 bind-address 改了没重启 MySQL，或者安全组开了但忘了宝塔防火墙同步放行。
