contenteditable="plaintext-only"仅chrome 121+支持，firefox和safari忽略该值，需配合paste事件拦截与clipboarddata提取纯文本才能实现跨浏览器一致的纯文本编辑。
contenteditable="plaintext-only" 在 Chrome 121+ 才真正生效
设为 plaintext-only 并不会让所有浏览器都禁用富文本——它是个“有条件支持”的值：Chrome 121+ 开始按规范实现，Firefox 和 Safari 当前（2026年8月）仍直接忽略该值，退化为 inherit 或 fallback 到默认粘贴行为。这意味着你写 contenteditable="plaintext-only"，在 Safari 里可能完全没用，用户照样能粘贴带 <script></script> 的 HTML。
实操建议：
- 不要单独依赖
plaintext-only做安全控制，必须配合paste事件拦截 +event.clipboardData.getData('text/plain')提取纯文本 - 若需跨浏览器一致的纯文本编辑体验，显式设
contenteditable="true"+onpaste="return false"+ 手动插入文本更可靠 -
plaintext-only不影响键盘输入（如加粗、斜体快捷键仍可能触发），它只约束粘贴来源
回车换行渲染差异： vs
vs
设为 true 时，不同浏览器对 Enter 键的处理完全不同：Chrome 默认插入 <div>，<code>Firefox 插入 <br>，Safari 插入 <p></p>。这导致 innerHTML 结构不可控，后续解析、存储、渲染都容易出错。
而 plaintext-only（在支持它的 Chrome 中）会把 Enter 当作普通换行符 \n 处理，不生成任何标签，innerHTML 里只看到文本加 <br> 或纯 \n（取决于是否启用 white-space: pre-wrap）。但注意：它不阻止用户手动输入 HTML 标签字符，比如敲 <b>test</b> 仍会原样存入。
常见错误现象：
- 服务端收到一堆嵌套
<div><div>
<p>，解析失败
</p>
<li>CSS 用 <code>p + p 做段间距，结果 Chrome 里没 <p></p> 标签，样式失效
- 移动端软键盘回车后光标消失或跳到顶部
样式与焦点行为其实没区别
plaintext-only 和 true 都不改变元素的可聚焦性、CSS 伪类响应或默认编辑样式。两者都需要手动加 tabindex="0" 才能用 Tab 键进入，都需要 :focus CSS 控制边框/背景，也都受 user-select 和 outline 影响。
关键区别只在「粘贴」和「回车」两个动作的底层 DOM 行为上，其余表现一模一样。别指望设了 plaintext-only 就自动获得干净的 textarea 体验——它不提供 placeholder、不支持 maxlength、不触发 change 事件，这些都得自己补。
为什么不能用 getAttribute('contenteditable') 判断当前状态
读 element.getAttribute('contenteditable') 只返回你写的原始字符串，比如 "plaintext-only"；但浏览器实际执行的可编辑逻辑，由 element.contentEditable（返回 "true"/"false"/"plaintext-only"）和 element.isContentEditable（布尔值，综合继承、CSS、父级锁死等）共同决定。尤其当祖先节点设了 contenteditable="false"，子元素即使写了 plaintext-only，isContentEditable 也会是 false。
所以判断是否真能编辑，唯一靠谱的是：
- 用
element.isContentEditable（只读布尔）
- 监听
input 事件看是否触发
- 避免用
getAttribute 或字符串比较做条件分支
最易被忽略的一点：即使 contentEditable === "plaintext-only"，也不能假设内容就是纯文本——用户仍可手动输入标签字符，DOM 结构仍可能被破坏，生产环境必须清洗 innerHTML 或只取 textContent。
vs
设为 true 时，不同浏览器对 Enter 键的处理完全不同：Chrome 默认插入 <div>，<code>Firefox 插入 <br>，Safari 插入 <p></p>。这导致 innerHTML 结构不可控，后续解析、存储、渲染都容易出错。
而 plaintext-only（在支持它的 Chrome 中）会把 Enter 当作普通换行符 \n 处理，不生成任何标签，innerHTML 里只看到文本加 <br> 或纯 \n（取决于是否启用 white-space: pre-wrap）。但注意：它不阻止用户手动输入 HTML 标签字符，比如敲 <b>test</b> 仍会原样存入。
常见错误现象：
- 服务端收到一堆嵌套
<div><div> <p>，解析失败 </p> <li>CSS 用 <code>p + p做段间距，结果 Chrome 里没<p></p>标签，样式失效 - 移动端软键盘回车后光标消失或跳到顶部
- 用
element.isContentEditable（只读布尔） - 监听
input事件看是否触发 - 避免用
getAttribute或字符串比较做条件分支
样式与焦点行为其实没区别
plaintext-only 和 true 都不改变元素的可聚焦性、CSS 伪类响应或默认编辑样式。两者都需要手动加 tabindex="0" 才能用 Tab 键进入，都需要 :focus CSS 控制边框/背景，也都受 user-select 和 outline 影响。
关键区别只在「粘贴」和「回车」两个动作的底层 DOM 行为上，其余表现一模一样。别指望设了 plaintext-only 就自动获得干净的 textarea 体验——它不提供 placeholder、不支持 maxlength、不触发 change 事件，这些都得自己补。
为什么不能用 getAttribute('contenteditable') 判断当前状态
读 element.getAttribute('contenteditable') 只返回你写的原始字符串，比如 "plaintext-only"；但浏览器实际执行的可编辑逻辑，由 element.contentEditable（返回 "true"/"false"/"plaintext-only"）和 element.isContentEditable（布尔值，综合继承、CSS、父级锁死等）共同决定。尤其当祖先节点设了 contenteditable="false"，子元素即使写了 plaintext-only，isContentEditable 也会是 false。
所以判断是否真能编辑，唯一靠谱的是：
最易被忽略的一点：即使 contentEditable === "plaintext-only"，也不能假设内容就是纯文本——用户仍可手动输入标签字符，DOM 结构仍可能被破坏，生产环境必须清洗 innerHTML 或只取 textContent。
