SQL Server 中用 FOR JSON 生成标准 JSON 结构

从SQL Server 2016开始，原生就支持JSON输出了，`FOR JSON` 是最直接的办法。它能把查询结果乖乖转成合法的JSON字符串，完全不用你费心去手动拼接或者加引号。 要说关键区别，就在 `AUTO` 和 `PATH` 这两种模式上。`AUTO` 模式会自动推导嵌套结构，但字段别名里要是带了点号，它就不灵了。而 `PATH` 模式就灵活得多，它支持自定义键名、嵌套对象和数组。举个例子，`SELECT name AS 'user.name' FOR JSON PATH` 这行代码，就能生成 `{"user": {"name": "xxx"}}` 这样的结构。 * 如果你希望根节点是一个对象而不是数组，那就加个 `WITHOUT_ARRAY_WRAPPER`。 * NULL值默认会被忽略，如果想让它们显示为 `"key": null`，就得加上 `INCLUDE_NULL_VALUES`。 * 有一点要注意，字符串里的换行、双引号、反斜杠这些特殊字符，`FOR JSON` 会自动帮你转义，保证符合JSON规范。

MySQL 8.0+ 用 JSON_OBJECT 和 JSON_ARRAYAGG 拼装结构

MySQL这边的情况就有点不同了，它没有 `FOR JSON` 这么方便的语法，得靠函数组合。单行转对象用 `JSON_OBJECT(key1, val1, key2, val2)`；多行聚合为数组的话，就必须嵌套 `JSON_ARRAYAGG` 和子查询。 实践中常见的坑是漏掉子查询的括号，或者误用了 `GROUP BY`。比如你想返回一个用户列表，结果在外部查询加了 `GROUP BY id`，那就会导致每行生成一个数组，而不是整个结果变成一个数组。 * 使用 `JSON_OBJECT` 时，key必须是字符串字面量或者列别名，不能是表达式。 * 想嵌套对象就得写两层子查询，比如 `SELECT JSON_OBJECT('users', JSON_ARRAYAGG(...))`。 * 字段值是NULL的时候，`JSON_OBJECT` 会直接跳过这个键。如果想保留它，得先用 `COALESCE(col, 'null')` 或者加个额外的判断。

PostgreSQL 用 row_to_json 和 json_agg 避免类型隐式转换问题

PostgreSQL的JSON函数看起来挺简洁，但容易因为数据类型问题触发隐式转换失败。比如，直接把 `timestamp with time zone` 类型的数据塞进 `json_build_object`，很可能会报错“cannot cast type timestamptz to json”。 稳妥的做法是显式地转成字符串：`to_char(created_at, 'YYYY-MM-DD"T"HH24:MI:SS.USZ')`，或者用 `row_to_json` 来处理整行记录，它会自动处理好类型。 * `json_agg` 对空结果集会返回 `NULL`，而不是空数组 `[]`。最好包装一下：`COALESCE(json_agg(...), '[]'::json)`。 * 如果字段名里包含大小写或特殊字符，在PostgreSQL里用双引号包裹别名（比如 `SELECT col AS "userName" FROM t FOR JSON`）不生效，得靠 `json_build_object` 来处理。 * 这里有个性能小技巧：避免在 `json_agg` 内部直接多次调用 `json_build_object`，性能会比先 `SELECT ... AS j` 再 `json_agg(j)` 的方式差不少。

存储过程中输出 JSON 时绕开 PRINT 和 SELECT 的陷阱

存储过程最终是要供给API调用的，所以就不能依赖 `PRINT`（它只输出到消息窗口）或者裸 `SELECT`（可能带回多结果集和列元数据）。正确的做法是使用 `OUTPUT` 参数，或者通过单个 `SELECT` 返回纯JSON字符串。 拿SQL Server举例，你可以声明一个 `@json NVARCHAR(MAX)` 变量，然后用 `SELECT @json = ... FOR JSON ...` 来赋值，最后用 `SELECT @json AS result` 返回。MySQL这边则需要确保最终只有1行1列的结果，且类型是 `TEXT` 或 `JSON`。 * 不要在这个过程中用多个 `SELECT`，否则API客户端可能只取到第一个结果集。 * PostgreSQL的存储过程（`FUNCTION`）必须声明返回类型为 `json` 或 `jsonb`，并且末尾用 `RETURN` 语句。 * 在所有数据库中，如果JSON字符串长度超过4000字符，一定要检查变量类型是否为 `NVARCHAR(MAX)`/`TEXT`，否则会被截断。 最容易被忽略的问题其实是字符编码和BOM。有时候客户端解析失败，就是因为SQL Server默认用UTF-16编码输出，而API那边期望的是UTF-8。这时候就得在应用层转码，或者改用 `CONVERT(VARCHAR(MAX), @json) COLLATE Latin1_General_BIN2` 强制转换成字节流来处理。