浅拷贝不会直接导致富文本编辑器嵌套引用渲染错乱，但对AST或自定义节点树浅拷贝后修改会因共享引用污染状态，引发标签嵌套、样式丢失等问题；应使用编辑器官方克隆方法或手动深拷贝关键字段，并确保插入逻辑与拷贝方式对齐。
浅拷贝本身不会直接导致富文本编辑器“嵌套引用渲染错乱”，但当富文本内容以嵌套 JavaScript 对象（如 AST 节点树、自定义 rich-text nodes 结构）形式被浅拷贝后，再进行插入、修改或序列化操作，就极易引发 DOM 渲染异常——比如标签意外嵌套、样式丢失、节点重复、甚至解析中断。根本原因在于：浅拷贝保留了子对象的内存引用，而富文本编辑器底层往往依赖节点的独立性与可变状态（如 parent、children、isDirty 等字段）。一旦多个地方共用同一子节点引用，一处修改就会污染其他上下文。
识别是否是浅拷贝引发的问题
出现以下现象时，应优先排查数据拷贝方式：
- 在编辑器中插入一段结构化内容（如带样式的段落+列表），之后调用
editor.insertContent(cloneData)，结果新内容被包裹进前一个段落内部，而非作为兄弟节点追加 - 使用
JSON.parse(JSON.stringify(node))处理 rich-text node 后，渲染时丢失事件绑定、自定义属性或data-*字段（因 JSON 序列化会丢弃函数、undefined、Symbol 和原型链） - 对备份后的编辑器内容做格式清理（如移除冗余
），原始内容的对应节点也同步被修改
富文本场景下推荐的安全拷贝策略
不要依赖 Object.assign()、[].slice() 或 structuredClone()（部分旧环境不支持）处理富文本节点结构。应按层级和用途选择：
- 纯 HTML 字符串内容：无需拷贝，直接传参；若需清洗，用正则或 DOMParser 解析后再序列化，避免 JS 对象引用问题
-
AST 类型节点（如 draft-js、slate、quill delta）：使用编辑器官方提供的克隆方法（如
node.clone()、editor.convertToRaw()+editor.createWithContent()） -
自定义 rich-text nodes 数组（如微信小程序 rich-text 的 nodes 字段）：手动深拷贝关键字段，跳过不可序列化属性（
el、ref、onTap函数等），示例：
nodes.map(n => ({ ...n, children: n.children ? deepCloneNodes(n.children) : undefined }))
插入逻辑必须与拷贝方式对齐
即使做了深拷贝，若插入时机或位置控制不当，仍会触发嵌套。关键要确保每次插入都落在“编辑器内容末尾”或“指定容器外部”，而不是当前光标所在的某个可编辑子节点内部：
- 插入前主动将光标移出目标容器：
editor.selection.select(editor.getBody(), true)（TinyMCE）或editor.focus()+editor.selection.collapse(true) - 批量插入时，统一拼接为单个 HTML 字符串再执行一次
mceInsertContent，而非循环调用（避免光标滞留导致嵌套） - 若必须逐个插入，每次插入后显式重置光标位置：
editor.execCommand('mceInsertContent', false, html); editor.selection.setCursorLocation();
跨平台渲染前务必做白名单净化
富文本最终渲染错乱，常因未过滤非法嵌套或平台不支持的结构。无论数据来源是否经过深拷贝，都应在渲染前强制执行结构校验：
- 微信小程序
p、span、strong、img等） - React Native WebView：用
htmlparser2构建 AST，遍历检查parent引用是否形成环状结构（即 A→B→A），有则打断并降级为文本 - 通用建议：对所有
children数组执行Array.isArray()校验，防止字符串误作数组导致渲染引擎解析崩溃
