SQL Formatter 详解：让你的代码更整洁 – wiki基地

作者： /

SQL Formatter 详解：让你的代码更整洁

在软件开发的世界里，代码不仅仅是实现功能的指令集，它也是开发者之间交流思想的载体。干净、易读的代码能极大地提升开发效率、降低维护成本并促进团队协作。虽然我们经常强调应用代码（如 Java, Python, C#）的风格和规范，但数据库交互的核心——SQL 代码的整洁性却常常被忽视。

你是否曾面对过这样一堆 SQL 代码：

sql
select id,name,age from users where status='active' and creation_date > '2023-01-01' order by creation_date desc limit 10;

或者这样的：

sql
SELECT
o.order_id, c.customer_name, oi.product_id, oi.quantity, oi.price
FROM
orders o
JOIN
customers c ON o.customer_id = c.customer_id
JOIN
order_items oi ON o.order_id = oi.order_id
WHERE o.order_date >= '2023-01-01' AND c.location = 'New York'
ORDER BY o.order_date DESC, o.order_id ASC;

第一段代码虽然能执行，但挤成一团，难以快速阅读和理解。第二段代码稍好，但缩进、换行、大小写等风格可能并不统一，特别是在多人协作的项目中，每个人的习惯差异会导致代码风格五花八门的“大杂烩”。

混乱的 SQL 代码不仅影响个人开发效率，更是团队协作和项目维护的“隐形杀手”。理解他人的代码变得困难，调试复杂查询如同大海捞针，合并代码时冲突频发，新成员加入时学习成本高企。

正是为了解决这些问题，SQL Formatter（SQL格式化工具）应运而生。它们就像一位专业的代码整理师，能够按照预设或自定义的规则，自动将杂乱无章的 SQL 代码重新排版，使其结构清晰、风格统一、易于阅读和维护。

本文将深入探讨 SQL Formatter 是什么、为什么重要、它是如何工作的、它有哪些核心功能、有哪些流行的工具可供选择，以及如何利用它让你的 SQL 代码真正实现“整洁”。

第一部分：混乱的代价——为什么不规范的 SQL 代码是“定时炸弹”？

在深入了解 SQL Formatter 之前，我们首先需要深刻认识到 SQL 代码整洁性的重要性，以及混乱代码带来的潜在风险和高昂代价。

  1. 可读性差，理解成本高： 这是最直接的问题。没有统一的缩进、换行和大小写规则，关键字、表名、列名、条件混杂在一起，眼睛需要费力地扫描和解析。理解一个简单的查询尚且不易，更不用说面对数百甚至数千行的存储过程或复杂视图定义了。理解成本高直接导致开发效率低下。
  2. 调试困难，错误率增加： 当查询返回错误结果或性能不佳时，你需要仔细检查 SQL 代码。杂乱无章的排版会隐藏逻辑错误、语法错误或潜在的性能问题。例如，一个错误的逗号、一个括号的缺失或一个 JOIN 条件的遗漏，在密集的代码块中很难一眼发现。调试时间成倍增加，引入新的错误的风险也随之提高。
  3. 协作障碍，风格冲突： 在团队开发中，每个人可能有自己的编码习惯。有人喜欢全部大写关键字，有人喜欢小写；有人喜欢用 Tab 缩进，有人用空格；有人喜欢所有字段写在一行，有人喜欢每个字段占一行。这些差异在提交代码、进行代码评审或合并分支时，会带来大量的风格层面的冲突，分散对代码逻辑本身的关注。
  4. 代码评审效率低下： 代码评审是保证代码质量的重要环节。如果评审者需要花费大量时间去“翻译”或理清代码的结构，就无法专注于逻辑的正确性、效率或安全性。风格问题会淹没真正的逻辑缺陷，降低代码评审的有效性。
  5. 维护噩梦，技术债务： 随着项目的演进，原有的 SQL 代码需要修改、扩展或重构。面对一堆格式不一、难以理解的代码，维护者往往无从下手，甚至不敢轻易修改，导致代码逐渐僵化，形成技术债务。长此以往，系统的迭代速度会受到严重影响。
  6. 新人上手困难： 新加入团队的成员需要快速熟悉项目代码。如果项目的 SQL 代码库风格混乱，新人不仅要学习业务逻辑和数据库结构，还要适应各种不同的编码风格，这无疑增加了学习曲线和适应时间。
  7. 影响专业形象： 虽然这看似是次要因素，但整洁规范的代码往往反映了开发者对细节的关注和专业的态度。相反，混乱的代码可能会给人留下不专业、不负责任的印象。

认识到这些问题后，我们可以看到，SQL 代码的整洁性并非可有可无的“面子工程”，而是直接关系到开发效率、代码质量、团队协作和项目长期健康发展的基石。而 SQL Formatter 正是解决这些问题的关键工具。

第二部分：解决方案——什么是 SQL Formatter？

SQL Formatter，顾名思义，是一种用于格式化 SQL 代码的工具。它的核心功能是接收一段原始的 SQL 代码字符串，根据一套预设的或用户配置的规则，对其进行解析、重排，最终输出一段格式规范、结构清晰的新 SQL 代码字符串。

简单来说，SQL Formatter 的作用就是：

  • 统一风格： 确保所有 SQL 代码遵循相同的缩进、换行、大小写、间距等规则。
  • 提高可读性： 通过合理的排版，让 SQL 代码更容易被人类阅读和理解。
  • 自动化处理： 将原本需要手动进行的格式化工作自动化，节省时间和精力。

SQL Formatter 并非简单的文本替换工具。它需要理解 SQL 语言的语法结构，能够区分关键字、标识符（表名、列名、别名）、操作符、常量、注释等不同元素，并基于这些元素的类型和它们在语句中的位置来应用格式化规则。

你可以将 SQL Formatter 类比为文本编辑器中的“代码整理”功能，但它通常更加强大和灵活，特别是对于复杂且语法多样的 SQL 语言。

第三部分：幕后工作——SQL Formatter 如何实现格式化？

虽然不同的 SQL Formatter 工具实现细节可能有所差异，但其基本工作流程通常遵循以下步骤：

  1. 词法分析（Lexical Analysis / Tokenization）：

    • Formatter 首先将输入的 SQL 代码字符串分解成一系列被称为“词法单元”（Tokens）的基本构建块。
    • 这些 Tokens 代表了 SQL 语句中的最小有意义单位，例如关键字 (SELECT, FROM, WHERE)、标识符 (users, id, customer_name)、操作符 (=, >, AND, JOIN)、常量 ('active', 10)、标点符号 (,, ;, (, )) 等。
    • 在这一步，Formatter 会识别并忽略空白字符（空格、制表符、换行符）和注释，但会记录它们的位置信息，以便在后续步骤中重新生成。

  2. 语法分析（Syntactic Analysis / Parsing）：

    • 词法分析的结果——Tokens 序列被输入到语法分析器。
    • 语法分析器根据 SQL 语言的语法规则，检查 Tokens 序列是否构成一个合法的 SQL 语句，并构建一个层次化的结构来表示语句的语法结构。这种结构通常被称为抽象语法树（Abstract Syntax Tree / AST）。
    • AST 以树状结构表示了 SQL 语句的组成部分及其相互关系，例如一个 SELECT 语句可能包含一个 SELECT 列表、一个 FROM 子句、一个 WHERE 子句等，这些子句又包含更小的元素。AST 剥离了原始代码的具体文本格式，只保留了其逻辑结构。

  3. 应用格式化规则（Applying Formatting Rules）：

    • Formatter 遍历或操作构建好的 AST。
    • 根据预设的或用户自定义的格式化规则，Formatter 决定如何在 AST 的各个节点（代表语句的不同部分）之间插入空白字符、换行符，以及如何处理大小写。
    • 规则可能包括：
      • 在每个关键字 (SELECT, FROM, WHERE, JOIN, etc.) 后强制换行。
      • 根据层级（如子查询、CASE 语句）使用特定数量的空格或 Tab 进行缩进。
      • 将关键字转换为大写或小写。
      • 在操作符 (=, >, <) 周围添加空格。
      • 在逗号 (,) 后添加空格。
      • 对齐 SELECT 列表中的列名或 WHERE 子句中的条件。
      • 处理注释的缩进和位置。

  4. 生成格式化后的代码（Code Generation）：

    • Formatter 根据应用了格式化规则的 AST，重新生成一个 SQL 代码字符串。
    • 这个新的字符串包含了与原始代码相同的逻辑功能，但具有规范统一的排版风格。

整个过程是自动化的，用户只需提供原始的 SQL 代码和选择（或配置）格式化规则，Formatter 就能快速输出整洁的代码。理解这个过程有助于我们更好地利用 Formatters，并在遇到问题时进行排查（例如，某些格式化效果不符合预期，可能是规则配置或解析问题）。

第四部分：核心功能——SQL Formatter 能做什么？

一个功能完善的 SQL Formatter 通常提供以下核心能力：

  1. 缩进控制：

    • 最基本的功能。能够根据语句的结构层级（如 SELECT 列表、FROM 子句、WHERE 条件、子查询、CASE 语句等）自动添加适当的缩进。
    • 支持使用空格或 Tab 进行缩进，并可配置缩进的宽度（每级缩进多少空格）。
    • 处理多行语句的悬挂缩进（hanging indentation）。

  2. 大小写规范：

    • 控制 SQL 关键字 (SELECT, FROM, WHERE 等) 的大小写（全部大写、全部小写、首字母大写等）。
    • 控制 SQL 内置函数 (COUNT(), SUM(), MAX() 等) 的大小写。
    • 部分 Formatters 还支持对用户定义的标识符（表名、列名、别名）应用大小写规则，但这通常需要更复杂的配置或不太常用，因为标识符可能区分大小写或遵循特定的命名规范。

  3. 间距处理：

    • 在操作符 (=, >, <, +, -, *, /) 周围添加或移除空格。
    • 在逗号 (,) 后强制添加空格。
    • 在括号 () 内添加或移除首尾空格。
    • 处理 SQL 语句中不必要的连续空格。

  4. 换行规则：

    • 在关键的 SQL 子句之间添加换行符（如 SELECT 后、FROM 后、WHERE 后、JOIN 的 ON 条件后、GROUP BY 后、ORDER BY 后等）。
    • 控制 SELECT 列表中的每个列是否单独占一行。
    • 控制 WHERE 子句中的每个条件是否单独占一行，以及如何处理 AND/OR 的位置。
    • 处理 JOIN 子句的换行和缩进。

  5. 对齐能力：

    • 高级功能。能够尝试对齐 SELECT 列表中的列名，使其纵向对齐。
    • 对齐 SET 语句中的赋值号 (=)。
    • 对齐多行 VALUES 列表中的值。

  6. 注释处理：

    • 保留行内注释 (--) 和块注释 (/* ... */)。
    • 根据代码的缩进调整注释的缩进。
    • 有些工具可以配置是否将行内注释移动到代码行的末尾或代码块的上方。

  7. 支持多种 SQL 方言：

    • 不同的数据库系统（MySQL, PostgreSQL, SQL Server, Oracle, SQLite 等）在语法上存在差异。优秀的 Formatter 需要能够识别并正确处理这些方言的特性。
    • 例如，支持特定的函数、语法结构或注释风格。

  8. 可配置性强：

    • 允许用户通过配置文件或命令行参数自定义格式化规则，以适应不同的项目需求或团队风格。这通常是 Formatter 的核心价值所在。

  9. 集成选项：

    • 提供不同的使用方式，如在线工具、IDE/编辑器插件、命令行接口 (CLI)、编程库/API，以便集成到不同的开发工作流程中。

通过这些功能，SQL Formatter 能够将原本难以卒读的 SQL 代码转化为结构清晰、赏心悦目的规范代码，从而带来显著的效率和质量提升。

第五部分：使用 SQL Formatter 的好处——不只是“看着舒服”

使用 SQL Formatter 的价值远不止于让代码“看着舒服”。它带来的好处是多方面的，并且对个人和团队都有深远影响：

  1. 显著提升代码可读性：

    • 这是最直接的好处。规范的缩进和换行让语句结构一目了然。
    • 统一的大小写让关键字和标识符易于区分。
    • 恰当的间距让代码不再拥挤，扫描速度更快。
    • 理解复杂查询所需的时间大大缩短。

  2. 强制执行编码规范，确保团队风格一致：

    • 手动维护团队编码规范是困难的，总会有人忘记或忽略。
    • Formatter 可以自动化这一过程，每次提交或保存时自动应用规范。
    • 团队成员无需花费精力去记住或检查格式细节，可以将精力集中在代码逻辑上。
    • 新成员可以快速融入，无需额外学习团队的排版习惯。

  3. 减少人为错误：

    • 手动格式化容易出错，比如多输入或少输入空格、Tab 和空格混用、错误的换行等，这些错误虽然不影响执行，但会影响可读性。
    • 更重要的是，清晰的代码结构本身有助于发现潜在的逻辑错误。例如，对齐的 WHERE 条件更容易发现 AND 或 OR 的逻辑问题。

  4. 加速代码评审流程：

    • 当代码风格统一时，评审者可以忽略格式问题，直接聚焦于代码的正确性、效率、安全性和业务逻辑。
    • 评审意见将更有价值，评审过程将更高效。
    • 合并代码时，由于格式统一，减少了因纯粹格式差异引起的冲突。

  5. 提高调试效率：

    • 在调试过程中，清晰的排版能够帮助开发者更快地定位问题代码行。
    • 特别是对于复杂的存储过程或动态 SQL，格式化后的代码更便于单步调试和理解执行流程。

  6. 降低长期维护成本：

    • 随着项目的演进和团队成员的变动，历史代码的维护变得越来越重要。
    • 格式规范的代码库更易于被后人理解和修改，降低了维护难度和风险。
    • 减少了技术债务的积累速度。

  7. 促进自动化工作流：

    • 命令行工具和编程库使得 SQL Formatter 可以轻松集成到开发者的本地开发环境（如使用 Git Hook 在提交前自动格式化）和持续集成/持续部署 (CI/CD) 流水线中（如作为代码质量检查的一部分）。
    • 可以在 CI/CD 流程中添加一个步骤，检查提交的 SQL 代码是否符合格式规范，如果不符合则阻止合并或给予警告。

总而言之，SQL Formatter 是一种强大的工具，它将繁琐的手动格式化工作自动化，释放了开发者的精力，提升了代码质量、团队协作效率和项目可维护性。投资于 SQL Formatter 的使用和推广，是提升整个开发流程专业度和效率的重要一步。

第六部分：流行工具介绍——选择你的 SQL 代码整理师

市面上有许多不同类型的 SQL Formatter 工具，它们在使用方式、支持的方言、可配置性等方面有所差异。以下是一些常见且流行的 SQL Formatter 选项：

  1. 在线 SQL Formatter：

    • 特点： 无需安装，打开网页即可使用，方便快捷，适合临时格式化一小段代码。
    • 缺点： 通常功能相对简单，可配置性有限，安全性需注意（不要格式化敏感数据），无法集成到自动化工作流。
    • 示例：
      • Poor Man’s T-SQL Formatter (Online Version): 专注于 T-SQL (SQL Server)，功能强大，配置选项多。
      • SQL Format (sqlformat.darrenjones.org): 支持多种方言，界面简洁。
      • dpFormatter (db-fiddle.com 内嵌): 许多在线 SQL 编辑器或分享网站（如 DB Fiddle）都内置了格式化功能。

  2. IDE/编辑器插件：

    • 特点： 与开发环境深度集成，提供快捷键、保存时自动格式化等功能，用户体验流畅。是日常开发中最常用的方式。
    • 缺点： 功能和支持的方言取决于具体的插件实现。
    • 示例：
      • VS Code 扩展: 有大量可用的 SQL 格式化扩展，如 “SQL Formatter” (多种后端，包括 sql-formatter 库)、”SQLTools” (一个数据库工具集，包含格式化功能)、”pgFormatter” (专注于 PostgreSQL)。
      • JetBrains IDEs (IntelliJ IDEA Ultimate, DataGrip): 内置强大的 SQL 编辑器和格式化功能，支持多种数据库，可高度配置。
      • SQL Developer (Oracle): 内置格式化功能。
      • SQL Server Management Studio (SSMS): 可以安装第三方插件，如 Poor Man’s T-SQL Formatter 的 SSMS 插件。
      • DBeaver: 跨平台数据库工具，内置格式化功能。

  3. 命令行工具 (CLI)：

    • 特点： 适合脚本化、自动化处理，易于集成到版本控制钩子 (Git Hooks)、持续集成 (CI) 流水线中，批量处理文件。
    • 缺点： 需要在命令行环境下使用，不如 IDE 插件直观。
    • 示例：
      • sqlfluff: 一个现代、强大的 SQL Linter 和 Formatter。支持多种方言，高度可配置，有规则检查能力，非常适合集成到 CI/CD 中进行代码质量把控。支持作为 Python 库使用。
      • pgFormatter: 专注于 PostgreSQL 的 Formatter，功能强大，历史悠久，广泛使用。也支持命令行使用。
      • sqlfmt: 另一个 Python 实现的 Formatter，设计理念是提供一种“不妥协”的、强制性的格式化风格，减少配置项。
      • 一些在线 Formatter 或库也提供了 CLI 版本。

  4. 编程库/API：

    • 特点： 可以在自己的应用程序中调用格式化功能，例如构建一个定制的数据库工具或自动化脚本。
    • 示例：
      • 许多 CLI 工具（如 sqlfluff）同时也是可用的编程库。
      • sql-formatter (Node.js 库) 或 sqlparse (Python 库) 等提供了解析和格式化 SQL 的 API。

如何选择合适的工具？

  • 考虑你主要使用的数据库方言： 有些工具专注于特定方言（如 pgFormatter for PostgreSQL, Poor Man’s for T-SQL），它们可能对该方言的支持更全面。通用的 Formatter (如 sqlfluff, JetBrains 内置) 通常支持多种主流方言。
  • 考虑你的工作流程： 如果主要在 IDE 中写代码，那么 IDE 插件最方便。如果需要自动化检查或批量处理，CLI 工具是更好的选择。如果需要构建自己的工具，则选择提供 API 的库。
  • 考虑团队协作： 如果是团队使用，选择一个支持配置文件且易于在团队成员之间共享配置的工具（如 sqlfluff），并考虑集成到版本控制和 CI 中强制执行。
  • 可配置性和功能： 不同的工具在规则的丰富度和可配置性上有所差异。评估哪些格式化规则对你的团队最重要。sqlfluff 通常在可配置性和 linting 功能方面表现突出。

理想情况下，一个团队可能会结合使用多种工具：开发者在 IDE 中使用插件进行即时格式化；团队在代码仓库中配置一个 CLI 工具（如 sqlfluff）并结合 Git Hook 或 CI 检查来确保最终提交的代码符合规范。

第七部分：落地实践——建立并执行团队 SQL 风格指南

仅仅使用 SQL Formatter 是不够的，最重要的是建立并执行一套团队共享的 SQL 编码风格指南。Formatter 是实现风格指南的工具，而风格指南本身定义了“什么是规范的”。

1. 为什么需要风格指南？

  • Formatter 是可配置的： 大多数 Formatter 允许自定义规则。没有风格指南，每个团队成员可能会配置不同的规则，反而引入新的不一致。
  • Formatter 有其局限性： Formatter 主要处理代码的物理排版，但无法解决所有的风格问题，例如：
    • 命名规范（表名、列名、视图、存储过程的命名规则）。
    • 别名使用规则（何时使用、如何命名）。
    • 注释的最佳实践（何时写注释、注释格式）。
    • 查询结构的逻辑风格（如是否允许 SELECT *，子查询的使用方式）。
    • SQL 语句的效率和最佳实践（如 JOIN 类型选择、索引考虑等，这更偏向于 Linting）。
  • 统一的理解： 风格指南是团队成员对“好”SQL 代码的共同理解和约定。

2. 如何建立团队 SQL 风格指南？

  • 参考现有规范： 不要从零开始。许多大型公司或社区（如 PostgreSQL, MySQL, Google）都有公开的 SQL 风格指南，可以作为起点。
  • 讨论并达成一致： 团队成员一起讨论关键的风格点（例如，关键字是否大写？缩进使用空格还是 Tab？JOIN 的 ON 条件是否换行？），并投票或协商决定。
  • 文档化： 将达成的风格规则清晰地记录在文档中，供所有团队成员参考。
  • 配置 Formatter： 根据风格指南，配置你选择的 SQL Formatter 工具。将其配置存储在项目仓库中（例如 .sqlfluff 文件），确保所有团队成员使用相同的配置。
  • 持续演进： 风格指南不是一成不变的，可以在实践中根据需要进行调整和完善。

3. 如何执行风格指南？

  • 本地集成：
    • 鼓励或要求团队成员在本地开发环境（IDE）中安装并配置好 Formatter 插件，并开启保存时自动格式化功能。
    • 使用 Git Hook（例如 Pre-commit Hook）在代码提交前自动运行 Formatter 检查或修复代码格式。这能防止不规范的代码被提交到仓库。可以使用 pre-commit 这样的工具来管理 Hook。
  • 持续集成 (CI) 集成：
    • 在 CI 流水线中添加一个步骤，使用命令行 Formatter 工具（如 sqlfluff lint 或 sqlfluff fix --check-only）检查提交的代码格式是否符合规范。
    • 如果检查失败（即代码格式不规范），则构建失败，阻止代码合并到主分支。这提供了最终的保障。
    • sqlfluff 不仅能格式化，还能进行 Linting（代码质量检查），可以同时检查风格和一些潜在的逻辑或效率问题。

通过建立清晰的风格指南并将 Formatter 集成到开发和 CI 工作流中，团队可以有效地确保 SQL 代码始终保持整洁和规范，从而真正享受到 Formatter 带来的各项好处。

第八部分：潜在的挑战与注意事项

虽然 SQL Formatter 好处多多，但在引入和使用过程中也可能遇到一些挑战：

  1. 过渡期的不适应：
    • 如果团队之前没有统一的风格，初次引入 Formatter 可能会改变一些开发者习惯的排版方式，导致短暂的不适应甚至抵触。
    • 解决办法：充分沟通 Formatters 的好处，让团队成员理解其长期价值。允许一定的适应期。
  2. 配置的复杂性：
    • 一些高级 Formatter 的配置选项非常多，初次配置可能需要花费一些时间来理解和调整，以完美匹配团队的风格需求。
    • 解决办法：从一个简单的配置开始，逐步根据需要进行调整。参考工具的官方文档和社区示例。
  3. 对特定复杂语法的处理：
    • 对于非常复杂、嵌套层级很深或包含非标准语法的 SQL 查询，某些 Formatter 可能无法生成完美的格式化结果，甚至可能引入错误（尽管这种情况比较少见，且优秀的工具会不断改进）。
    • 解决办法：对于特殊情况，可能需要手动微调。及时向工具的开发者反馈问题，帮助他们改进。
  4. 不能解决所有问题：
    • 再次强调，Formatter 主要处理排版。它不能修复错误的逻辑、低效的查询计划或不安全的行为。它也不能替代代码评审。
    • 解决办法：将 Formatter 视为代码质量工具集中的一环，结合 Linter、性能分析工具和人工代码评审共同提升代码质量。
  5. 版本控制历史的变动：
    • 对整个代码库运行 Formatter 会一次性改变大量文件的格式，导致版本控制历史中出现大块的格式修改提交。
    • 解决办法：在一个独立的提交或分支中进行大规模格式化，并明确说明这是格式化操作。之后的所有提交都应保持格式化状态。最好在项目初期或重构期间进行一次彻底的格式化。

认识到这些潜在的挑战并提前做好准备，可以帮助你更顺利地引入和推广 SQL Formatter。

结论

在现代软件开发中，SQL 代码的整洁性和规范性与应用代码同等重要。混乱的 SQL 代码是效率的杀手、错误的温床、协作的障碍和维护的噩梦。

SQL Formatter 作为一种自动化工具，通过解析 SQL 语法并应用预设或自定义的格式化规则，能够有效地将杂乱的 SQL 代码转化为结构清晰、风格统一、易于阅读和维护的规范代码。它不仅能提升个人开发效率，更能显著提高团队协作效率、加速代码评审、降低调试难度和长期维护成本。

从在线工具的便捷性到 IDE 插件的无缝体验，再到命令行工具在自动化工作流中的强大能力，市面上有丰富的 SQL Formatter 工具可供选择。结合团队的实际情况（使用的数据库方言、开发流程、协作模式），选择合适的工具并建立一套清晰的团队 SQL 编码风格指南，是充分发挥 Formatter 价值的关键。

将 SQL Formatter 集成到你的开发工作流程中，无论是通过 IDE 插件的自动保存格式化，还是通过 Git Hook 在提交前检查，抑或是通过 CI/CD 流水线进行强制检查，都能确保你的 SQL 代码库始终保持在健康、整洁的状态。

投资于 SQL Formatter，就是投资于更高的开发效率、更少的错误、更顺畅的协作和更健康的软件项目。立即行动起来，选择一款适合你的 SQL Formatter，让你的数据库代码从此告别混乱，变得前所未有的整洁！

发表评论

您的邮箱地址不会被公开。 必填项已用 * 标注

滚动至顶部