Navicat代码片段在“工具→选项→SQL编辑器→代码片段”中管理，输入前缀（如sel）后按Tab键触发；仅限SQL编辑器生效，不支持换行、高级PG语法，且配置不跨实例共享。
Navicat 的代码片段模板在哪找、怎么触发
navicat 的代码片段（code snippets）不是 postgresql 自带的功能，而是 navicat 客户端的私有快捷补全机制，仅在 navicat 的 sql 编辑器中生效。它不依赖 postgresql 版本，也不影响服务端执行逻辑。
触发方式很简单：在 SQL 编辑器里输入片段前缀（比如 sel），然后按 Tab 键自动展开为 SELECT * FROM ；输入 ins + Tab 展开为插入模板。这些前缀和内容可在 工具 → 选项 → SQL 编辑器 → 代码片段 里查看或自定义。
- 默认片段只覆盖基础 DML（
sel、ins、upd、del），没有with、cte或窗口函数等高级模板 - 新增片段时，变量占位用
$1、$2表示，编辑后需重启 SQL 编辑器才生效 - 片段内容里不能含换行符（Navicat 会把换行转成空格），否则生成的 SQL 可读性差、易出错
为什么改了模板却没反应？常见同步失效场景
Navicat 的代码片段配置是用户级本地文件，路径藏得深，且不同版本位置不同：Windows 下通常在 %APPDATA%\PremiumSoft\Navicat\ 子目录里，macOS 在 ~/Library/Application Support/PremiumSoft/Navicat/。直接改文件不如用界面操作——因为 Navicat 启动时会校验并可能覆盖手动修改的 JSON 或 XML 配置。
- 多实例运行时（比如同时开 Navicat for PostgreSQL 和 Navicat Premium），片段配置不共享，需分别设置
- 使用「连接 → 新建查询」打开的编辑器才加载片段；从「工具 → 命令列」或「数据传输」等模块进的 SQL 窗口不支持
- 片段前缀若与已有的关键字冲突（如设成
select），Tab不会触发，Navicat 默认忽略长度 >4 的前缀或保留字
想复用 PostgreSQL 官方语法特性？别依赖 Navicat 模板
Navicat 的模板本质是静态文本替换，对 PostgreSQL 特有语法（比如 INSERT ... ON CONFLICT、jsonb_set()、分区表 ATTACH PARTITION）完全无感知。它不会帮你补全列名、检查类型兼容性，也不会根据当前连接的 PG 版本调整语法（例如 GENERATED ALWAYS AS IDENTITY 在 10+ 才支持）。
- 写复杂 CTE 查询时，靠
with片段只能补出开头，后续AS (之后全得手敲，容易漏括号或逗号 - 涉及
pg_stat_statements或pg_locks等系统视图时，片段不会提示字段名，补全后还得查文档或右键「描述表」 - 如果团队协作，Navicat 模板无法随项目 Git，也不能导出为标准 SQL 片段（比如 VS Code 的
snippets.json格式）
真正提效的做法：用 psql \set + 自定义脚本替代
PostgreSQL 原生命令行客户端 psql 支持 \set 定义变量、\i 加载外部 SQL 文件，配合 shell 脚本或 Makefile，比 Navicat 模板更可控、可复用、可版本化。
例如，在 ~/.psqlrc 里加：
\set sel 'SELECT $1 FROM $2 WHERE $3'
，之后在 psql 中输入 :sel 就能展开（注意冒号前缀）。再配合 cat query.sql | psql -d mydb，就能把模板注入真实环境。
- 所有变量、路径、SQL 片段都可提交到 Git，新人拉下仓库就能用
-
psql的\copy、\timing、\x等元命令，Navicat 模板根本没法模拟 - 遇到
ERROR: column "xxx" does not exist这类错误时，psql 的错误定位比 Navicat 更准，尤其嵌套子查询场景
Navicat 模板适合临时写几条简单语句，但只要涉及跨环境部署、多人协同或复杂分析逻辑，它的“便利”很快会变成维护负担——毕竟它连 $$ 字符串引号嵌套都处理不了。
