代码评审前，先保留不可改动的 SQL 原文，再生成一份只用于阅读的格式化副本。排版可以让 JOIN、WHERE、AND 和 OR 不再挤在一行里，却不能证明查询能执行、结果正确或适合生产环境。
先固定原文和这次评审要回答的问题
原始查询应留在版本控制、工单附件或只读文本中，格式化结果不要直接覆盖它。这样一旦换行、大小写或注释位置看起来异常，评审者还能回到明确的基准，而不是在已经改过的副本上继续猜。
例如一段订单查询把客户连接、付款状态、地区限制和日期条件全部写在一行。评审目标不该只是“变得好看”，而应明确回答这些问题：连接键是否正确、筛选条件是否重复、括号有没有改变 AND 与 OR 的组合、参数是否齐全、排序和行数限制是否符合接口约定。
粘贴前还要删除真实姓名、手机号、令牌、连接字符串和内部地址。即使只是代码片段，字符串常量和注释里也可能带有生产数据；无法安全脱敏时，应改用组织批准的本地开发工具处理。
用格式化副本展开关键字，不把它当解析器
把脱敏后的副本贴进 SQL 格式化工具，点击“计算 / 格式化”后再复制结果。当前组件会在常见的 SELECT、FROM、WHERE、GROUP BY、ORDER BY、HAVING、LIMIT、多种 JOIN、AND 与 OR 前换行，并把这些常见关键字改成大写。
组件会先保护常见的单引号、双引号、反引号、方括号标识符、行注释、块注释和 PostgreSQL 风格的美元引号片段。遇到未闭合或无法安全识别的字符串、注释时，它会停止格式化并显示错误，而不是猜一个结尾。
这些保护仍不等于完整 SQL 方言解析。工具没有数据库连接、方言选择、表结构、参数类型、权限上下文或执行计划，也不会运行查询。存储过程、模板占位符、厂商扩展、复杂转义和动态拼接都可能超出简单排版规则；遇到这类输入，应保留原文并交给对应数据库的解析器或 IDE。
按数据流检查 JOIN 和 WHERE，而不是只扫缩进
格式化后先从 FROM 和每个 JOIN 看数据从哪里来，再检查连接条件和筛选条件。排版的价值是把审查点摊开，评审者仍要理解业务关系。
- 核对每个别名只指向一张预期的表，并确认连接键不会把一条订单扩成多条重复记录。
- 逐个检查
WHERE下的状态、日期、租户和软删除条件，特别留意同一条件出现两次或彼此冲突。 - 保留原有括号，确认
A AND (B OR C)没被人工改成(A AND B) OR C。 - 检查外连接右表的条件放在
ON还是WHERE；移动位置可能改变保留空值行的含义。 - 对照参数清单，确认每个占位符都有来源、类型和允许范围，不能因为排版成功就默认绑定正确。
比如活动订单查询里同时出现 o.status = :status 和固定的 o.status = 'paid'，换行后更容易发现冲突，但只有需求说明和调用参数才能决定哪一个应该保留。格式化器不会替评审者做这个业务判断。
用原文比对和目标数据库完成验证
复制结果后，把原文与格式化副本放进文字差异比对查看变化。空格、换行和关键字大小写本来就会产生大量差异，因此重点是逐一核对字符串、注释、参数名、运算符、括号、列名和表名有没有意外改变或丢失。
如果参数单独以 JSON 交付，可以先用 JSON 格式化器确认那份参数文本是有效 JSON；这也不能证明参数类型符合数据库列，或者 SQL 与 JSON 之间的映射正确。两个工具处理的是粘贴文本，不会读取项目文件或写回代码仓库。
合并前还要在目标数据库对应的安全环境中完成语法解析、参数绑定和受控数据测试。对读取查询，检查已知应该包含和排除的记录、边界日期、空值以及重复行；对任何可能写入数据的语句，遵守团队的事务、备份、权限和审批流程，不要在在线格式化页面里试运行。
最后把原文位置、数据库方言与版本、格式化副本、参数定义和验证结果放进评审记录。这样排版只是阅读辅助，不会被误写成“查询已经验证通过”。
常见问题
SQL 格式化工具会连接或修改数据库吗？
不会。当前工具只处理浏览器里粘贴的文本，没有数据库连接、执行按钮、文件写回或表结构读取能力。
格式化成功是否代表 SQL 语法正确？
不代表。简单排版规则能识别部分关键字和字面量边界，但不是目标数据库的完整解析器，语法仍要由对应方言和版本验证。
为什么未闭合的字符串不会继续排版？
继续改写可能破坏字符串或注释内容。组件遇到无法安全闭合的常见片段会停止并报错，评审者应先回到原文查明原因。
可以直接粘贴生产查询和真实参数吗？
不要这样做。先删除令牌、连接字符串、客户数据和内部地址；无法可靠脱敏时，使用组织批准的本地工具。
文字比对没有发现字符丢失就足够了吗？
不够。逐字检查只能覆盖文本变化，无法验证权限、表结构、参数类型、执行计划、并发影响或业务结果，仍要在受控数据库环境中测试。