MVC5中JavaScriptSerializer报maxJsonLength异常但Payload极小的排查求助

这种间歇性的问题确实头疼——明明看着请求Payload很小，却时不时触发长度超限的错误，我来分享几个容易被忽略的少见原因：

• 反向序列化时的隐式数据膨胀
  别光盯着请求的Payload，服务器端Action的参数类型可能藏着坑。比如如果用了EF的实体类作为参数，而实体里有延迟加载的导航属性，JSON解析器在反序列化时可能意外触发了延迟加载，把关联的大量数据（比如用户的所有订单、评论）都拉了进来，导致实际要处理的数据量远超请求里的那点JSON。这种情况往往是间歇性的，取决于实体对象当时的状态。

• 请求的重复提交/合并
  浏览器在网络波动时会自动重试请求，或者前端代码有重复触发的bug（比如按钮点击事件绑定了两次），可能导致多个小请求被合并成一个，或者同一个请求被多次发送，服务器端接收到的实际数据长度叠加后超过了限制。Chrome调试器有时候只会显示最后一次的请求，抓不到这种合并的场景，所以看起来Payload很小。

• 序列化配置的冲突或局部失效
  MVC5默认用JavaScriptSerializer，但如果你的项目里混着用了Json.NET（Newtonsoft.Json），很容易出现配置冲突。比如Web.config里设置了全局的maxJsonLength，但某些Action用了自定义的JsonResult或者直接实例化JavaScriptSerializer，没读取这个全局配置，还是用了默认的小限制（默认是2097152字符）。这种情况会导致只有特定场景下触发错误，表现为间歇性。

• 搞反了：是响应数据超限，不是请求
  很多人会看错异常的触发时机——这个错误可能是服务器端序列化返回数据时抛出的，而不是解析请求Payload的时候。比如你的Action有时候会返回包含大量数据的对象（比如某次查询返回了全表数据），这时候即使请求Payload很小，也会触发maxJsonLength的限制。你可以检查下出现错误时，Action正在返回什么数据。

• 请求格式异常导致的错误误导
  有时候前端发送的请求格式有问题（比如Content-Type不对，或者JSON里有特殊字符、语法错误），服务器端的解析器在处理时抛出了异常，但错误信息被包装成了“长度超限”。这种情况的异常其实是解析失败的次生问题，不是真的长度不够。

几个排查小技巧 #

• 用Fiddler抓完整的请求和响应，比Chrome调试器更可靠，能看到真实的请求内容和长度；
• 在Action开头加一段代码，读取并记录原始请求内容：

  using (var reader = new StreamReader(Request.InputStream))
  {
      var rawJson = reader.ReadToEnd();
      // 记录rawJson的长度和内容到日志
  }
  

• 检查EF实体的导航属性，必要时关闭延迟加载或者用DTO类代替实体作为参数/返回值；
• 确认Web.config里的全局配置是否生效：

  <system.web.extensions>
    <scripting>
      <webServices>
        <jsonSerialization maxJsonLength="50000000"/>
      </webServices>
    </scripting>
  </system.web.extensions>
  

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