本文探讨在 go 中对 sql（及类 sql）字符串进行语法感知式格式化的实用方法，涵盖基于关键字的轻量处理、缩进逻辑设计，并重点指出——真正可靠的格式化必须依赖专业 sql 解析器，而非正则或字符串分割。
在 Go 中对 SQL 字符串进行格式化（如将一行语句转为多行、大写关键字、智能缩进），看似可通过简单字符串操作实现，但实际面临显著局限。例如，对如下语句：
select col1, col2, col3 from foo where col1 > 1000 and col2 < 2000
一种常见思路是按 SQL 关键字（SELECT、FROM、WHERE、AND、OR 等）切分，并在每个关键字前插入换行符，再对 AND/OR 等逻辑连接词额外添加缩进：
package main
import (
"regexp"
"strings"
)
func simpleSQLFormat(sql string) string {
sql = strings.ToUpper(sql)
// 在关键字前插入换行（保留空格避免连写）
re := regexp.MustCompile(`\s+(SELECT|FROM|WHERE|GROUP BY|ORDER BY|HAVING|LIMIT|OFFSET|INSERT INTO|UPDATE|DELETE FROM|BEGIN|END|IF|ELSE)\b`)
sql = re.ReplaceAllString(sql, "\n$1")
// 对 AND/OR 前加缩进（需确保不在字符串或注释内——此处不处理！）
sql = regexp.MustCompile(`\s+AND\b`).ReplaceAllString(sql, "\n AND")
sql = regexp.MustCompile(`\s+OR\b`).ReplaceAllString(sql, "\n OR")
return strings.TrimSpace(sql)
}⚠️ 但该方法存在根本性缺陷：
- 无法识别字符串字面量（如 'WHERE col1 = "SELECT"' 中的 SELECT 不应被格式化）；
- 忽略注释（-- SELECT ... 或 /* FROM */）；
- 无法处理嵌套结构（如 BEGIN/END 块、子查询、条件分支），导致缩进层级错误；
- 对括号匹配、逗号分隔、函数调用等语法元素完全无感知。
正如问题中所示的嵌套逻辑：
if (1 > 0) begin if (2 > 1) begin select * from foo end end
仅靠关键字替换无法推导出正确的缩进层级——begin 的嵌套深度需动态跟踪，而 end 必须与对应 begin 匹配，这已属于上下文相关语法分析范畴。
✅ 正确解法：使用成熟的 SQL 解析器
Go 生态中已有经过生产验证的 SQL 解析库，推荐：
- github.com/xwb1989/sqlparser（原 vitess/sqlparser 的社区维护分支）：支持 MySQL 语法，提供 AST（抽象语法树）遍历能力，可自定义格式化逻辑；
- github.com/lfittl/pg_query_go（PostgreSQL 专用，基于 libpg_query）：高精度解析，适合 PostgreSQL 场景。
以 sqlparser 为例，可构建结构化格式化器：
import (
"fmt"
"github.com/xwb1989/sqlparser"
)
func formatSQL(sql string) (string, error) {
stmt, err := sqlparser.Parse(sql)
if err != nil {
return "", err
}
// 此处可递归遍历 stmt（如 *sqlparser.Select),
// 按节点类型插入换行/缩进，保证语义正确性
return sqlparser.String(stmt), nil // 默认 String() 已含基础格式化
}? 提示：sqlparser.String() 默认输出已具备基本换行与缩进，若需自定义风格（如强制大写、特定缩进宽度），可实现 sqlparser.SQLNode 接口的 Format 方法，或封装 sqlparser.TreePrint 进行深度控制。
总结：
- ✅ 轻量场景（单层、无嵌套、无引号/注释）可用正则+关键字规则快速原型；
- ⚠️ 任何生产级需求（兼容性、健壮性、可维护性）都应基于 AST 解析；
- ❌ 避免“状态机式字符串扫描”——它终将在复杂 SQL（CTE、窗口函数、JSON 操作、嵌套 DML）前失效。
选择合适解析器，是对 SQL 格式化任务最专业、最可持续的技术决策。
