contenteditable 必须与 tabindex="0" 配合才能真正响应键盘输入；其值仅支持 true、false、inherit 和空字符串；需拦截 paste/enter 等事件并清洗 HTML 以保障行为一致性和安全性。
contenteditable 不是开关，是行为入口；单独加它几乎没用，必须配 tabindex="0" 才能真正响应键盘输入。
为什么加了 contenteditable="true" 还是点不进去、Tab 不进去
浏览器默认只让表单控件（input、textarea 等）进入键盘焦点流。div、p 这类元素即使有 contenteditable，也不自动获得 tabindex，所以：
- 鼠标点击能聚焦 → 是浏览器的“点击编辑”兜底逻辑，但仅限鼠标，不触发完整编辑上下文（比如
document.execCommand无响应） - 按 Tab 跳不过去 → 缺
tabindex="0"，该元素不在自然 tab 流中 - Ctrl+B / Ctrl+I 快捷键无效 → 没焦点，Selection API 和命令系统压根收不到事件
- 移动端点一下就失焦 → Safari 和部分 Android WebView 对无
tabindex的contenteditable元素支持极差
正确写法只有这一种组合：<div contenteditable="true" tabindex="0" spellcheck="false">内容</div>
contenteditable 的值不是布尔字符串，而是有限枚举
它只认四个值：true、false、inherit、空字符串（contenteditable），其余全是无效写法：
立即学习“前端免费学习笔记（深入）”；
-
contenteditable="on"、contenteditable="1"、contenteditable="plaintext-only"→ 浏览器直接忽略，退化为inherit，可能意外继承父级的false - 只写
contenteditable（无等号无值）→ 大部分现代浏览器当true，但旧版 Safari 行为不稳定，不推荐 - 父级设了
contenteditable="false"→ 子元素显式写contenteditable="true"也无效，“就近 false 优先”是硬规则
所以判断是否可编辑，不能只看子元素，得向上查所有祖先节点的 contenteditable 值。
粘贴、回车、删除行为失控的根本原因
contenteditable 的底层是浏览器把用户操作映射成 HTML 片段，不是纯文本流。这就导致：
- 回车：Chrome 插入
<div></div>，Firefox 插入<br>，Safari 插入<p></p>—— 语义不一致，后续解析难统一 - 粘贴 Word 或网页内容：带
<style>、<meta>、甚至<script>，XSS 风险真实存在 - 删到块开头时：相邻
<p>可能被合并，或整段被删掉，跨浏览器行为不可预测
必须主动拦截：
- 监听
paste事件，用event.clipboardData.getData('text/plain')提纯文本 - 拦截
keydown.enter，event.preventDefault()后手动插入<div><br></div>或其他可控结构 - 用
MutationObserver替代已废弃的DOMSubtreeModified，监听并清洗非法标签（如<script>、<iframe>）
data-* 和 id 与 contenteditable 的常见误用边界
它们都用于标识，但作用域和使用方式完全不同：
-
data-*是运行时数据容器：命名必须小写+连字符（data-user-id），JS 中需通过el.dataset.userId访问；值始终是字符串，不参与样式、无障碍或 SEO -
id是文档级锚点：必须全局唯一，首字符只能是字母或下划线；CSS、document.getElementById()、页面内跳转（#header）、ARIA 属性（如aria-labelledby）都依赖它 - 最容易被忽略的是：
contenteditable元素若要绑定 ARIA 标签（如aria-label），必须配合有效id；而data-id再多，对无障碍完全无效
真正静默失效的点往往在这里：属性写了，控制台不报错，但屏幕阅读器读不出、快捷键没响应、粘贴后内容错乱——问题不在代码语法，而在这些组合规则没对齐。
