这不是一个真正的问题，因为我已经解决了这个问题，但我想我会让每个人都知道，因为它可能对人们使用Google Web Toolkit的方式产生很大的影响。
因此问题之一是Google gson表示JSON中的数字。例如，int myInt = 2将变为"myInt":2，long myLong = 5432198765L将变为"myLong":5432198765，BigInteger myBI = 1310381093810938109481049128409487109378109248104098130981039810983将变为"myBI":1310381093810938109481049128409487109378109248104098130981039810983。虽然gson本身可以毫无问题地反序列化，但JSON中的GWT 2.4中的AutoBeans框架不会喜欢它。 Issue 6331修复了它在即将发布的GWT 2.5版本中的长期表示。但是，由于Javascript编号精度的工作方式，issue 7555将无法解析。
因此，我们需要将BigIntegers表示为字符串，它将起作用，例如，String myBIStr = new BigInteger("1310381093810938109481049128409487109378109248104098130981039810983").toString()将表示为"myBIStr":"1310381093810938109481049128409487109378109248104098130981039810983"。在GWT结束时，这将产生一个String，我们将不得不构建一个BigInteger。
为什么谷歌不会解决7555这一切都是完全合理的，但这引出了一个真正的开放性问题：如何处理Javascript中的高精度数字？
通常，如果基于Web的Javascript和Google Web Toolkit前端要挑战本机前端，那么可能会出现我们处理任意精度数字的情况，而不是受到53位精度的限制comment 3谈到的。更糟糕的是，这个限制是否也会影响node.js或任何其他服务器端Javascript？
是否有一个很好的解决方案，尤其是使用或无缝使用Google Web Toolkit的工作？
答案 0 :(得分：3)
GWT可以对大于53位的整数进行数学运算，因为它模拟Long（我认为是BigInteger）。数学运算速度较慢，因为它不能只使用本机JS操作，但这并不是硬限制。
因此，GWT已经实现了变通方法，它已内置。当你需要一个大整数时，你只需要避免传递数字JSON。