今天早上我尝试使用ExtJS的JSON解码设备来对抗0.75MB的数据，并且它崩溃了FF3。我想知道在客户端可以合理地期望解码的JSON最多的是什么？这可能是使用ExtJS，jQuery，其他Javascript框架或Javascript本身可能提供的任何内置解码。
答案 0 :(得分：1)
我在使用YUI的JSON解析器时遇到了这个问题，因此我尝试使用Prototype的JSON解析器来处理大型数据集，并发现它工作得更好。我还发现，一旦数据集达到一定的大小，它们需要花费很长时间才能解析，浏览器会发出一条消息，询问您是否要终止该作业。因此，对于大型数据集，可能值得将它们分成更容易消化的较小块。
答案 1 :(得分：1)
这在很大程度上取决于客户端浏览器，因为Chrome对于那些大的东西没有任何问题，而IE6很可能会在现场停止。
我建议您不必一次解码大型750 KB JSON传输，尝试在后台发送较小（100 KB）的消息并请求/显示客户端的数据部分需要先。这样你的页面会感觉更快。始终尝试按需加载大型数据集。
我的直觉是，问题不在于JSON消息的大小，而在于FF中的ExtJS'JSON实现。
您是否在其他浏览器中尝试过此操作？如果这只发生在FF上，我建议尝试使用Firefox's own JSON interface进行解码，看看是否有效。
另外，您是否检查过JSON响应实际上是否正确？它可能会崩溃JSON解析器。
答案 2 :(得分：0)
事实证明，Firebug是罪魁祸首。关闭它后，Ext.util.JSON.decode和Javascript的本机eval（）函数都会在0.15秒内返回。
使用Firebug虽然eval返回0.3但我最终得到Ext.util.JSON.decode以完成Firebug并且花了60多秒！在开发过程中我绝对需要Firebug。
答案 3 :(得分：0)
这很有意思，因为如果浏览器支持，Ext只使用本机浏览器JSON解析，否则它{J} evals。没有任何类型的手动解析，因此不确定Firebug会如何影响它。您可以尝试一件事，在解析逻辑之前检查Ext.USE_NATIVE_JSON的值（如果您使用FF 3.1+，则应为true，否则将为false）。尝试将其设置为相反的值并查看是否会发生任何变化（同样，不确定为什么会这样，但值得尝试查看您的情况是否存在差异）。