答案是Navicat默认走本地命名管道触发pg_hba.conf中local行的ident/peer认证，而该认证要求OS用户名与数据库用户名一致，Navicat无法提供；同时旧版Navicat内置libpq.dll不支持scram-sha-256（method 10），需改md5、替换dll或升级至Navicat 16+，并确保用户已设密码。
确认是不是 pg_hba.conf 的 local 行在捣鬼
很多人填对了 127.0.0.1 和密码，却还是被 ident authentication failed 拦住，根本原因常是 navicat 默认走本地命名管道（windows 下等效于 unix socket），触发的是 pg_hba.conf 里以 local 开头的规则——而这一行往往写着 ident 或 peer。
这类认证要求操作系统用户名和数据库用户名完全一致，Navicat 根本无法提供对应凭证。
- 打开
pg_hba.conf（路径类似C:\Program Files\PostgreSQL\17\data\pg_hba.conf） - 找到所有以
local开头的行，把METHOD列从ident或peer改成md5 - 如果同时用
127.0.0.1连，也检查对应host行，确保不是ident或未被客户端支持的scram-sha-256 - 改完必须重启 PostgreSQL 服务（Windows 下通过
services.msc操作），否则配置不生效
Navicat 自带的 libpq.dll 不认识 scram-sha-256
即使 pg_hba.conf 写了 scram-sha-256，只要 Navicat 自带的 libpq.dll 是旧版（比如随 Navicat 12/13/14/15 发布的），它就无法解析 method 10。这不是配置问题，是硬性兼容缺陷。
验证方式：psql -U postgres -h 127.0.0.1 -d postgres 能连上，但 Navicat 连不上 → 基本锁定是客户端驱动问题。
- 临时解法：把
pg_hba.conf对应行的METHOD改成md5（仅限开发/测试环境） - 长期解法：手动替换
libpq.dll——找到 Navicat 安装目录下的plugins\postgresql\（或类似路径），用 PostgreSQL 官方发行包里同版本、同位数（x64 对 x64）的libpq.dll替换它 - 更省事：直接升级到 Navicat 16+，原生支持
scram-sha-256
别漏掉用户密码这个硬性前提
md5 和 scram-sha-256 都要求用户有密码。如果你用 postgres 用户连接，但从来没设过密码，哪怕配置全对，也会静默失败。
执行以下命令为用户设置密码（需用 psql 或其他可连上的客户端）：
ALTER USER postgres PASSWORD 'your_secure_password';
另外注意：若 pg_hba.conf 中存在 host all all 0.0.0.0/0 trust 这类宽泛规则，它可能优先匹配，导致你辛苦改的那行根本没机会生效。
scram-sha-256 认证失败的本质是协议不匹配
PostgreSQL 10+ 默认启用 scram-sha-256（即错误里常出现的 authentication method 10 not supported），但老版 Navicat 内置的 libpq.dll 往往只支持 md5。这不是密码错了，而是客户端根本“听不懂”服务端说的认证语言。
真正容易被忽略的点是：同一台机器上可能同时存在多个 pg_hba.conf 实例（比如不同 PostgreSQL 版本共存），或者修改后忘记重启服务；还有人替换了 libpq.dll 却没注意位数（x86/x64）错配，导致 Navicat 启动失败或报 DLL 加载错误。
