TinyMCE setContent 后撤销导致内容被清空的问题分析
在使用 TinyMCE 进行富文本编辑开发时，程序动态设置编辑器内容是一个非常常见的操作。例如在接口返回数据后，通过 setContent 将文章内容写入编辑器，或者在某些业务场景中重新加载编辑内容。
在实际开发过程中，会遇到一个比较隐蔽的问题：当通过 setContent 设置内容之后，如果用户执行撤销操作（Undo），在多次撤销后，最后一次撤销会导致编辑器内容被完全清空。
这一行为在很多场景中都会被误认为是编辑器异常，但实际上这是 TinyMCE 撤销管理机制（UndoManager）所导致的一种正常表现。
问题现象
在编辑器中通过 setContent 设置内容，例如：
editor.setContent(html)用户在编辑器中进行修改后，连续执行撤销操作时，会出现如下行为：
- 第一次撤销，恢复到上一步编辑状态
- 第二次撤销，恢复到更早的编辑状态
- 当撤销到最后一步时，编辑器内容被完全清空
最终结果是编辑器恢复到一个空内容状态。
产生问题的原因
TinyMCE 内部通过 UndoManager 来维护编辑器的历史状态。每一次编辑操作都会形成一个 undo level，并被记录在撤销栈中。
在调用 setContent 时，TinyMCE 会把当前内容状态加入到撤销历史中，但撤销栈中的初始状态通常是一个空内容节点。因此，当用户不断执行撤销操作时，撤销栈会逐步回退，直到回到最初的状态。
一个典型的撤销栈结构可能如下：
[
"",
"<p>文章内容</p>",
"<p>文章内容修改 1</p>",
"<p>文章内容修改 2</p>"
]在这种情况下：
- 用户第一次撤销 → 回到
修改 1 - 用户第二次撤销 → 回到
文章内容 - 用户第三次撤销 → 回到
""
因此编辑器最终变为空内容。
解决方案
在调用 setContent 之后，需要对 UndoManager 的历史记录进行重置，使当前内容成为新的初始状态。
实现方式如下：
editor.setContent(html)
editor.undoManager.clear()
editor.undoManager.add()执行过程为：
setContent写入新的编辑器内容undoManager.clear()清空已有的撤销历史undoManager.add()将当前内容作为新的初始状态加入撤销栈
这样处理后，撤销历史的结构会变为：
[
"<p>文章内容</p>"
]之后用户在编辑器中的所有修改，都会基于这个状态产生新的撤销记录。
当用户执行撤销操作时，编辑器只会回退到最近的编辑状态，而不会回退到空内容。
实际使用场景
在实际项目中，这种处理方式通常用于以下场景：
- 编辑文章时加载服务器返回的内容
- 切换文档或模板时更新编辑器内容
- 通过接口动态刷新编辑器内容
- 富文本表单初始化
例如在加载接口数据时：
function loadContent(html) {
const editor = tinymce.activeEditor
editor.setContent(html)
editor.undoManager.clear()
editor.undoManager.add()
}这样可以确保：
- 用户撤销不会回退到空内容
- 编辑器历史记录保持正常
- 撤销与重做行为符合用户预期
总结
在使用 TinyMCE 进行富文本编辑开发时， setContent 会影响编辑器的撤销历史。如果不对 UndoManager 进行处理，撤销操作可能会回退到编辑器的初始空状态，从而导致内容被清空。
通过在设置内容后清空撤销栈，并将当前内容作为新的历史起点，可以保证撤销行为的稳定性，使编辑器在动态加载内容的场景下仍然保持正确的编辑体验。
