SQL Server中如何用嵌套查询配合FOR JSON导出报表？

聊到 SQL Server 的 FOR JSON，不少朋友会发现，想搞出复杂的多层嵌套结构，光靠一条简单的 SELECT 可不行。这里面的弯弯绕绕，尤其是几个“坑”，如果没趟过，很容易在前端“翻车”。今天就把这些核心要点掰开揉碎了说说。

一句话先定个调子：靠单条 FOR JSON 指望它自动推导出多层嵌套，基本没戏。你得用子查询加上 JSON_QUERY() 显式地告诉数据库：“这段东西，请把它当成一个完整的 JSON 对象给我嵌进去，而不是一个普通的字符串。”

子查询出来的 JSON，必须用 JSON_QUERY() 包一下

这是最容易踩的坑，没有之一。如果你直接在 SELECT 里写个子查询，再给它套个 FOR JSON PATH，外层的大循环 FOR JSON 会把子查询的结果当成一个普通的 NVARCHAR(MAX) 字符串来处理。最终在输出里，你会看到类似 "items": "[{"id":1}]" 这种奇怪的东西——这可不是你想要的 JSON 对象，它仅仅是一个被转义了的字符串字面量，前端解析时必然报错。

• 根源在于，子查询返回的类型是字符串，不是 JSON 对象。FOR JSON 没有那个“眼力劲儿”去识别它。
• 解决办法很简单，但请务必牢记：在子查询外面套一层 JSON_QUERY()。这就像给 SQL Server 下一道明确的指令：“这段文本，请把它当作一个合法的 JSON 值来嵌入。”
• 漏掉这一步，是生产环境中最常见的坑。现象就是前端要么解析失败，要么得到一个空数组，查错的时候还很让人头疼。

FOR JSON PATH 子查询里头，别直接写 ORDER BY

子查询里要是敢写 ORDER BY，除非你同时加上 TOP 100 PERCENT，否则 SQL Server 会毫不留情地给你报个错：FOR JSON requires an alias for nested results。 这个报错信息非常容易让人误入歧途，因为它跟实际问题的关联性并不直接。

• 标准写法是：(SELECT TOP 100 PERCENT id, name FROM Items WHERE ... FOR JSON PATH) AS items 。这里的 TOP 100 PERCENT 完全没有业务语义，纯粹是为了满足 SQL Server 的语法约束，让它闭嘴。
• 如果你用的是 SQL Server 2022 或更高版本，也可以用 OFFSET 0 ROWS 来替代 TOP，但从兼容性角度考虑，TOP 100 PERCENT 无疑是最稳妥、最通用的方案。
• 如果真的需要稳定排序，可以耍个小聪明：在子查询的外面再套一层 SELECT * FROM (子查询) ORDER BY ...。但要注意，这可能会破坏 FOR JSON PATH 生成数组的逻辑，用之前最好想清楚。

空子查询返回的是 null，不是你想要的 []

当你的关联子查询没有找到匹配数据时（比如某个订单没有任何明细），JSON_QUERY(...) 会直接返回 NULL。最终在你生成的 JSON 里，就会看到 "items": null。但绝大多数前端都默认期盼一个空数组 "items": []。

• 补刀的方法是用 ISNULL(JSON_QUERY((SELECT ... FOR JSON PATH)), '[]')。简单粗暴，但很有效。
• 还有个更稳一点的做法：在子查询里通过 LEFT JOIN 或者 CASE WHEN 来保证至少能返回一行数据（哪怕字段全是 NULL），然后再配合 INCLUDE_NULL_VALUES 选项。
• 需要特别注意，INCLUDE_NULL_VALUES 的作用是控制空字段是否在对象中间出现，它并不会改变空集合返回 null 还是 [] 这个行为。

别名里带点号，最多只能生成一级嵌套，再深就得靠子查询了

我们经常会用 user.name 或 address.city 这种带点号的别名，利用 FOR JSON PATH 的特性来生成一层嵌套。这确实很方便，但它有局限性——只能处理一层。如果你想表达类似 {"user":{"profile":{"age":30}}} 这种三层结构，点号写法就行不通了。

• 三层及以上的复杂嵌套，必须老老实实拆成两层子查询：外层查 user，内层子查询查 profile 并加上 FOR JSON PATH，然后外层再通过 JSON_QUERY 把它嵌进去。
• 别名点号本质上是一种语法糖，底层映射的仍然是字段，并不会触发真正的嵌套查询执行计划。千万别把它想得太强大。
• 建议在项目中统一使用“子查询 + JSON_QUERY”的方案，逻辑更清晰，也更容易控制和调试。

说到底，写一个能跑的 FOR JSON 并不算太难。真正考验功力的是：确保每一层子查询的关联条件都精准无误，把空值的边界情况都处理干净，并且一个 JSON_QUERY 都没有漏掉。这三个地方一旦出错，生成的 JSON 看起来可能没问题，但到你消费端（比如前端 JS 解析）时，就直接崩给你看了。