contenteditable 元素的 input 事件在 safari 15.4+/monterey 12.3+ 才稳定支持，旧版 webkit 基本不触发或延迟；它仅可靠响应用户直接输入字符，不涵盖粘贴、拖放、格式化及快捷键操作；获取内容应优先用 innerhtml（带格式）或 textcontent（纯文本），禁用 value 和 innertext；onchange 对其无效，需用 mutationobserver 或组合 paste/keydown 等事件弥补。
contenteditable 元素触发 input 事件的兼容性问题
原生 contenteditable 元素在 Chrome/Firefox/Edge（Chromium 内核）中支持 input 事件，但 Safari 从 iOS 15.4 和 macOS Monterey 12.3 起才开始稳定支持——更早版本基本不触发或严重延迟。如果你监听了 input 却没反应，大概率是 Safari 或旧版 WebKit 的锅。
别指望靠 input 事件覆盖所有编辑场景：粘贴、拖放、格式化操作（如加粗、插入图片）、快捷键（Ctrl+Z/Y）在部分浏览器里不会触发它；input 只保证“用户直接输入字符”时可靠。
用 input 事件获取最新内容的正确写法
监听 input 事件本身没问题，但必须注意 DOM 更新时机：事件触发时，textContent 或 innerText 已同步更新，但 innerHTML 才反映真实结构（含标签、换行、空格等）。别用 value 属性——contenteditable 元素没有 value。
- 获取纯文本用
el.textContent（会合并空白、丢弃格式） - 获取带格式的 HTML 用
el.innerHTML（保留<br>、<span></span>等，但可能含不可见字符如） - 避免用
el.innerText：它受 CSS 影响，且在 Firefox 中对隐藏元素行为不一致 - 如果需要标准化换行，可对
innerHTML做一次简单清洗：html.replace(/<br>/gi, '\n').replace(/]+>/g, '')（仅作示意，勿直接用于生产）
为什么 onchange 不生效，以及替代方案
onchange 事件对 contenteditable 元素完全无效——它只适用于表单控件（<input>、<select></select> 等）。试图绑定 onchange 是白忙活。
当 input 事件不可靠时（比如要捕获粘贴或撤销），可组合监听：
-
input：覆盖键盘输入 -
paste：手动setTimeout(() => { /* 读取 innerHTML */ }, 0)，因为粘贴后 DOM 更新有微小延迟 -
keydown+keyup：检测 Ctrl+Z/Y，但无法区分是否真修改了内容 - 更健壮的做法是用
MutationObserver监听子节点变化，不过开销略大，适合对一致性要求极高的场景
容易被忽略的边界情况
用户连续快速输入时，input 事件会高频触发，但两次事件之间 DOM 已更新——不需要防抖也能拿到最新值。真正麻烦的是这些：
- 光标位于空行末尾时按 Enter：Chrome 插入
<div><br></div>，Firefox 插入<br>，Safari 可能插入<p><br></p>——innerHTML结构差异极大 - 全选后删除：某些浏览器会清空元素但留下空
<br>或零宽空格，textContent.length === 0但innerHTML !== '' - 移动端软键盘回车键可能触发
input，也可能先触发blur再触发，顺序不稳定
别依赖一次取值就认为内容“已确定”，尤其涉及保存逻辑时，最好加个 blur 事件兜底，并对比前后 innerHTML 是否真变了。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
