SQL Server 2016+ 使用 FOR JSON 子句直接返回 JSON，它不是函数而是查询子句，必须紧跟 SELECT 后；FOR JSON AUTO 自动推导层级，FOR JSON PATH 支持点号嵌套（如 user.name），NULL 默认被忽略，需加 INCLUDE_NULL_VALUES 才输出 null。
SQL Server 2016+ 怎么用 FOR JSON 直接返回 JSON？
SQL Server 2016 起原生支持 JSON，FOR JSON 是最轻量、最直接的方案。它不是函数，而是查询子句，必须紧跟在 SELECT 后面，不能单独用在变量赋值或 RETURN 中。
常见错误是写成 SELECT ... FOR JSON PATH 然后试图把结果塞进 RETURN ——RETURN 只接受整数，JSON 必须作为结果集返回。
- 用
SELECT @json = (SELECT ... FOR JSON PATH)提前拼好字符串（适合单行 JSON） - 但更推荐直接
SELECT ... FOR JSON PATH，让客户端接收结果集（兼容性更好，不丢失嵌套结构） -
FOR JSON AUTO自动按表名/别名推导层级，适合简单 JOIN；FOR JSON PATH更灵活，能用点号控制嵌套，比如user.name、address.city - 注意 NULL 值默认被忽略，加
INCLUDE_NULL_VALUES才输出"field": null
MySQL 8.0 怎么用 JSON_OBJECT 和 JSON_ARRAYAGG 拼 JSON？
MySQL 没有类似 FOR JSON 的查询级语法，得靠函数组合。核心是：JSON_OBJECT 构建单对象，JSON_ARRAYAGG 聚合多行成数组，两者嵌套使用。
容易踩的坑是字段别名没加引号或用了保留字，导致 JSON_OBJECT 报错 ERROR 3142；还有聚合时漏写 GROUP BY，让 JSON_ARRAYAGG 把所有行压成一个数组（而不是每组一个）。
- 单行：
SELECT JSON_OBJECT('id', id, 'name', name) FROM user WHERE id = 123 - 多行列表：
SELECT JSON_ARRAYAGG(JSON_OBJECT('id', id, 'name', name)) FROM user - 带关联：先
JOIN再GROUP BY parent.id，然后在外层用JSON_OBJECT包住JSON_ARRAYAGG(child.*) - 性能注意：大结果集下
JSON_ARRAYAGG可能触发group_concat_max_len限制，默认只有 1024 字符，需提前设高（如SET SESSION group_concat_max_len = 1000000）
PostgreSQL 怎么用 row_to_json 和 json_agg？
PostgreSQL 的 JSON 支持最成熟，但函数语义和 MySQL 不同：row_to_json 作用于单行（或子查询结果），json_agg 是聚合函数，对应 MySQL 的 JSON_ARRAYAGG。
典型错误是把 row_to_json(t.*) 直接放在 SELECT 列表里又没加 GROUP BY，导致“column must appear in the GROUP BY clause” —— 实际上你并不总需要 GROUP BY，除非用了聚合函数。
- 单行：
SELECT row_to_json(t.*) FROM (SELECT id, name FROM user LIMIT 1) t - 多行数组：
SELECT json_agg(row_to_json(t.*)) FROM (SELECT id, name FROM user) t - 嵌套结构：用子查询 +
json_build_object控制键名，比如json_build_object('user', row_to_json(u.*), 'posts', (SELECT json_agg(row_to_json(p.*)) FROM post p WHERE p.user_id = u.id)) - 注意：
row_to_json默认包含 NULL 字段，无需额外开关；但若列含二进制或特殊类型（如bytea），需先转成文本或 base64
存储过程中怎么安全返回 JSON 而不截断？
无论哪种数据库，存储过程返回 JSON 最容易出问题的地方不是语法，而是长度限制和字符集。
SQL Server 的 varchar(max) 或 nvarchar(max) 看似够用，但实际执行时如果没显式声明类型，可能被隐式转成 varchar(8000) 导致截断；MySQL 的 group_concat_max_len 和 PostgreSQL 的 work_mem 都会影响大 JSON 生成。
- SQL Server：声明变量时务必写
DECLARE @json nvarchar(max)，别只写nvarchar - MySQL：在存储过程开头加
SET SESSION group_concat_max_len = 4194304;（4MB） - PostgreSQL：避免在函数里拼超大 JSON，优先用
RETURN QUERY SELECT ...让客户端流式接收 - 统一建议：别在存储过程里做复杂 JSON 格式化，尤其涉及循环拼接 —— 容易失控，交给应用层更可控
真正麻烦的从来不是“怎么生成 JSON”，而是“怎么保证生成的 JSON 不被悄悄截掉、不因字符集乱码、不在某次数据量上涨后突然失败”。这些边界条件，比语法本身更值得盯紧。
