“现代”，因为该定义可能会随着时间而改变(特别是我的意思是桌面浏览器)
“句柄”，因为这可能会因机器配置/内存而异，但具体而言，我指的是一般用例。
这个问题是在我试图解决涉及大型数据集的特定问题时想到的。
基本上，每当对特定数据集进行更改时，我都会取回完整的数据集，并且必须在浏览器中呈现这些数据。
因此，例如，通过 websocket，我收到一个推送事件，告诉我数据集发生了变化，然后我必须通过抓取现有 DOM 元素、复制它、使用来自此的数据填充元素来以 HTML 格式呈现此数据集使用类名或其他元素标识符进行设置，然后将其添加回 DOM。
请记住，此数据集中的任何对象 (JSON) 可能有多达 1000 多个子对象，并且可能有多达 10,000 多个父对象，因此您可以看到可能存在返回的实例数据集向上接近 1,000,000 => 10,000,000 个数据点或更多。
现在，当我必须渲染这些东西时，有趣的部分就来了。对于每个数据点，可能有 3 或 4 个标签用于渲染和设置数据样式，并且这些标签中的任何一个都可能有事件监听器(可能在父容器上使用委托(delegate)来减轻负担)。
总而言之，可能需要呈现大量传入信息，我正在尝试找出处理这种情况的最佳方法。
理想情况下，您只想渲染具有更改的单个数据点的更改，而不是重新渲染整个数据集，但由于后端的设计方式，这可能不是一个选项。
我主要关心的是了解浏览器/DOM 的局限性，并通过前端的镜头来看待这个问题。后端肯定会发生一些变化(数据设计、缓存、分页)，但这不是这里的重点。
这不是 HTML/DOM 的典型用例，因为我知道存在限制，但它们到底是什么？我们仍然限制在大约 3000-4000 个元素吗？
我有一些 related subquestions为此，我是 actively looking up但我认为与 stackoverflow 社区的其他成员分享一些想法并尝试将有关此问题的一些信息汇总在一起会很好。
现代浏览器在开始变慢/无响应之前可以处理的“合理”数量的 DOM 元素是多少？
如何对浏览器可以处理的 DOM 元素数量进行基准测试？
有哪些strategies用于处理需要渲染的大型数据集(分页除外)？
像 mustache 和 handlebars 这样的模板框架在从 data/json(在前端)渲染 html 方面是否比使用 jQuery 或正则表达式更高效？
最佳答案
您的答案是:1 或数百万。我将复制/粘贴关于 SO 的类似问题的答案。
To be honest, if you really need an absolute answer to this question, then you might want to reconsider your design.
No answer given here will be right, as it depends upon many factors that are specific to your application. E.g. heavy vs. little CSS use, size of the divs, amount of actual graphics rendering required per div, target browser/platform, number of DOM event listeners etc..
Just because you can doesn't mean that you should! :-)"
见:how many div's can you have before the dom slows and becomes unstable?
这确实是一个无法回答的问题，有太多的因素在太多的角度。然而，我会这么说，在单个页面加载中，我使用 1 毫秒的 javascript setinterval 不断向 ID 递增 1 的页面添加新的 div。我的 Chrome 浏览器刚刚超过 20,000，并且正在使用 600MB 内存。
关于html - "modern"浏览器 "handle"一次可以有多少个 HTML 元素？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/21611822/