JSON与SQL格式化后怎么验收？类型核对和LEFT JOIN反例

01先验收一份只有五个字段的JSON

下面是虚构配置，便于逐项复查。0012是账号字符串，不能变成数字12；0、false和null也不能因为看起来“没有值”而省略。

1. 1
   打开JSON格式化，粘贴后选择格式化，检查是否得到可读结果。若报语法错误，先检查引号、逗号与括号，不先删除报错字段。
2. 2
   逐字段比较：account为字符串0012、retries为数字0、enabled为布尔false、note为null、tags为按a再b排列的两项数组。空字符串、缺少键和null不是同一状态。
3. 3
   只有目标系统确实需要YAML时，再用JSON/YAML转换生成副本并往返检查。最后交给目标应用的解析器和测试环境验收；不要覆盖原配置或在线上试错。

{"account":"0012","retries":0,"enabled":false,"note":null,"tags":["a","b"]}

02完整SQL反例：一处条件移动，结果从两行变一行

在可丢弃的SQLite测试库运行下面完整脚本，不要对业务库建表。它是编辑设计的两客户样例：A有一笔已付款订单，B没有订单。第二个查询与第一个只改变paid条件的位置。

1. 1
   需要整理查询时，把SELECT语句放入SQL格式化，保留原文与排版后的副本。确认ON、WHERE及引号内容没有被改写。
2. 2
   在同一份测试数据上分别运行两版。Q1应为2行，Q2为1行；若输出把B显示为空白，请确认它代表SQL NULL而不是空字符串。
3. 3
   业务若要求“所有客户及其已付款订单”，使用Q1的含义；若要求“有已付款订单的客户行”，才选择Q2。修复时恢复正确条件位置并重新运行，不能只把缩进改回去。

CREATE TABLE customers (id TEXT PRIMARY KEY);
CREATE TABLE orders (customer_id TEXT, status TEXT);
INSERT INTO customers VALUES ('A'), ('B');
INSERT INTO orders VALUES ('A', 'paid');

-- Q1: keep every customer
SELECT c.id, o.status
FROM customers c
LEFT JOIN orders o
  ON o.customer_id = c.id AND o.status = 'paid'
ORDER BY c.id;

-- Q2: keep only rows with a paid order
SELECT c.id, o.status
FROM customers c
LEFT JOIN orders o ON o.customer_id = c.id
WHERE o.status = 'paid'
ORDER BY c.id;

SQLite的SELECT处理说明解释了外连接补NULL行与WHERE过滤的顺序。这个两行练习不等于对生产查询、权限或执行计划做过验证。

03用一个小配置逐字段检查，别只比较缩进

自编配置为 {"account":"0012","retries":0,"enabled":false,"note":null,"tags":["a","b"]}。格式化或 JSON→YAML→JSON 后，account 必须仍是四位字符串，retries 是数值零，enabled 是布尔假，note 是空值，tags 仍含两个元素且顺序未变。将 account 变成 12、把 false 变成 "false"，都是应用可能感知的变更，不属于纯排版。

JSON/YAML 转换工具解析后重新生成目标格式；它不是原文保存器。YAML 注释、锚点等写法不能当成转换后仍会保留的编辑资料。JSON 对象的键顺序变化也不等于业务值改变，但数组顺序可能有含义。若配置包含签名所需的原始字节，应保留源文件，不要用“解析出来一样”推断字节签名仍有效。

04再加一笔订单：两行结果不等于两个独立客户

在上面的测试库追加一笔A的paid订单，再运行Q1与Q2。Q1应为3行：A两行、B一行；Q2应为2行，都是A。连接输出的单位是匹配行，不是自动按客户去重的人数。若指标要数独立客户，需要先明确计数规则，不能把查询行数直接写进客户报表。

INSERT INTO orders VALUES ('A', 'paid');

当前SQL工具使用通用排版，没有数据库连接或方言选择控件。目标数据库的专有语法、约束和实际返回行需要在对应测试环境验证。

05正则与基础压缩需要最小失败样本

当前正则工具固定使用 g、m、u 标志。用 ^cat$ 匹配“cat”与“Cat”可以检查大小写；它没有 i 标志控件。m 会让行首行尾锚点按行工作，因此还应加入多行样本。界面显示的匹配位置使用 JavaScript 字符串索引，含表情时不要把它当成屏幕上的第几个字形。

JavaScript 工具的反向操作是基础文本压缩，会用正则移除类似注释的片段，并非完整的语言语义压缩。像 const url = "https://example.com/a"; 里的 // 就是必须保护的字符串内容。不要把这种输出当作可直接上线的构建文件；保留源码，使用项目正常构建与测试。CSS 也应检查字符串、URL 和布局，不凭文件变短认定无损。

06输入不同或继续处理时，再选这些工具

• 格式化 JSON: 先处理语法错误再排版，检查 "0012"、12、false 与 null 是否保留预期类型。
• 转换 JSON 与 YAML: 先往返转换嵌套小样本，检查字符串、数组与空值；不要假定注释和 YAML 特有功能都能保留。
• 测试正则表达式: 加入命中、近似但不命中、空输入和多行样本；工具固定使用 g、m、u 标志，在其他场景应用前核对匹配边界。
• 整理 SQL: 本工具使用通用 SQL 格式化，没有方言选择器。单独核对关联与过滤条件，再在目标数据库验证具体语法；排版不会执行查询。
• 整理或压缩 CSS: 保留可编辑源文件，在窄屏和宽屏预览受影响布局；源码变短不代表视觉效果相同。
• 整理 JavaScript: 比较变更源码并运行应用正常检查；基础压缩不保证语义等价，也不代表生产优化已完成。
• 转换网页颜色值: 使用支持的六位 HEX 或整数 RGB 输入；HEX 转换也会显示 HSL。本入口没有透明度控件，也不检查文字对比度。
• 比较环境配置: 检查变量名及新增、删除和变更值；导出审核表时保留遮盖，并另行核对目标环境。

07格式化出错时，按层定位

MDN 说明 JSON 解析与语法错误；解析成功的结论小于应用正确。

结构化输出应分别检查 Schema 和来源证据。 正文与代码围栏混合时，应检查 Markdown 结构。