contenteditable="true"在子元素中不生效，因遵循“就近false优先”规则：任一祖先设contenteditable="false"即覆盖子级true；且必须配tabindex="0"才能获得焦点和快捷键支持。
contenteditable="true"为什么在子元素里不生效
因为 contenteditable 遵循“就近 false 优先”规则：只要任意祖先节点设置了 contenteditable="false"，哪怕子元素显式写 contenteditable="true"，也完全无效。
常见错误场景：
- 父级
<div contenteditable="false">包裹了可编辑区域，结果整个区域点不动 - 组件库或框架默认给根容器加了
contenteditable="false"（比如某些 CMS 编辑器外壳），子节点白配true - 误用
contenteditable="on"或contenteditable="1"—— 这些值浏览器直接忽略，退化为inherit，最终继承到false
验证方法：用 DevTools 检查目标元素的 computed contenteditable 值，不是看 attribute，而是看最终解析结果。
为什么点了能输字，但 Ctrl+B 没反应
因为没焦点。contenteditable 不会自动让非表单元素获得键盘焦点，document.execCommand() 和 Selection API 全部依赖有效焦点。
立即学习“前端免费学习笔记（深入）”；
必须手动加 tabindex="0"：
-
tabindex="0"：加入自然 Tab 键顺序，用户可键盘切换进入，推荐首选 -
tabindex="-1"：只能靠 JS 调用el.focus()主动聚焦，无法键盘抵达 - 漏掉这步，鼠标点击能打字，但所有快捷键、选区操作、格式命令全部失效
注意：旧版 Safari 对只写 contenteditable（无等号无值）支持不稳定，务必写全 contenteditable="true" + tabindex="0"。
粘贴带 script 标签？回车变成 <div>？
这是 contenteditable 的默认行为，不是 bug —— 它本就不承诺输出干净 HTML，而是把浏览器原生编辑引擎暴露给你。
关键控制点：
- 拦截
paste事件，用event.clipboardData.getData('text/plain')提纯文本，再用document.execCommand('insertText', false, text)插入（仅作兼容过渡） - 监听
keydown，对Enter调用event.preventDefault()，然后手动插入<br>或自定义分隔符 - 用
MutationObserver监听 DOM 变更，清洗掉<script>、内联style、非法嵌套等危险结构 - Chrome 121+ 支持
contenteditable="plaintext-only"，但 Firefox/Safari 仍无视，不能当主力方案
和 execCommand、designMode 是什么关系
三者同属一套已废弃的编辑 API 体系：designMode='on' 控制整个 iframe 文档，contenteditable 是其细粒度替代，execCommand 是配套命令接口。
现实问题：
-
document.execCommand('bold')在不同浏览器中可能生成<b>、<strong>或带style="font-weight: bold"的 span - Chrome 98+ 移除部分命令，Firefox 标记为 deprecated
- 现代方案应转向
getSelection().getRangeAt(0)+RangeAPI 手动操作 DOM
真正容易被忽略的点：你不是在配置一个编辑器，而是在接管浏览器的编辑引擎——它默认不做任何清洗、约束或语义保证，所有责任都在你手上。
