简介面向SQL Server开发与后端工程师这份资料专门讲解如何用SQL语言自动生成JSON数据解决分页查询结果转换为前端可调用格式的问题。内容先介绍JSON键值对结构及在数据交换中的用途随后拆解核心实现步骤声明TableName、sql、CurPageFirstRow等变量借助SYS.SYSCOLUMNS获取表结构用WITH子句与ROW_NUMBER()构造分页临时集结合ISNULL动态拼接SQL再通过EXEC执行并输出JSON。文中还给出了INSERT INTO将JSON存入数据表的写法以及AJAX调用接口获取JSON数据的前端示例。资源包包含1个docx文件整体仅30KB轻量易读适合快速查阅。该文档已有1141人学习对需要掌握SQL Server动态SQL、JSON格式化输出及分页接口开发的读者有直接参考价值。1. 从一张 Word 文档到一套可落地的 JSON 生产线这个标题到底在说什么如果你是一名每天要和数据库打交道的开发或运维大概率遇到过这种场景上游系统要 JSON 格式的接口数据但你的数据还躺在 SQL Server 或 MySQL 的表里只能先查出来再写段 C# 或 Python 脚本去拼字符串。拼一次两次还好一旦字段有几十个、嵌套层级有三四层手写拼接就变成了纯粹的体力活而且每改一个字段代码就要跟着改一遍。“SQL自动生成JSON数据”这份方案要解决的正是这个痛点——不借助后端代码直接让数据库在查询时就把结果输出成 JSON 结构。它能带来的最直接的价值有三点一是省掉一层应用代码让数据从表到 JSON 的路径变得更短二是利用数据库本身的查询优化能力避免先把全量数据拉到应用层再序列化造成的性能浪费三是把“字段映射”这件事收拢到 SQL 语句里改结构时只改查询不用重新发版。这篇文章会带你从最基础的 JSON 输出函数讲起逐步走到“根据表结构自动拼 SQL”的完整方案并把我在实际项目里踩过的几个典型坑原原本本摆出来。2. 选型对比SQL 生成 JSON 的四条主流路线和一条隐藏捷径2.1 SQL Server 的 FOR JSON 系列最省心的内置方案如果你的数据库是 SQL Server 2016 以上版本那么 FOR JSON 就是第一优先选择。它有FOR JSON PATH和FOR JSON AUTO两种模式前者让你完全控制输出结构后者让数据库自己根据 JOIN 关系推断嵌套。我在实际项目中几乎只用 PATH 模式因为 AUTO 的输出字段名和嵌套规则不够直观而且一旦 SELECT 列表里出现重复列名生成的 JSON 键名会自动加上数字后缀线上排查非常费劲。FOR JSON PATH 的核心语法就是在普通 SELECT 末尾加一行 FOR JSON PATH而嵌套结构靠的是给列名起别名时用点号分隔。下面这个例子演示了把一张订单主表和一张订单明细表合并成嵌套 JSON 的写法SELECT TOP 3 o.OrderID, o.CustomerName, o.OrderDate, d.ProductName AS Items.ProductName, d.Quantity AS Items.Quantity, d.Price AS Items.Price FROM Orders o JOIN OrderDetails d ON o.OrderID d.OrderID WHERE o.OrderDate 2025-01-01 ORDER BY o.OrderDate FOR JSON PATH, ROOT(OrderList);这段 SQL 的逻辑关键在于AS Items.ProductName这种带点号的别名逗号分隔的字段名会被 FOR JSON PATH 自动组建成对象数组。ROOT(OrderList)则是给整个 JSON 加一层根包裹接口对接方如果要求外层有固定字段名这一步就很有用。需要注意的是如果订单下没有明细这种 INNER JOIN 写法会让你丢掉空明细的订单如果业务上要求保留主表记录就要先查主表再用子查询或 APPLY 生成子数组。2.2 MySQL 的 JSON_OBJECT 与 JSON_ARRAY手动拼装的精确控制MySQL 从 5.7 开始支持 JSON 类型同版本也带上了 JSON_OBJECT 和 JSON_ARRAY 函数。和 SQL Server 的 FOR JSON 相比这种方式更像是“用函数组装”没有那种直接把查询结果转成 JSON 的语法糖——在 MySQL 8.0.21 之前你也确实没法让SELECT * FROM table FOR JSON在 MySQL 里跑通只能一个个字段地手动包裹。SELECT JSON_ARRAYAGG( JSON_OBJECT( order_id, o.id, customer_name, o.customer, items, ( SELECT JSON_ARRAYAGG( JSON_OBJECT( product, d.product_name, quantity, d.qty ) ) FROM order_details d WHERE d.order_id o.id ) ) ) AS order_json FROM orders o WHERE o.created_at 2025-01-01;外层用JSON_ARRAYAGG把所有订单行聚合成数组每行用JSON_OBJECT定义键值映射嵌套明细则通过相关子查询再套一次JSON_ARRAYAGG JSON_OBJECT。这种写法的好处是结构完全可控连键名都能用中文或带空格的字符串坏处是 SQL 会变得非常臃肿一旦字段多了就很难维护。我一般建议字段超过 15 个或嵌套超过两层时就别继续手动拼了直接看第 4 章的动态生成方案。2.3 PostgreSQL 的 row_to_json 与 jsonb_build_object类型处理最顺手PostgreSQL 走的是函数路线但比 MySQL 多了一个把整行转成 JSON 的便捷函数 row_to_json配合 json_agg 可以很快地把查询集转成 JSON 数组。如果你使用的是 jsonb_build_object它还能自动处理布尔值和数字类型不会像 FOR JSON 那样把数字带上引号变成字符串。SELECT jsonb_pretty( jsonb_agg( jsonb_build_object( id, id, name, customer_name, tags, COALESCE(tags, []::jsonb) ) ) ) FROM customers WHERE created_at now() - interval 7 days;这条语句里的jsonb_build_object接收的是交替出现的键和值jsonb_agg负责聚合成数组最后的jsonb_pretty只是让输出在客户端里容易读。值得注意的是COALESCE(tags, []::jsonb)的处理如果 tags 列是 NULL直接塞进 JSON 会让字段缺失而接口端有时候希望拿到空数组而不是 null所以这里给它一个默认值。这条血泪经验在 MySQL 和 SQL Server 里同样适用——输出 JSON 前先想好 NULL 字段的语义。2.4 隐藏捷径SQL Server 的 FOR XML 老手艺转 JSON还有一种比较老的生成 JSON 方案是先用 FOR XML 把查询结果拼成 XML 字符串再在应用层把 XML 转成 JSON。这在 2016 年之前几乎是 SQL Server 唯一的选择很多老系统里现在还跑着类似SELECT * FROM table FOR XML PATH这种代码。从技术演进的角度看这个方案已经不推荐新项目用了因为 FOR XML 生成的字符串需要额外做 XML 反转义比如把 换成 \u0026步骤多出一截而且调试时看那串长文本比看 JSON 难受得多。但如果你在维护 2012 或 2008 R2 的老库相关热搜里也有不少人在搜 sql server 2008 r2 下载那 FOR XML 加一个 .NET 里的 XDocument.Parse 是你目前在数据库侧唯一可行的方案——不要试图在还原老库的同时引入新数据库引擎迁移成本和风险远比转 JSON 本身要高。3. 从表结构自动生成 JSON 查询把“拼 SQL”这件事也自动化3.1 基于系统视图的元数据提取如果只需要写一两条查询手动拼 FOR JSON 完全没问题但当你面对十几张表、每张表几十个字段时手动拼写就成了“慢 SQL 优化”之外另一个耗时间的无底洞。更合理的思路是先查系统视图拿到表结构再写一个 SQL 脚本自动生成 FOR JSON 查询语句。SQL Server 里查字段元数据用的是sys.columns和sys.tablesMySQL 对应 information_schema.columns两边逻辑大同小异。-- SQL Server根据表名生成 FOR JSON PATH 的 SELECT 字段清单 DECLARE tableName NVARCHAR(128) Orders; DECLARE selectList NVARCHAR(MAX) ; SELECT selectList selectList [ c.name ] AS Item. c.name , CHAR(13) FROM sys.columns c WHERE c.object_id OBJECT_ID(tableName) ORDER BY c.column_id; PRINT selectList;这段脚本的核心是遍历 sys.columns 里的列拼出形如[OrderID] AS Item.OrderID的别名片段。注意PRINT有最大 8000 字符的限制如果表字段很多导致字符串超长就改用SELECT selectList把结果拿到结果集窗口里看完整内容。生成这段 SELECT 清单后你把前面那段 FOR JSON PATH 的主查询框架一拼整条 SQL 就出来了。3.2 一个完整的动态生成存储过程模板光拼字段清单还不够更理想的做法是写一个存储过程传入表名直接返回该表的 JSON 数据。这样业务方只需要调用一个过程不需要关心具体字段名更不需要把 SQL 拷来拷去。下面是一个 SQL Server 的动态存储过程利用了 sp_executesql 执行拼出来的查询CREATE PROCEDURE sp_GenerateTableJSON SchemaName NVARCHAR(128) dbo, TableName NVARCHAR(128), TopN INT 1000 AS BEGIN SET NOCOUNT ON; DECLARE sql NVARCHAR(MAX); DECLARE cols NVARCHAR(MAX) ; -- 1. 拼接字段列表每个字段包装成 JSON 键值对 SELECT cols cols QUOTENAME(c.name) AS Data. c.name , CHAR(10) FROM sys.columns c WHERE c.object_id OBJECT_ID(QUOTENAME(SchemaName) . QUOTENAME(TableName)) ORDER BY c.column_id; -- 2. 去掉末尾多余的逗号 SET cols LEFT(cols, LEN(cols) - 1); -- 3. 组装完整查询 SET sql NSELECT TOP (TopN) cols N FROM QUOTENAME(SchemaName) . QUOTENAME(TableName) N FOR JSON PATH, ROOT(Data);; -- 4. 执行动态 SQL EXEC sp_executesql sql, NTopN INT, TopN; END;这个存储过程里值得注意的几个参数细节第一TopN通过 sp_executesql 的参数列表传入而不是直接拼进字符串里这样能避免注入问题也让查询计划可以被缓存复用第二QUOTENAME给表名和列名加方括号防止字段名碰巧是保留字或带空格时执行失败第三ROOT(Data)是给输出包一层统一外壳接口方解析时直接用Data.xxx就能定位数据。你可以在这个基础上加过滤条件比如增加WhereClause参数直接拼到 WHERE 后面但必须验参否则就白搭了。3.3 MySQL 版本的自动化思路MySQL 里做同样的事情要用 information_schema 拼 JSON_OBJECT 的片段。下面这段生成字段包裹片段的示例核心是通过group_concat把每列的JSON_OBJECT(字段名,列名)片段拼起来-- 生成单行 JSON_OBJECT 的字段片段 SELECT CONCAT( JSON_OBJECT(data, JSON_OBJECT(, GROUP_CONCAT( CONCAT(, COLUMN_NAME, , , COLUMN_NAME, ) ORDER BY ORDINAL_POSITION SEPARATOR , ), )) ) AS json_snippet FROM information_schema.columns WHERE table_schema your_db AND table_name orders;执行后你会得到类似JSON_OBJECT(data, JSON_OBJECT(id,id, customer,customer, ...))的一长串文本把它复制到查询里再调通缩进就完成了。这个方案在 MySQL 上会比 SQL Server 更零碎因为 MySQL 没有内置的“行转 JSON”语法只能在 SQL 生成 SQL 之后手动粘贴。不过如果你用的是 Navicat 或 DataGrip它们自带的“导出为 JSON”功能其实也基于这种思路只是把字段映射藏在对话框里不适合自动化。提示按照字段顺序生成 JSON 并不代表接口就该用这个顺序。JSON 对象的键顺序在语义上不是强制的但为了排查方便尽量保持 SELECT 列表顺序和数据库表定义顺序一致。如果接口文档要求的字段顺序不同别在数据库里硬调交给应用层做一次字段重排更省事。4. 让 JSON 输出真正可用数据类型、NULL 处理和日期格式的必调参数4.1 数字别变成字符串类型转换的三个关键点SQL 生成 JSON 最常见的翻车现场就是类型错乱。SQL Server 的 FOR JSON PATH 会对DECIMAL和FLOAT类型做特殊处理在输出时给数字型字段加上引号的情况很少但UNIQUEIDENTIFIERGUID和DATETIME在默认序列化下会变成字符串这本身没错问题出在如果你的查询里用了VARCHAR存储数值那输出来的就是一个字符串前端做加减乘除时会直接得到 NaN。解决办法是在 SELECT 阶段就做一次显式转换SELECT OrderID, TRY_CAST(OrderAmount AS DECIMAL(18,2)) AS Amount, FORMAT(OrderDate, yyyy-MM-dd HH:mm:ss) AS OrderDateStr FROM Orders FOR JSON PATH;TRY_CAST和FORMAT在这里的作用是把脏数据拦在查询阶段。TRY_CAST遇到没法转成数字的字符串时返回 NULL 而不是报错这在跑线上表时很关键——一线表里常常躺着历史脏数据一个 CAST 不让过导致整条查询失败线上接口就被你拖崩了。FORMAT函数则是把 SQL Server 的默认时间格式从带毫秒和时区的形式转成可读性更好的标准格式如果接口对接的是 Java 的 LocalDateTime建议连毫秒一起去掉否则反序列化经常报格式错误。4.2 NULL 字段的三种策略剔除、保留 null、给默认值在设计 JSON 输出时NULL 字段是必须提前拍板的问题。如果你不处理FOR JSON PATH 默认会把 NULL 字段输出为field: nullMySQL 的 JSON_OBJECT 也会保留 null。从接口协议的角度看null 和字段缺失在语义上是两回事null 表示“有约束但值未填”缺失表示“这个对象根本没有这个属性”。如果前端代码写的是if (data.field ! undefined)那 null 和缺失都能通过但如果写的是Object.keys(data).includes(...)两者就会产生分支差异。最常见的需求是“去掉所有 NULL 字段”。SQL Server 里可以通过在列别名后面加WITHOUT_ARRAY_WRAPPER等参数组合但真正干净的做法是在 SELECT 层用 CASE 判断SELECT OrderID, CASE WHEN Note IS NULL THEN ELSE Note END AS Note FROM Orders FOR JSON PATH;这样 NULL 会被替换成空字符串虽然是改了语义但很多接口就这么约定俗成了。如果你需要的是剔除字段那就得在动态生成脚本里加一层判断遍历 sys.columns 时把 IS_NULLABLE 为 YES 的列单独拿出来再配合NULLIF或条件拼接来判断是否要输出。这一步没有一劳永逸的标准答案我习惯把策略做成存储过程的一个参数调用方按接口文档要求传值。4.3 大数据量分批FOR JSON 的内存限制和 TOP × 分页FOR JSON PATH 一次性生成的结果是个大字符串SQL Server 在输出时会受到MAX_STRING_LENGTH之类的限制吗答案是不受传统的 8000 字符限制但受输出凭证影响——实际能到你手里的最大字符串由客户端配置决定。在 SSMS 里你会看到它只展示前 65535 个字符在 JDBC 里用 getString 拿到完整结果是完全可以的。真正的瓶颈在内存和网络传输上当你对一张千万级表直接执行 FOR JSON 时SQL Server 需要先把所有行序列化到内存再一次性推给客户端任何一方的内存不够都会导致超时或 OOM。我在线上遇到过一张 500 万行的订单表直接 FOR JSON 跑了 3 分钟还没出结果。后来改成按日期窗口分批拉取每次只取 1 天数据批量调用 30 次合并总耗时反而只有 40 秒——因为每批排序和序列化的开销都变小了而且还能走索引下推。分批的 SQL 模板可以这样写DECLARE BatchSize INT 10000; DECLARE LastID INT 0; WHILE 1 1 BEGIN SELECT TOP (BatchSize) OrderID, CustomerName, OrderDate FROM Orders WHERE OrderID LastID ORDER BY OrderID FOR JSON PATH; SET LastID (SELECT MAX(OrderID) FROM (SELECT TOP (BatchSize) OrderID FROM Orders WHERE OrderID LastID ORDER BY OrderID) t); IF ROWCOUNT BatchSize BREAK; END;这段把程序里的分页逻辑塞到了数据库里利用OrderID LastID做键值分页比 OFFSET 分页在大表上性能好得多。每次循环返回一段 JSON你在应用层收集拼接即可。注意SET LastID的赋值用了嵌套查询这是为了让循环条件始终基于上一次最大值避免并行或新增数据导致重复或漏行。5. 把方案接到真实链路与查询工具、慢 SQL 优化和下游系统的集成细节5.1 Navicat、DataGrip 和 SSMS 里怎么跑通结果每种客户端处理 JSON 输出结果的方式都有差异。SSMS 里直接执行 FOR JSON 查询结果是一个超长字符串你用鼠标点那一格很难直接看到完整内容更别说复制了。这里有一个技巧把结果转成 XML 再复制到文本编辑器里格式化或者直接右键选择“将结果保存为文件”让 SSMS 把整个字符串写进一个 .txt 里再到 VS Code 中点一下格式化 JSON 就能检查结构。Navicat 的表现类似但新版 Navicat尤其是 16.x 以上对 JSON 结果有内置的格式化预览直接点开单元格就能看到树形展开的 JSON 对象对调试友好很多。DataGrip 则更直接它在查询结果面板里能识别 JSON 类型字段并在网格里显示为一个带花括号的图标点击即可查看格式化后的内容。如果你是 MySQL 用户执行 5.7 版本生成的 JSON 字符串在 DataGrip 里同样适用。唯一要注意的是如果你的 SELECT 结果和 FOR JSON 或 JSON_ARRAYAGG 放一起网格里可能混有多列DataGrip 判断某列是 JSON 是按内容嗅探的结果里万一出现一串像 JSON 格式的普通字符串它也会误渲染排查时先确认列名对应关系就好。5.2 慢 SQL 优化视角FOR JSON 的查询计划有什么不同加上了 FOR JSON 的查询在 SSMS 里查看预估执行计划和普通查询几乎相同因为序列化步骤发生在查询执行完毕之后——它不会影响连接、筛选和排序阶段的执行计划。这也是我推荐在数据库侧做 JSON 序列化的原因之一性能开销主要是 CPU 序列化和内存分配并不影响 SQL Server 优化器原本的选择。真正会让慢 SQL 变慢的是你为了拼 JSON 引入的多层子查询和重复计算比如在 SELECT 列表里反复调用 JSON_OBJECT 或 FOR JSON 的子查询。一个典型的性能坑是在关联查询的 SELECT 字段里对每一行都执行一个相关的 FOR JSON 子查询这就是行级触发器式的开销表一大就直接打满 CPU。更好的做法是先把关联表的数据查询出来再一次性用 APPLY 或 OUTER APPLY 做连接后统一 FOR JSON。比如SELECT o.OrderID, d.Items FROM Orders o OUTER APPLY ( SELECT d.ProductName, d.Quantity FROM OrderDetails d WHERE d.OrderID o.OrderID FOR JSON PATH ) d(Items) FOR JSON PATH;这里的OUTER APPLY把每一行的明细聚合成了一个 JSON 子串再在外层统一做一次 FOR JSON。它和前面 2.1 小节里的 JOIN 写法在结果上类似但执行路径更灵活——明细表没匹配到数据时Items字段会变成 NULL结合上一章的 NULL 策略就可以控制是否输出。5.3 下游系统消费C# 和 Java 里反序列化的对齐检查JSON 生成出来是要被消费的不是给自己看的。我见过太多项目SQL 侧辛苦拼好了 JSON结果下游的 C# 反序列化直接抛异常原因不外乎两个字段名对不上或者类型对不上。C# 里的 Newtonsoft.Json 对 JSON 的键名默认区分大小写如果你在 SQL 里用的别名是customer_name而 C# 模型类属性是CustomerName直接反序列化就会得到全是默认值的对象。解决办法是在 SQL 别名阶段就把字段名完全对齐到契约命名或者在 C# 侧加[JsonProperty(customer_name)]属性。// 在模型属性上手动指定 JSON 键名避免改 SQL public class OrderItem { [JsonProperty(ProductName)] public string ProductName { get; set; } [JsonProperty(Quantity)] public int Quantity { get; set; } }Java 里用 Jackson 的话可以在类上配置JsonNaming(PropertyNamingStrategies.SnakeCaseStrategy.class)来让 Java 字段自动映射成下划线风格的 JSON 键这样 SQL 里的别名就用下划线不用为每个字段单独写 JsonProperty。如果两边团队同时维护 API 契约最稳的做法是把 JSON 样例固化下来用 JSON Schema 做校验SQL 侧每次改查询后在 CI 里跑一遍 Schema 校验字段改名引起的兼容问题就能在合并分支前被发现而不是等上了生产才开始排查接口 500。6. 这套方案常见的 5 个坑现象、原因和解决办法避坑指南6.1 数字字段被序列化成字符串导致前端图表全部异常现象FOR JSON 输出的price: 19.99而不是price: 19.99前端拿到后求和、排序结果全部变成字符串拼接连在一起。原因你在 SQL 查询里把价格列的数据类型定义成VARCHAR或者查询里做了隐式转换让 SQL Server 无法推断出它是数值型。解决办法使用TRY_CAST(price AS DECIMAL(18,2))显式转一次并检查源表的数据类型如果源表本身就是字符串存储金额就真要考虑修表结构了——靠 SQL 每次转不是长久之计。6.2 中文乱码或转义错误现象JSON 输出里的中文字符变成了\u4e2d\u6587这样的 Unicode 转义序列前端把它当字符串显示没问题但直接写进日志或文件里看着非常难受。原因这是数据库驱动和客户端渲染机制导致的本质没有问题——\uXXXX是 JSON 标准转义任何 JSON 解析器都能正确还原。解决办法如果你希望看到直接的中文在 SSMS 菜单“工具 → 选项 → 查询结果 → SQL Server → 结果到文本/网格”里调整编码为 UTF-8 即可。但注意输出到文件时不要强行替换反斜杠那会把合法 JSON 破坏掉。6.3 嵌套数组变成多个独立行而非一个数组现象使用 FOR JSON PATH 关联查询后明细数据没嵌套成数组而是变成多条记录各有独立的Items.ProductName字段。原因FOR JSON PATH 默认会把同一个父行的多个字段展开成数组但如果你希望的是每个父行对应一个子数组就需要让明细字段通过子查询或OUTER APPLY生成一个独立的 JSON 片段。解决办法参考第 5 章里OUTER APPLY的写法把明细查询的结果先聚合成一个 JSON 子串别直接在主查询中展开。6.4 动态 SQL 拼接时出现 NULL 或空字符串导致语法错误现象用存储过程动态生成字段清单时遇到表中只有一个字段或表名不存在时拼出来的 SQL 是残缺的执行时报语法错误。原因SELECT cols cols ...初始值为 NULL加上字符串后结果还是 NULL表名不存在时 sys.columns 查不到任何行cols就一直是 NULL。解决办法给cols赋初值空字符串加一个 IF 判断如果cols仍为空就RAISERROR抛出异常并返回。6.5 大批量执行时客户端内存溢出现象直接选中一个 100 万行的 FOR JSON 查询在客户端里执行客户端的表格控件直接卡死或崩溃。原因JSON 序列化全结果为一个字符串客户端网格控件需要把这个长字符串渲染成一个单元格内容内存占用瞬间飙升。解决办法按第 4 章的批量方案BatchSize设到 5000 到 10000 之间分多次执行或者把FOR JSON PATH结果写入一个中间表再在应用层按文件流读取该表内容。7. 进阶验证用 JSON Schema 给自己上一道保险最后这条进阶技巧是我在过去两个项目里养成的习惯——把生成的 JSON 数据落进一个 JSON Schema 校验流程里提前拦住 90% 的字段级问题。JSON Schema 是一个描述 JSON 结构的规范文件你可以把它理解为数据库表结构对 JSON 数据的关系约束。在 SQL 生成 JSON 的链路中这个 Schema 应该由接口契约方来维护每次 SQL 改完查询然后执行一次校验。下面这个 Schema 片段描述了订单嵌套对象的预期结构{ $schema: http://json-schema.org/draft-07/schema#, type: object, properties: { OrderList: { type: array, items: { type: object, properties: { OrderID: { type: integer }, CustomerName: { type: string }, Items: { type: array, items: { type: object, properties: { ProductName: { type: string }, Quantity: { type: integer } }, required: [ProductName, Quantity] } } }, required: [OrderID, CustomerName, Items] } } }, required: [OrderList] }你可以用 Python 的 jsonschema 库或 Node.js 的 ajv 库在 CI 里写一个简单的校验任务每天夜间跑一次当天的订单生成任务把生成的 JSON 文件喂给 Schema 校验器有任何字段缺失或类型不匹配构建就失败并通知到对接群。这种做法比我过去肉眼看 JSON 样例猜字段要靠谱得多——有段时间我们改了一个字段的类型数据库侧和前端都通过但 BI 侧老报错最后查下来就是 Schema 没同步。现在我把 Schema 文件放在 git 仓库里和接口代码同目录数据库侧改字段别名时必须同步提一个 Schema 更新 PR两边锁死这半年一次字段兼容事故都没出过。另外如果生成 JSON 的这个存储过程本身要接受参数强烈建议你在数据库侧也做一次参数化测试把 Schema 校验嵌入到一个 T-SQL 测试脚本里每次部署存储过程前先跑一遍典型输入和边界输入看输出是否符合契约。SQL 侧的问题最好在 SQL 侧发现别等应用层接了脏数据再半夜爬起来看日志。希望这篇文章的这套链路——选型、动态生成、调参、避坑、Schema 校验——能帮你少走几趟弯路至少在 SQL 生成 JSON 这条路上能一次趟平。本文还有配套的精品资源点击获取