我目前正在调试一个 ajax 聊天，它会用 DOM 元素无休止地填充页面。如果你有 3 个小时的聊天时间，你会发现上帝现在有多少个 DOM 节点。
extreme DOM 使用有哪些问题？
用户界面是否可能完全没有响应（尤其是在 Internet Explorer 中）？
（和这个问题相关的是off course the solution，如果除了手动垃圾收集和去除dom节点之外还有其他解决方案。）
【问题讨论】：
标签： javascript performance dom chat
拥有很多 DOM 节点应该不是什么大问题（除非客户端内存不足）；但是，操作大量的 DOM 节点会很慢。例如，如果您对 100 个元素执行此操作，则循环遍历一组元素并更改每个元素的背景颜色很好，但如果您在 100,000 个元素上执行此操作可能需要一段时间。此外，一些旧浏览器在处理巨大的 DOM 树时会出现问题——例如，滚动浏览具有数十万行的表格可能会慢得无法接受。
一个很好的解决方案是缓冲视图。基本上，你只显示在任何给定时刻在屏幕上可见的元素，当用户滚动时，你删除隐藏的元素，并显示那些被揭示的元素。这样一来，树中 DOM 节点的数量就相对固定了，但你并没有真正失去任何东西。
另一个类似的解决方案是对在任何给定时间显示的消息数量实施上限。这样，任何超过 100 条的消息都会被删除，要查看它们，您需要单击显示更多信息的按钮或链接。如果您需要参考，这就是 Facebook 对他们的个人资料所做的事情。
【讨论】：
extreme DOM 使用问题可以归结为性能问题。 DOM 脚本非常昂贵，因此不断访问和操作 DOM 会导致性能（和用户体验）不佳，尤其是当元素数量变得非常多时。
考虑 HTML 集合，例如 document.getElementsByTagName('div')。这是对文档的查询，每次需要最新信息时都会重新执行，例如集合的长度。这可能导致效率低下。在循环内访问和操作集合时会发生最坏的情况。
有很多注意事项和示例，但就像任何事情一样，它取决于应用程序。
【讨论】：
大多数现代浏览器应该能够很好地处理巨大的 DOM 树。而“大多数”通常不包括 IE。
是的，您的浏览器可能会变得无响应（因为它需要太多 RAM -> 交换）或者因为它的渲染器不堪重负。
标准的解决方案是删除元素，比如在页面有 10'000 行的聊天内容之后。即使是 100'000 行也不应该是一个大问题。但是对于比这大得多的数字（比如数百万行），我会开始感到不安。
[编辑] 另一个问题是内存泄漏。即使 JS 使用垃圾回收，如果您在代码中出错并在全局变量中保留对已删除 DOM 元素的引用（或来自全局变量的对象引用），即使页面本身仅包含一些一千个元素。
【讨论】：