应先用psql -U xxx -h 127.0.0.1测试TCP连接，再查pg_hba.conf认证方式是否为md5/password、用户密码是否存在且非NULL、listen_addresses是否包含127.0.0.1或*、SSL设置是否匹配，并查看PostgreSQL日志定位具体失败原因。
PostgreSQL报错 ERROR: password authentication failed for user "xxx" 怎么查
这不是navicat的问题，而是postgresql服务端拒绝了密码认证。重点不是重输密码，是确认「这个用户在数据库里是否存在、密码是否匹配、认证方式是否允许密码登录」。
常见错误现象：psql 命令行连得上，Navicat死活报1045；或者换台电脑就连不上——说明问题出在服务端配置或用户权限，不是客户端输错了。
- 先用
psql -U xxx -h 127.0.0.1 -d postgres模拟Navicat的TCP连接方式测试，排除本地socket直连干扰 - 检查
pg_hba.conf文件中对应IP段和数据库的认证方法是否为md5或password（不能是trust或peer） - 确认用户确实设置了密码：
SELECT usename, passwd IS NOT NULL FROM pg_shadow WHERE usename = 'xxx';，返回true才说明密码存在
ALTER USER ... PASSWORD 之后还是连不上？
改密码不等于立刻生效，PostgreSQL不会自动重载认证配置，也不缓存密码明文——它只认 pg_hba.conf 和当前 pg_authid 表里的哈希值。
容易踩的坑：ALTER USER xxx PASSWORD 'xxx'; 执行成功，但没执行 SELECT pg_reload_conf();，导致 pg_hba.conf 修改未生效；或者改了密码却忘了该用户属于哪个 host 规则段。
- 修改密码后，必须确认
pg_hba.conf中对应连接类型（如host）的认证方式支持密码，例如：host all all 0.0.0.0/0 md5 - 改完
pg_hba.conf必须执行SELECT pg_reload_conf();，不能只重启PostgreSQL服务（某些部署方式下配置不会热加载） - 如果用户是通过
CREATE USER创建但没设密码，passwd字段为NULL，此时即使填了密码也认证失败
Navicat里填对了密码，为什么还提示1045？
Navicat默认走TCP/IP连接，而很多本地安装的PostgreSQL默认只监听 localhost 或 Unix socket。如果Navicat填的是 127.0.0.1，但 postgresql.conf 里 listen_addresses 是空或 ''，就会被拒。
另一个高频原因：Navicat用了SSL连接，但服务端没开或配置不匹配，错误被笼统显示为密码错误。
- 检查
postgresql.conf中listen_addresses是否包含'127.0.0.1'或'*'；改完要重启或pg_reload_conf() - 在Navicat连接设置里关掉
Use SSL试试，或者确认服务端ssl = on且证书路径正确 - 查看PostgreSQL日志（通常是
pg_log/下的最新文件），搜索authentication failed，里面会明确写是「no pg_hba.conf entry」还是「password mismatch」
用pgAdmin能连，Navicat连不上：兼容性细节
Navicat对PostgreSQL协议版本和密码哈希格式更敏感。比如9.6+默认用SCRAM-SHA-256加密，而老版本Navicat（如12.x之前）只支持MD5。
这不是Bug，是协议升级带来的真实兼容断层。强行降级服务端不现实，优先调客户端。
- PostgreSQL 10+ 默认启用
password_encryption = scram-sha-256，若Navicat版本旧，需在postgresql.conf中改为md5 - 改完需重置用户密码才能生效：
ALTER USER xxx PASSWORD 'xxx';（否则仍用旧哈希） - Navicat 15+ 已支持SCRAM，但安装包可能默认不勾选SSL/SCRAM组件，重装时注意勾选完整功能
实际排查时，最耗时间的往往不是改哪行配置，而是分不清错误到底来自网络层、认证层还是密码哈希层。日志里那句 connection matched pg_hba.conf line 83 比任何猜测都管用。
