navicat sql格式化无效主因是未启用开关，需在工具→选项→编辑器→sql格式化中勾选“启用sql格式化”并设为手动模式；再调整换行缩进、关键字大小写、编码及字体等设置。
navicat 里 sql 格式化按钮没反应？检查是否启用了自动格式化开关
navicat 的格式化功能默认是关闭的，不是装上就能用。很多人点 ctrl+shift+f 或右键选“格式化”没反应，其实是根本没打开开关。
- 进入
工具 → 选项 → 编辑器 → SQL 格式化，勾选启用 SQL 格式化 - 确保
格式化模式设为手动（如果设成自动，每次输入分号或换行都会触发，反而干扰编码节奏） - 注意：该设置是全局生效的，切换连接/数据库不会重置
格式化后字段全挤在一行？调整缩进和换行策略
默认配置容易把 SELECT a, b, c FROM t WHERE x = 1 压成单行，可读性差。关键在控制「何时换行」和「缩进层级」。
- 在
工具 → 选项 → 编辑器 → SQL 格式化 → 格式化规则中，重点调这几个：每个字段单独一行、WHERE 子句条件分行、JOIN 条件分行 -
缩进大小建议设为 4，太小看不清嵌套，太大浪费水平空间 - 避免勾选
合并简单语句——它会把INSERT INTO t VALUES (1); SELECT * FROM t;合成一行，破坏语义分隔
MySQL 和 PostgreSQL 的关键字大小写不一致？统一设置关键词风格
Navicat 默认按目标数据库类型适配关键字大小写，但实际协作中常需统一风格（比如团队约定全大写 SELECT、FROM），否则 Git diff 里全是大小写变更。
- 在
SQL 格式化 → 关键字大小写中，选大写或小写，别选保持原样 - 注意：这个设置对函数名（如
COUNT()、TO_CHAR()）也生效，而有些函数在 PG 里大小写敏感（如自定义函数），若格式化后执行报错，先确认是不是把函数名也强行改写了 - 如果连接的是 MySQL，但写的是兼容 PG 的语法（比如用双引号括字段），格式化可能误判关键字——此时建议临时切换连接类型再格式化
格式化后中文注释错位或乱码？检查编辑器编码与字体支持
注释缩进错乱、中文显示为方块或偏移，通常不是格式化逻辑问题，而是编辑器渲染层的编码或字体缺失。
- 确认当前 SQL 编辑器编码为
UTF-8：右下角状态栏点击编码名称切换，避免用GBK打开 UTF-8 文件 - 在
工具 → 选项 → 编辑器 → 字体中，选一个明确支持中文的等宽字体，比如Consolas（Windows）、Monaco（macOS）、或Fira Code（跨平台推荐） - 如果注释紧跟在逗号或括号后（如
name VARCHAR(32) -- 用户名），格式化可能把注释顶到行尾导致换行异常——建议在注释前加空格，或改用/* */块注释
Navicat 的格式化不是黑盒操作，开关、规则、编码、字体四个环节任一卡住，效果就断在半路。最常被忽略的是「格式化模式」开关和「关键字大小写」对函数名的连带影响——这两个点不调好，其余设置调得再细也没用。
