contenteditable 的作用是让浏览器原生接管编辑行为，需显式写为 contenteditable="true"，不可简写；内容获取用 textContent 或 innerHTML；监听用 input 事件；光标需 Range 控制；粘贴须拦截过滤。
contenteditable 的作用不是“让元素看起来像输入框”，而是让浏览器原生接管该元素的编辑行为——光标、选区、输入、删除、粘贴、回车换行全部由渲染引擎处理，无需自己实现文本光标或 DOM 操作逻辑。
contenteditable="true" 必须写字符串，不能简写为 contenteditable
常见错误是写成 <div contenteditable> 或 <code><div contenteditable="">。这在 Chrome 中可能被当作 <code>"true"，但在 Firefox 或 Safari 中行为不一致，甚至被忽略。必须显式写成：
<div contenteditable="true">可编辑</div>
其他合法值只有 "false" 和实验性 "plaintext-only"（Safari 支持差，不建议依赖）。
-
contenteditable="false"会禁用编辑，但子元素仍可能继承父级状态；如需彻底禁用，建议同时加tabindex="-1"和style="user-select: none;" - 设为
"true"后，元素默认获得tabindex="0"，可通过 Tab 键聚焦——若不需要键盘导航，应手动设tabindex="-1" - 不适用于
<input>或<textarea></textarea>：它们已有语义化编辑逻辑，加contenteditable反而引发冲突
获取内容不能用 value，得选 textContent 还是 innerHTML
contenteditable 元素没有 value 属性，读取内容必须主动选择方式：
-
el.textContent：返回纯文本，无视所有标签和格式，适合保存摘要、搜索索引或做简单校验 -
el.innerHTML：返回实际渲染的 HTML 字符串，但可能含冗余标签（如<div><br></div>）、内联样式、甚至 XSS 风险节点（如<img onerror="alert(1)">） - 监听变更推荐用
input事件，而非blur：它在每次输入、粘贴、删除后立即触发，响应更及时
示例：
const el = document.getElementById('editor');<br>el.addEventListener('input', () => {<br> console.log('纯文本:', el.textContent);<br> console.log('HTML:', el.innerHTML); // 上线前务必过滤<br>});
focus() 不等于光标就位，光标位置得手动控制
调用 el.focus() 后，光标常卡在开头、末尾不一致，或因嵌套空标签（如 <p><br></p>）直接消失。必须用 Range + Selection 显式定位：
- 想光标落到末尾：先
selectNodeContents(el)，再collapse(false) - 想清空后聚焦并光标置末：先
el.innerHTML = ''，再创建Range插入空白文本节点，避免selectNodeContents选中不可见节点 - 移动端 Safari 对
Range支持不稳定，建议加role="textbox"提升可访问性兼容性
粘贴内容不可信，paste 事件必须拦截处理
用户 Ctrl+V 粘贴时，浏览器默认直接插入原始 HTML（含样式、脚本、iframe），极易引入 XSS 或破坏布局。不能依赖 "plaintext-only"，得监听 paste 事件：
- 调用
event.preventDefault()阻止默认行为 - 用
event.clipboardData.getData('text/plain')获取纯文本 - 通过
document.execCommand('insertText', false, text)插入（注意：该 API 已废弃，现代方案需用getSelection()+Range手动插入） - 若需保留部分格式（如粗体、链接），必须白名单过滤 HTML，推荐用
DOMPurify.sanitize()
真正难的不是开启编辑，而是让编辑结果可控、安全、跨端一致——光标、粘贴、空内容占位、焦点管理、样式重置，每个点都容易漏掉。
