Navicat 16 备份不调用 pg_dump，而是通过 libpq 直连逐表 SELECT + 导出 DDL 生成 SQL 文件；不支持 -Fc、-Z、--exclude-table 等 pg_dump 高级参数，生产全量备份应直接使用 pg_dump 命令。
Navicat 16 本身不调用 pg_dump，它走的是 PostgreSQL 协议直连导出
navicat 的「备份」功能不是封装 pg_dump 命令，而是通过 libpq 连接远程数据库，逐表 select 数据 + 导出 ddl，再拼成 sql 文件。这意味着：
- 它无法使用
pg_dump的-Fc（自定义二进制格式）、-Fd（目录并行）、--compress=zstd:3等高级参数 - 不支持
--exclude-table、--inserts、--column-inserts这类精细控制选项 - 导出的 SQL 是纯文本，但语句顺序和权限还原逻辑与
pg_dump -Fp不完全一致，比如角色依赖可能出错 - 若远程服务器未开放
pg_hba.conf中的 replication 权限，Navicat 仍能备份（因为它不用复制协议），但pg_dump某些场景会失败
想真正用 pg_dump 逻辑，就得绕过 Navicat 界面直接执行命令
Navicat 提供了「工具 → 命令行工具」入口，但它默认只打开本地 shell —— 关键是：你得在本地装好与远程 PostgreSQL 版本兼容的 pg_dump（通常来自相同版本的 postgresql-client 包）。
实操要点：
- 确认远程库可被本地
pg_dump访问：pg_dump -h remote_host -p 5432 -U myuser -d mydb -Fp -v -f /tmp/test.sql 2>&1 | head -20，看是否报password authentication failed或connection refused - 若远程 PostgreSQL 版本是 16，本地
pg_dump --version最好也是 16.x；跨大版本（如用 PG 17 的pg_dump备份 PG 15 库）虽能导出，但恢复时可能因语法差异失败 - Navicat 的「导出向导」里选「SQL 文件」后点「高级」，它显示的其实是它自己生成的选项（如“导出数据”“导出结构”），不是传给
pg_dump的参数 —— 别被界面误导
混合使用场景：Navicat 做快速验证，pg_dump 做生产备份
日常开发中可以这样分工：
- 用 Navicat 快速导出单张表或几个视图的定义+前 100 行数据，用于调试或分享逻辑
- 生产环境全量备份必须用
pg_dump -Fc -Z6 -j4 -f backup_$(date +%F).dump mydb，因为：-
-Fc支持pg_restore -t users单表恢复，Navicat 导出的 SQL 不支持 -
-Z6用 zlib 压缩，比 Navicat 默认无压缩的 SQL 小 60%~80% -
-j4并行导出（仅-Fd格式才真正并行，但-Fc在 16+ 版本中也优化了内部锁等待）
-
- 如果 Navicat 连接超时或导出中断，别反复重试 —— 直接切到终端跑
pg_dump，它有更稳定的连接重试和 WAL 安全性保障
容易忽略的关键细节
很多人卡在权限和路径上：
-
pg_dump需要对每个表有SELECT权限，对序列有USAGE，对函数/类型等有EXECUTE—— 如果用普通用户而非postgres超级用户，得提前 GRANT，而 Navicat 界面不会提示缺哪项权限 - 备份文件路径写在本地（
-f /backup/mydb.dump），不是远程服务器路径；误写成-f /var/lib/pgsql/data/backup.dump会导致命令在本地找不到该目录而失败 -
pg_dump默认不导出全局对象（角色、表空间），要用pg_dumpall -g单独备份，Navicat 的「备份整个服务器」功能也做不到这点
真正用好逻辑备份，得接受一个事实：图形工具适合探索，关键任务还得回到命令行和参数本身。
