.NET6 REST API中long.MinValue与long.MaxValue序列化异常排查

问题核心现象 #

• .NET（使用System.Text.Json）和Java均存在long.MinValue（-9223372036854775808）、long.MaxValue（9223372036854775807）的序列化相关异常表现
• 控制台程序中序列化这两个极值时结果完全正确，但在.NET 6 REST API场景下出现差异：
  • Swagger UI、Chrome自带的JSON解析视图会将值显示为-9223372036854776000和9223372036854776000（精度截断）
  • API返回的原始响应数据是正确的，仅前端/UI展示层出现错误
  • 当上述错误值回传至API时，会触发无法转换为long类型的报错

重点排查管道环节 #

1. Swagger UI的数字处理逻辑 #

Swagger UI依赖浏览器JS引擎渲染数据，而JS的Number类型最大安全整数为2^53（9007199254740992），远小于long.MaxValue。Swagger UI默认用Number解析大整数，导致精度丢失。可以：

• 检查Swagger配置，是否能强制将大数字以字符串形式渲染
• 验证原始响应数据（通过Swagger的"Response body"原始文本或浏览器Network面板）确认序列化结果正确

2. Chrome浏览器的JSON解析限制 #

Chrome的内置JSON视图同样使用JS引擎处理数据，超出2^53的整数会被自动近似处理，属于浏览器端的固有精度限制。解决方式：

• 始终通过Network面板的"Response"标签查看原始数据，避免依赖Chrome的格式化视图
• 前端接收数据时，需用BigInt类型或字符串类型处理long极值，而非Number

3. .NET 6 API的序列化配置差异 #

对比控制台程序和API的System.Text.Json配置：

• 检查API的全局序列化配置（如Program.cs中的AddJsonOptions），是否设置了NumberHandling为JsonNumberHandling.AllowReadingFromString或其他可能影响long序列化的选项
• 确认API未意外将long类型序列化为浮点型或其他类型

4. 前端数据接收的处理方式 #

如果前端直接用JS解析API响应，Number类型无法承载long极值，必然出现截断。需：

• 前端将long类型字段以字符串形式接收，后续转换为BigInt处理
• 或后端配置序列化时将long极值转为字符串（仅针对极值场景或全局配置）

内容的提问来源于stack exchange，提问作者monty