设置contenteditable="true"的div采用何种数据结构存储文本？

首先给明确结论：HTML标准从未强制规定contenteditable="true"元素的内部内容存储结构，具体实现完全由浏览器自身的排版引擎决定，不存在跨浏览器的统一方案。
你提到的两种纯文本编辑器常用存储结构，以及“每次修改都重新生成完整普通字符串”的方案，都和主流浏览器的实际实现有偏差：

• 没有任何主流现代浏览器会采用“每次修改全量重建完整字符串”的方案：这种实现在大文本编辑场景下性能差到完全不可用，属于早就被淘汰的早期简易引擎逻辑。
• 主流引擎也不会直接照搬rope、gap buffer这类纯文本编辑器专用结构：contenteditable编辑的不是线性纯文本，而是带层级、带样式的富内容，内部本质是维护一棵实时更新的DOM节点树——你在编辑区输入、删除、修改格式的所有操作，本质都是对这棵DOM树做节点增删改，而非修改一段线性文本。
  当然，针对DOM树里的单个长文本节点，部分引擎会做底层存储优化，比如用分段存储、类rope的结构降低大段文本插入删除的性能开销，但这是DOM文本节点本身的通用优化，不是contenteditable单独为编辑场景设计的专属存储结构。

这里要澄清一个常见误解：很多人以为contenteditable是用字符串存储内容，是因为调用innerHTML、textContent这类API时拿到的是完整字符串，但这只是接口对外输出的序列化结果，不是内部的实际存储形态。日常编辑过程中引擎不会维护这么一整串待修改的字符串，只有当你主动调用上述API时，才会临时遍历DOM树序列化出对应字符串返回。

本质上contenteditable的存储逻辑和普通非可编辑div没有区别，只是浏览器额外给它加了输入响应、选区管理、编辑命令处理的相关逻辑。和那些自己接管输入渲染、绕开原生编辑行为的独立编辑器不同，它不需要专门为纯文本编辑选择rope、gap buffer这类线性存储结构，因为它从底层设计上就不是为纯文本编辑场景服务的。

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