纯html无法实现真正的sql格式化，因其缺乏词法分析能力，必须依赖js库（如sql-formatter）或后端api；仅用textarea+button加简单js只能做正则替换，无法处理引号配对、子查询等复杂语法。
纯 HTML 无法真正做 SQL 格式化工具 —— 它没有解析能力，也不能执行逻辑，所有“HTML 实现的 SQL 格式化”本质都是前端调用 JS 库或后端 API。
为什么不能只用 textarea + button 就完成格式化
常见误解是：把 <textarea></textarea> 输入框、<button onclick="format()"></button> 和几行 JS 拼一起就算“HTML 工具”。但 SQL 格式化需要词法分析（识别 SELECT、FROM、括号嵌套、字符串引号配对等），纯 HTML 标签做不到。浏览器里没内置 sql-formatter 函数，必须引入第三方逻辑。
- 不引入 JS 库（如
sql-formatter、sql.js或pg-structure的轻量 parser）→ 只能做简单正则替换，遇到WHERE name = 'O''Reilly'或子查询就崩 - 不发请求到后端 → 无法支持 PostgreSQL 特有语法（如
LATERAL）、MySQL 窗口函数的深度校验 - 把格式化逻辑硬写进
<script></script>标签里又不打包 → 代码不可维护，升级规则（比如新增关键字大写）就得改 HTML 文件
sql-formatter 是最实用的前端方案
它体积小（gzip 后约 12KB）、零依赖、支持 MySQL/PostgreSQL/SQLite/T-SQL，且暴露清晰的 format() 接口。直接通过 CDN 引入就能用：
<script src="https://cdn.jsdelivr.net/npm/sql-formatter@14.0.0/dist/sql-formatter.min.js"></script>
调用时注意三点：
- 传入原始 SQL 字符串，别漏掉
options参数，否则默认缩进是 2 空格、关键字小写 —— 不符合多数团队规范 - 想让
SELECTFROM大写？得显式设{language: 'mysql', uppercase: true} - 处理含注释或换行符混乱的 SQL 时，先用
.trim()再传入，避免format()内部报SyntaxError: Unexpected token
响应式布局里左右分栏的 DOM 结构陷阱
很多教程用 <div style="display: flex"> 做左右栏，但在 Safari 旧版本或某些移动端 WebView 中，<code>textarea 高度自适应会失效。更稳的做法是：
- 左侧
<textarea></textarea>设flex: 1; min-width: 0;（防止内容撑破容器） - 右侧
<pre class="brush:php;toolbar:false;"></pre>包裹格式化结果，加white-space: pre; overflow-x: auto;保换行和横向滚动 - 禁用
textarea的resize（resize: none;），否则拖拽会破坏双栏比例 - 别用
height: 100vh给父容器 —— 顶部配置栏+底部按钮会挤出视口，改用calc(100vh - 80px)更可靠
自定义缩进和关键字大小写的实际影响
看似只是显示偏好，实则影响协作效率和 CI 检查：
-
indent: ' '（两个空格）是主流，但若团队用 Prettier 统一 JS/SQL，就得设成indent: ' '（四个空格）保持一致 -
uppercase: true对 MySQL 生效，但对 PostgreSQL 的ILIKE或~*运算符无效 —— 它们本身不区分大小写，强制大写反而误导语义 - 开启
linesBetweenQueries: 2后，多个INSERT语句之间会空两行，适合生成迁移脚本；但用于单条查询调试时显得冗余
真正的难点不在“怎么写出来”，而在于：SQL 方言差异比想象中多，sql-formatter 的 language 参数必须精确匹配（比如 'postgresql' 不能简写成 'pg'），否则窗口函数解析会错位。这点容易被忽略，直到上线后发现 ROW_NUMBER() OVER (PARTITION BY x ORDER BY y) 被错误折行。
