JSON_AGG适用于PostgreSQL 12+，将多行聚合成JSON数组，需配合ROW_TO_JSON或JSON_BUILD_OBJECT使用；SQL Server用FOR JSON；MySQL需GROUP_CONCAT模拟；跨库推荐应用层序列化。
JSON_AGG 适合 PostgreSQL 和标准 SQL 场景
PostgreSQL 12+ 原生支持 JSON_AGG，它把多行结果聚合成一个 JSON 数组。注意它只接受单个表达式（比如整行、某个字段或 ROW_TO_JSON()），不能直接写多个字段——否则报错 function json_agg(record) does not exist。
常见写法是配合 ROW_TO_JSON() 或子查询：
SELECT JSON_AGG(ROW_TO_JSON(t)) FROM (SELECT id, name, age FROM users WHERE age > 30) t;
如果只想聚合部分字段且控制键名，得用 JSON_BUILD_OBJECT：
SELECT JSON_AGG(JSON_BUILD_OBJECT('uid', id, 'label', name)) FROM users;
容易踩的坑：
-
JSON_AGG(NULL)返回[null]，不是[]；需要先FILTER (WHERE ... IS NOT NULL) - 空结果集返回
NULL，不是空数组；可用COALESCE(JSON_AGG(...), '[]'::json)补默认值 - 字段含特殊字符（如点号、斜杠）会导致 key 不合法；需手动转义或改用字符串拼接
FOR JSON 是 SQL Server 的专属语法
SQL Server 2016+ 提供 FOR JSON，但它不是函数，而是查询末尾的输出修饰子句，语法位置固定、不可嵌套调用。最常用的是 FOR JSON AUTO 和 FOR JSON PATH。
AUTO 自动推导结构，但列名带点（如 u.name）会生成嵌套对象；PATH 更可控，支持别名中用点号定义层级：
SELECT u.id AS 'user.id', u.name AS 'user.name', a.city AS 'address.city'
FROM users u
JOIN addresses a ON u.id = a.user_id
FOR JSON PATH, ROOT('result');
关键限制：
- 不能在子查询或 CTE 中直接用
FOR JSON；必须是顶层SELECT - 聚合函数（如
COUNT）和FOR JSON共存时，必须配GROUP BY，否则报错is invalid in the select list because it is not contained in either an aggregate function or the GROUP BY clause - 中文等 Unicode 字符默认被编码为
uXXXX；加WITHOUT_ARRAY_WRAPPER可去掉外层方括号，但仅限单行结果
MySQL 没有 JSON_AGG，得用 JSON_OBJECTAGG + GROUP_CONCAT 曲线救国
MySQL 5.7+ 有 JSON_OBJECTAGG(key, value)，但它只能做“键值对”聚合（类似 Map），不能直接把整行变 JSON 对象。想实现类似 JSON_AGG 效果，得组合 JSON_OBJECT 和 GROUP_CONCAT：
SELECT CONCAT('[', GROUP_CONCAT(
JSON_OBJECT('id', id, 'name', name, 'score', score)
SEPARATOR ','
), ']') AS json_array
FROM students WHERE class = 'A';
问题很明显：一旦某字段含单引号、换行或反斜杠，GROUP_CONCAT 产出的 JSON 就非法。必须提前转义：
- 用
REPLACE(REPLACE(..., '\', '\\'), '"', '\"')处理双引号 - 数值字段不用处理，但字符串字段建议统一过
JSON_QUOTE() -
GROUP_CONCAT默认长度上限 1024，超长会被截断；需临时设SET SESSION group_concat_max_len = 1000000;
跨数据库可移植方案：先取数据再序列化
如果业务逻辑允许，最稳的方式是放弃 SQL 层 JSON 构造，改用应用层组装。比如 Python 中用 psycopg2 获取 dict 列表后调 json.dumps(rows)；Go 里用 sql.Rows 扫描到 struct 切片再 json.Marshal。
理由很实际：
- SQL 生成 JSON 容易受 NULL、特殊字符、深度嵌套影响，调试困难
- 不同数据库语法差异大，写一次查三处（PG/SQL Server/MySQL）几乎必然要条件分支
- 应用层能复用已有 schema 验证、字段过滤、敏感信息脱敏逻辑
真正需要 SQL 直出 JSON 的场景其实有限：比如视图封装、极简 API 代理、或者 DBA 写诊断脚本。其他时候，别硬刚。
