SQL Server 2016+ 用 FOR JSON PATH 可直接生成标准 JSON 字符串，自动转义、类型区分、NULL 处理及 ISO 日期格式；PATH 比 AUTO 更灵活可控，嵌套需子查询配合 AS 别名或 WITHOUT_ARRAY_WRAPPER 控制结构。
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 值默认被忽略，加
INCLUDE_NULL_VALUES才保留"key": null - 注意：字符串中的换行、双引号、反斜杠会被自动转义，符合 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) - 若字段名含大小写或特殊字符，用双引号包裹别名：
SELECT col AS "userName" FROM t FOR JSON在 PG 不生效，得靠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 强制字节流处理。
