为何修改IE11及更低版本的innerText会永久销毁所有后代文本节点

textContent 和 innerText 被修改时都会移除子节点，但在 Internet Explorer 11 及更低版本中修改 innerText 还会永久销毁所有后代文本节点。执行该操作后，无法再将这些节点插入到任何其他元素或同一元素中。

IE低版本该特殊行为的设计初衷 #

innerText本身是微软在IE4时期首次推出的非标准API，这个销毁后代文本节点的设计完全适配当时IE的技术架构和时代背景，核心考量有三点：

• 性能适配早期硬件水平
  90年代末个人电脑硬件性能普遍较差，浏览器的DOM内存管理机制也十分简陋。绝大多数场景下开发者修改innerText的目的都是完全替换元素内的可见内容，不会复用原有的后代文本节点。直接销毁这些节点可以省去维护闲置节点引用的开销，也能降低内存泄漏风险、减少垃圾回收的压力，对当时的性能提升有明确收益。
• 简化引擎实现逻辑
  早期IE的渲染引擎和DOM引擎耦合度极高，而innerText本身的设计就是和渲染状态强绑定的：它返回的是元素渲染后的可见文本，会自动忽略隐藏元素内容、合并空白符、保留换行格式。修改innerText时直接销毁所有后代文本节点，不需要处理这些节点和渲染树的绑定解绑逻辑，也不用额外兼容后续节点重新插入时的样式重计算逻辑，大幅降低了引擎的实现复杂度。
• 缺乏统一标准约束
  innerText推出时W3C还没有出台对应的DOM标准规范，微软可以完全自主定义API的行为，也没有其他浏览器的实现作为参考。当时的设计优先适配IE内部的架构逻辑，并没有考虑到后续开发者复用原有文本节点的需求，这个不符合现代标准的行为就一直保留到了IE11。

后续W3C把innerText纳入标准后，其他浏览器的实现都没有沿用这个销毁节点的破坏性设计，微软推出Chromium内核的Edge浏览器后也完全匹配了标准行为，只有IE11及更低版本会存在这个特殊表现。

内容的提问来源于stack exchange，提问作者Eugene。