因此，这类性能问题有多个Angular 。
1.在浏览器中呈现数千个DOM节点是很慢的。如果你在客户端为100，000行生成随机数据（即模拟一种情况，你不需要在浏览器中下载1gb的数据模型，因为它只是JS中生成的随机数据），如果没有某些技术，它在浏览器中的表现仍然非常糟糕，而ag-grid正在使用的技术。
1.即使你已经解决了（1），1GB的数据也太多了，无法保存在单个浏览器选项卡的内存中。所以数据模型本身也会导致性能问题，更不用说渲染了。
(1)是通过一种叫做滚动虚拟化的方法来解决的。有很多类似TankStack Virtual的库。ag-grid也实现了该技术的自己的版本。基本上，这些解决问题的方法是只呈现适合用户屏幕的行。通常，浏览器会占用资源来呈现用户看不到的行，即使这些行被滚动出屏幕。但是随着虚拟化的到位，当用户滚动时，它会在可见区域内将行交换为新行。
您可以通过使用DOM检查器来定位行来看到这一点。请注意，当您上下滚动时，它们都将被动态替换。
(2)是个大问题1GB是非常大的，你永远不可能希望加载所有的一次去。这通常通过某种形式的分页或流来解决。单靠ag-grid不会有帮助，你还需要后端重新思考。您几乎肯定需要将数据存储在数据库中，然后您的后端可以将其分页到前端。注意“分页”是一个古老的术语，一直沿用至今。这并不意味着你需要谷歌风格的页面选择。这只是意味着你的服务器有一个API可以获取数据块。UI仍然可以在用户滚动时无缝地获取这些。
因此，当用户滚动时，它会按需下载数据的一个小子集，以方便下一批行。有时这被称为“延迟加载”。对于您拥有的数据级别，如果客户端缓存的行达到一定数量，您可能还需要从内存中删除旧页面，如果用户滚动回该点，则需要再次获取这些页面。这样做的原因是限制选项卡的内存需求，否则可能会崩溃。
我怀疑ag-grid网站上的例子避免了这一点，因为它在客户端动态地合成生成数据，因为它在不同大小的表之间切换时不请求任何网络数据。所以在这个例子中他们不处理（2）。虽然像ag-grid这样的东西可以与这种方法一起使用，而且它们也可能提供这种方法的例子。
下载整个1GB的数据永远不会工作，即使忽略等待页面加载的许多分钟的明显可用性问题。内存太大了。您的服务器必须按需增量地提供此服务。这允许您的客户端在任何给定时间请求它所需的位，同时保持在一些合理的内存要求之内。
如果你有这个，和一些虚拟化来管理渲染性能（如ag-grid或其他库），它可以以一种高性能的方式工作。
所以回到你原来的点，它崩溃的原因是ag-grid被用在这样一种方式，它只解决了（1）而不是（2）。你还需要（2）来让它工作而不崩溃这个级别的数据，这需要：
1.后端更改，以便能够在浏览器请求的范围内通过API以块的形式递增地提供数据。
1.与ag-grid的后端API集成。