navicat sql格式化没反应，90%因未启用“enable sql formatting”且未重启软件；需在tools→options→editor→sql formatting（windows）或navicat→preferences→editor→sql formatting（macos）中勾选并重启，快捷键仅在sql编辑器标签页有效，且受焦点、输入法、系统快捷键冲突及语法错误影响。
navicat 的 sql 格式化没反应，90% 是因为根本没开开关——enable sql formatting 没勾选，或者勾了但没重启软件。
格式化快捷键（Ctrl+Shift+F 或 Cmd+Shift+F）完全没反应
这不是快捷键冲突或软件崩溃，而是功能压根没启用。
- 路径必须是：
Tools → Options → Editor → SQL Formatting（Windows）或Navicat → Preferences → Editor → SQL Formatting（macOS），然后勾选Enable SQL formatting - 勾完必须重启 Navicat，热加载不生效——这是最常被跳过的一步
- 快捷键只在「SQL 编辑器」标签页内有效；如果焦点在结果页、表结构页、对象树上，按了也白按
- macOS 用户注意：
Ctrl+Shift+F默认被系统 Spotlight 占用，要进系统设置 → 键盘 → 快捷键 → Spotlight，关掉或改键位；更稳妥的是在 Navicat 里自定义成Cmd+Shift+F并取消勾选Use system shortcut
右键菜单里“Format SQL”变灰或不可点
说明当前上下文不支持格式化，常见于以下场景：
- 你正在「Command Line」模式下写 SQL —— 这个模式不走编辑器引擎，格式化功能完全不可用
- 光标落在查询结果表格里，或刚双击打开一个视图/存储过程的「Data」页，而非新建的
New Query编辑窗口 - SQL 编辑区里有语法错误（比如漏括号、单引号没闭合），Navicat 的格式化器会直接放弃解析，连菜单都禁用
- 连接类型和当前 SQL 方言不匹配：比如连的是 MySQL，但写了 PostgreSQL 特有的
"col_name"双引号语法，格式化器可能拒绝处理
格式化后代码看起来更乱，或关键字大小写/缩进不对
不是 bug，是参数没对齐你的习惯，Navicat 不会自动适配团队规范。
-
Indent width设成 2 或 4，别留空或填 8——嵌套 JOIN 后代码会滑出屏幕 -
Wrap after N characters建议设为 80～100；默认 0 表示不限宽，长 WHERE 条件就全挤一行 - 关键字大小写由
Uppercase keywords控制，不勾就是保持原样；勾了但还是小写？检查是否误选了Lowercase keywords或数据库类型识别错（比如连 MySQL 却用了 PostgreSQL 规则） - 字段全挤在一行？确认没勾
Merge simple statements，并打开Put each clause on new line和Align multiple conditions
格式化后执行报错，或 hint / 反引号丢失
Navicat 格式化不是纯文本重排，它会解析语法树，某些改动会破坏语义：
-
/*+ USE_INDEX(t1 idx_a) */这类 Oracle/MySQL hint 容易被换行或删空格截断，导致优化器忽略 - 含空格或关键字的标识符如
`order`，格式化有时漏掉反引号，变成order触发语法错误 - UNION 前后子查询字段类型不一致时，格式化重排可能暴露隐式转换问题（比如
INT和VARCHAR并列） - 批量格式化需求别硬扛：Navicat 不支持文件夹级处理，也不开放命令行调用；真要批量处理，用
pg_format（PostgreSQL）、sqlparse（Python）或sqlfmt更可靠
最容易被忽略的点：格式化配置存放在 sql_format.xml 文件里，缓存损坏或该文件被系统设为只读时，GUI 上调的参数可能根本不生效——删掉它再重启，比反复点设置更有效。
