<textarea>无法实现富文本编辑器核心区域嵌套，因其仅支持纯文本；必须使用contenteditable="true"的<div>或<iframe>容器，前者轻量推荐，后者隔离性强。
<textarea> 标签本身无法实现富文本编辑器的核心区域嵌套，因为它只支持纯文本输入，不解析 HTML、不渲染样式、不支持内联格式（如加粗、颜色、图片）、也不允许插入或嵌套任何 DOM 节点。
真正能支撑“嵌套结构”的富文本核心区域，必须使用 contenteditable="true" 的容器元素（如 <div> 或 <iframe>），而非 <textarea>。
为什么 <textarea> 不适合做富文本核心区域
- 内容始终是纯字符串，无法包含
<strong>、<p>、<img>等标签； - 无法设置光标在某个
<span style="color:red">内部并继续编辑； - 不支持
document.execCommand或现代 Selection/Range 操作； - 所有格式化需求（如加粗、列表、对齐）都需额外层模拟（比如双写 Markdown），不是真正的所见即所得。
✅ 正确做法：放弃
<textarea>作为编辑区，改用语义化、可嵌套的contenteditable容器。
实现嵌套结构的两种主流方式
1. contenteditable + <div> 根容器（轻量、现代、推荐）
- 根节点必须是
<div contenteditable="true">，不能是<p>或<section>，否则浏览器回车行为混乱（Chrome 插<div>，Firefox 插<p>）； - 初始化时显式构建嵌套块结构，例如：
<div id="editor" contenteditable="true"> <p data-block="paragraph"><br></p> <p data-block="paragraph"><br></p> </div>
- 通过
keydown拦截 Enter、Backspace 等键，结合window.getSelection()和RangeAPI 手动拆分/合并段落； - 所有行内格式（如加粗）应包裹在
<span data-inline>中，避免污染块级语义； - 粘贴内容必须在
paste事件中清洗，过滤 Word 生成的冗余<span style="mso-...">、无意义<div>嵌套等。
2. <iframe> + designMode="on"（隔离强、兼容老浏览器）
- 创建独立文档上下文，完全避免主页面样式/脚本干扰；
- 初始化流程严格：
src="about:blank"- 监听
iframe.onload -
iframe.contentDocument.open()→ 写入带<body>的 HTML →close() - 设
designMode = "on"
- 所有
execCommand必须调用iframe.contentDocument.execCommand(...)，否则无效； - 支持天然嵌套：
<body>→<p>→<strong>→<em>可自由组合，浏览器默认维护层级。
⚠️ 注意：
<iframe>模式下，工具栏按钮触发命令时，必须明确指向 iframe 内部 document，不可误用顶层document。立即学习“前端免费学习笔记（深入）”；
嵌套的关键控制点（无论哪种方案）
-
块级容器统一标记：用
data-block="paragraph"、data-block="list-item"区分语义，便于后续序列化和校验； -
禁止自动塌陷：用户删除所有内容后，确保至少保留一个空
<p><br></p>，防止编辑区“消失”或失去焦点； - 光标位置稳定：每次输入/粘贴/格式操作后，主动 restore selection，避免浏览器重置 Range 到意外位置；
-
结构校验与修复：在
input或compositionend后扫描 DOM，把意外生成的<div>提升为<p>，把孤立文本节点包进<span data-inline>。
不复杂但容易忽略。
