contenteditable 不是富文本编辑器，仅暴露浏览器底层编辑接口；需手动实现事件控制、格式拦截、粘贴净化和光标管理才能达到可用标准。
contenteditable 本身不是富文本编辑器，只是打开了浏览器内置的编辑能力；要让它真正像富文本编辑器一样用，必须手动补全事件控制、格式拦截、粘贴净化和光标管理。
为什么直接加 contenteditable="true" 不等于富文本编辑器
浏览器对 contenteditable 的实现本质是“暴露底层编辑接口”，而非提供封装好的编辑器。它默认支持加粗（Ctrl+B）、换行（Enter）、粘贴 HTML，但这些行为不可控：
- 回车插入的是
<div></div>或<p></p>，不是\n，后端解析常出错 - 从 Word 粘贴会带大量内联样式、
<span>嵌套、甚至 JS 脚本（XSS 风险） - 没有统一的“加粗”按钮状态反馈，
document.queryCommandState('bold')在 Chrome 120+ 已基本失效 - 移动端软键盘唤起后，光标常卡在顶部或消失，
focus()失效率高
必须监听的三个核心事件：input、paste、keydown
input 是唯一能实时捕获所有变更（包括粘贴、撤销、格式操作）的事件；paste 必须拦截并重写，否则无法过滤 HTML；keydown 用于拦截特定行为（如禁止 Tab 缩进、限制回车语义）：
-
input事件比blur更及时，适合做防抖保存：el.addEventListener('input', () => saveDebounced(el.innerHTML)) -
paste中必须调用event.preventDefault()，再用event.clipboardData.getData('text/plain')取纯文本，避免污染 -
keydown拦截回车时注意：仅event.key === 'Enter'不够，需同时判断event.ctrlKey（Ctrl+Enter 换行）或event.shiftKey（Shift+Enter 插入<br>）
光标定位不能只靠 focus()，得用 Range + Selection
调用 el.focus() 后，光标位置完全不可控——尤其当元素初始为空、含空 <p></p> 或有嵌套标签时。必须手动构造 Range：
anything-to-html
下载
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
立即学习“前端免费学习笔记（深入）”；
- 想让光标落在末尾：
range.selectNodeContents(el); range.collapse(false) - 想让光标落在开头：
range.selectNodeContents(el); range.collapse(true) - 若元素内容为纯文本，优先用
range.selectNode(el.firstChild)，避免选中空白节点 - SSR 渲染页面首次聚焦失败？包一层
requestAnimationFrame(() => { /* range logic */ })
移动端和 React/Vue 中的隐藏陷阱
移动端 Safari 对 contenteditable 的支持最脆弱；框架中则容易因虚拟 DOM 更新导致焦点丢失或样式重置：
- 必须加
role="textbox"和aria-label，否则 VoiceOver 读不出编辑态 - React 中不要用
dangerouslySetInnerHTML初始化内容，会导致首次focus()失败；改用useEffect+ref手动设置innerHTML后再聚焦 - Vue 里
v-html同样破坏焦点链，建议用ref+nextTick延迟聚焦 - 禁用双击放大：CSS 加
-webkit-user-select: text; touch-action: manipulation;
真正难的不是让文字可编辑，而是让每次粘贴、每次回车、每次失焦都按你预期走——这些细节没处理好，用户就会觉得“这个编辑框总在自己乱动”。
