contenteditable="true"不是开箱即用的编辑开关，必须配合tabindex="0"、paste拦截、enter处理等才能安全可用；否则易致光标丢失、xss漏洞或格式混乱。

contenteditable 不是“加了就能用”的开关，它是浏览器编辑引擎的启动键——没配好 tabindex、不拦 paste、不处理 Enter，轻则光标消失，重则 XSS 漏洞上线。

为什么写了 contenteditable="true" 却点不动或 Tab 进不去

因为 div、p、td 这类非表单元素默认不可键盘聚焦，contenteditable 不会自动补上可访问性支持。

• 必须显式加 tabindex="0"：让元素进入 Tab 链，支持快捷键（如 Ctrl+B）和 Selection API
• 只写 tabindex="-1"：只能靠 JS 调用 .focus()，无法键盘切换，document.execCommand 也失效
• CSS 中若存在 pointer-events: none 或 user-select: none，会彻底屏蔽点击

paste 事件不拦截，粘贴进来就是 XSS 风险

复制自微信、Word、网页的内容，浏览器默认以完整 HTML 片段插入，可能带内联样式、不可见字符，甚至 <img onerror="alert(1)">。

Article To Html

文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。

下载

• 用 event.clipboardData.getData('text/plain') 提纯文本最稳妥
• 别依赖 contenteditable="plaintext-only"：不是标准值，Firefox 忽略，Safari 行为不统一
• 避免直接用 document.execCommand('insertText')：该 API 已废弃，Chrome 98+ 移除部分命令

表格里直接用 contenteditable 的三大硬伤

在 <td> 上写 <code>contenteditable="true" 看似简单，但真实场景中几乎必踩坑：

• 回车行为不一致：Chrome 插入 <div>，Firefox 插入 <code><p></p>，Safari 可能插 <br>，破坏表格结构
• 移动端光标定位异常，长按选词后焦点丢失
• 无法设置 type="number"、maxlength、inputmode 等原生校验与输入优化能力

“点击才编辑”不是靠属性，而是靠状态切换

用户要的是“点击前是展示态，点击后才变编辑态”，而 contenteditable="true" 是永久可编辑——这和交互预期根本冲突。

• 初始状态应移除 contenteditable 属性，只保留纯文本
• 点击时动态添加 contenteditable="true" 并调用 .focus()
• 把原始内容暂存到 data-prev-value，用于 ESC 取消时还原
• 监听 blur（别用 input）：Safari 不触发 input 事件；用 textContent 取值，别用 innerHTML 防 XSS

真正难的不是让文字可编辑，而是控制它什么时候可编辑、怎么编辑、编辑完怎么收口。这些边界逻辑一旦漏掉，就不是“功能可用”，而是“随时崩坏”。