注意：我真的对那些适合其他人的“大型”数组感兴趣。这不是我第一次想到这一点并欢迎反馈。
我在下面详述的方案需要开发努力实现这一目标，因此最好知道我是否应该吃掉带宽并放弃想法，或者这是否是带宽边际增益的实用方法。在其他情况下，对于可能有好奇心的人或我未来的项目，收益可能会更大。
通常当我遇到大型javascript数据集是一个选项的情况时，通常会有其他选项，我倾向于支持其他选项。我实际上并不确定什么是大的或太大的。
我想知道在生产中安全有效。我知道理论上的限制，但我找不到任何实际限制。正如我在下面详述的那样，我的阵列是14000个元素和356k大小。
当然，我知道javascript是客户端，取决于客户端机器的规格，我的代码，以及某种程度上浏览器的版本（在版本之间相关内部性能得到改善的情况下）。 / p>
就像任何一个受人尊敬的现代网站一样，它也会有一个移动版本，这就是内存问题的确切位置。
我实际上并不认为这个尺寸太大或接近它对于客户机器的合理规格期望，但我可能是错的，这是我一直想知道的事情，并且没有找到任何关于。 （当然，这个问题的答案与 N 多年前的答案完全不同。）
编辑：我知道数据大小的32位限制，但我问的是什么可以在健康的生产中发挥作用并且表现良好。
我正处于圣经搜索引擎的计划阶段。
我有一本充满引文的圣经詹姆斯版本的副本。一些引用是相当冗长的，因为我将通过网络服务，我决定将引用重写为引用的索引数组。这样我就可以将引用重写为较短的代码，缩短文本并减少带宽。
这给我留下了一个阵列，其中包含大小为356k的14,000个元素（216k的数据），并且所有经文的总体大小缩小了20％（2mb，每节平均65个字节）。我称之为收益。
该文件的预览看起来像
['s=h07225','s=h0430','s=h0853','m=sm:th8804']
然而，潜在的缺点是与搜索结果一致地使用此阵列所消耗的内存。
答案 0 :(得分：1)
我的建议是使用localStorage，这样就可以将AJAX数据放入其中，这样就不会影响初始页面加载。一旦缓存在客户端上，您可以随意使用它。此外，您可能需要添加一种方法来继续检查您的阵列。您可以检查它是否存在，如果不存在则再次检查AJAX。浏览器可以随时删除本地存储。
另一种方法是放入一个在浏览器中缓存的JavaScript Web资源。您可以使用<script>标记将其引入。此文件将在您的应用程序中声明全局数组。有一个async属性可以让它异步加载。这里的缺点是找出阵列何时可用。