.NET Core 2.2跨API调用Decimal值异常（Azure环境）

我遇到了一个很棘手的问题：手上有两个基于.NET Core 2.2开发的Web API，当通过API A调用API B的接口时，返回的Decimal类型字段totalCost会出现完全错误的数值，但本地测试和直接用Postman调用Azure上的API B时，一切都正常。

举个实际的例子，在AppInsight的自定义事件里，API A获取到的API B响应内容是：

{"paymentTypeId": "1", "quoteNro": 6, "totalCost": 63831774.02}

但这个totalCost字段实际应该返回7443.02，数值偏差非常大。

环境差异总结 #

• 本地环境：不管是API A调用API B，还是直接调用API B，Decimal值都完全正确，没有任何异常。
• Azure环境：
  • 直接用Postman调用API B，返回的totalCost值是正确的；
  • 调用Azure上的API A（内部会调用API B），就会得到错误的totalCost值。

已经排除的可能性 #

我已经逐一排查了以下常见问题，但都没有找到根源：

• 响应反序列化逻辑错误
• AutoMapper配置问题（字段映射规则确认正确）
• 两个API的DTO字段名称和数据类型不匹配（totalCost都是Decimal类型）
• 区域文化设置导致的解析差异
• 数值舍入问题（尝试让API B返回舍入后的值，问题依然存在）

可能的排查方向 #

如果你也遇到过类似问题，或者有相关思路，欢迎帮忙指点，我也整理了一些接下来打算尝试的排查方向：

1. 检查API A的HttpClient配置

   • 确认HttpClient是否设置了正确的Accept请求头（比如application/json），会不会因为内容类型不匹配导致解析异常？
   • 检查是否在HttpClient的消息处理管道中添加了自定义拦截器/中间件，有没有可能在传递响应过程中意外修改了数值？

2. 对比API B的请求上下文日志

   • 在API B中添加详细日志，分别记录被API A调用和被Postman调用时的请求参数、生成的响应内容，对比两者的差异，看看API B是否针对不同调用方返回了不同结果？
   • 检查API B在Azure上的应用服务配置，有没有特殊的环境变量或开关，在被内部API调用时触发了异常逻辑？

3. 检查全局JSON序列化配置

   • 两个API都使用.NET Core 2.2默认的Newtonsoft.Json，检查AddJsonOptions中的配置，比如是否添加了自定义的Decimal转换器？会不会在序列化/反序列化时因为精度或缩放设置错误导致数值变形？
   • 确认API B序列化totalCost时的规则，和API A反序列化时的规则是否完全一致？

4. 排查Azure托管环境的特殊配置

   • 查看API A和API B的应用服务计划，是否有资源限制（比如内存不足）导致的异常数值处理？
   • 检查是否开启了响应压缩功能，会不会在压缩/解压过程中损坏了数值内容？

5. 追踪完整的请求响应流

   • 使用Fiddler或Azure Application Insights捕获API A调用API B的完整HTTP请求和响应，对比直接Postman调用API B的响应原始内容。如果原始响应就错误，问题出在API B的处理逻辑；如果原始响应正确但API A解析后错误，问题就出在API A的反序列化或后续处理环节。

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