contenteditable="true"不是开箱即用的编辑开关，必须配合tabindex="0"获焦、拦截paste/enter、清洗html、动态控制状态才能安全使用。
contenteditable 不是“加了就能用”的开关，它开对了，3 行 HTML 就能跑；开错了，回车变 <div>、粘贴带 <code><script></script>、移动端点不聚焦——全是没管住的副作用。
为什么加了 contenteditable="true" 还是点不动
最常见原因是元素无法获焦：原生 <div>、<code><p></p> 默认不在 Tab 链里，键盘和 el.focus() 都无效。
- 必须显式加
tabindex="0"（推荐）或tabindex="-1"（仅 JS 可聚焦） - 检查父容器是否写了
contenteditable="false"——该属性遵循“就近false优先”，子元素设true也无效 - 确认 CSS 没禁用交互：
user-select: none、pointer-events: none、display: contents都会让编辑失效 - 别加在
<input>或<textarea></textarea>上——浏览器静默忽略，且可能干扰原生行为
怎么安全获取和清洗用户输入内容
innerHTML 直接暴露 XSS 风险，textContent 又丢格式。得按需选，并主动清洗。
- 纯文本场景：用
el.textContent，它不执行脚本、不渲染标签，适合校验或后端存 plain text - 需保留简单格式（如换行、粗体）：取
el.innerHTML，但必须过滤——推荐用DOMParser解析后白名单遍历，只留<p></p>、<strong></strong>、<br>、<ul>/</ul> <ol>/<li> </ol>，删掉所有style、class和未知标签 - 绝对别用正则替换 HTML 字符串：
innerHTML.replace(/<script.>/gi, '')</script.>容易漏变体或闭合错误，导致 XSS - 若业务允许，粘贴时直接走
event.clipboardData.getData('text/plain')，跳过 HTML 解析更轻量也更安全
如何控制回车、粘贴和中文输入行为
浏览器默认行为几乎都不符合实际需求：回车插标签、粘贴带 Word 样式、中文上屏漏字——全得拦截重写。
- 回车：监听
keydown，对Enter调e.preventDefault()，再根据需要插入\n（纯文本）或<br>（HTML 场景） - 粘贴：监听
paste，e.preventDefault()后取e.clipboardData.getData('text/plain')或解析'text/html'，再用document.execCommand('insertText', false, text)（虽已废弃但目前最稳）或RangeAPI 插入到光标位置 - 中文输入：必须监听
compositionstart和compositionend，否则拼音上屏瞬间内容会丢失；input事件在 composition 结束后才触发，不能替代 - 别只靠
input事件：它漏掉execCommand格式操作、拖拽插入、撤销重做；关键场景建议组合input+compositionend+MutationObserver
为什么不能只靠 contenteditable 实现“点击编辑”
“点击才开始编辑”和“天生可编辑”是两回事。contenteditable="true" 让元素始终处于可编辑态，用户一进页面就能乱输，不符合交互预期。
- 真实需求是：点击前为展示态（带 hover 效果），点击后才激活编辑态（输入框或内联编辑），且编辑完成要自动保存或取消
- 这需要手动控制状态切换：初始移除
contenteditable属性；点击时动态添加并调.focus()；blur时比较新旧值决定是否保存 - 按
Escape取消：监听keydown，判断e.key === 'Escape'，然后还原内容 + 移除属性 +blur - 表格等结构敏感场景，强烈推荐用
<input>覆盖方案——支持原生校验、type="number"、maxlength，光标和样式都可控
最易被忽略的是：contenteditable 本身不提供版本、序列号或冲突检测能力。多人协同时，它只是个本地 DOM 开关，所有同步、光标定位、合并逻辑都得靠 JS 主动实现，且必须放弃 innerHTML 全量替换——DOM 结构稍有差异，diff 就崩。
