contenteditable="true"加了没反应，主因是元素无法聚焦：必须显式设tabindex="0"，并排除user-select:none、pointer-events:none等css拦截；还需配置white-space:pre-wrap、word-break:break-word及outline:none。
contenteditable="true"加了没反应？先看 tabindex 和 CSS
多数人写完 contenteditable="true" 发现点不动、Tab 进不去、快捷键（Ctrl+B）无效——根本不是属性没生效，而是元素没焦点。浏览器默认不给 <div> 或 <code><p></p> 聚焦能力。
必须显式加 tabindex="0"，让它进入键盘 Tab 链；同时检查是否被 user-select: none 或 pointer-events: none 拦住。CSS 上至少补三行：
-
outline: none（移除丑陋的默认蓝框） -
white-space: pre-wrap（保留换行和空格，避免折叠） -
word-break: break-word（防长文本溢出容器）
别用 tabindex="-1" 除非你只打算用 JS 主动调用 focus()；也别把 contenteditable 加在 <input> 或 <textarea></textarea> 上——浏览器直接忽略。
监听内容变化不能只靠 input 事件
input 事件对键盘输入响应快，但对粘贴、撤销（Ctrl+Z）、中文输入法上屏、拖拽插入等完全漏触发。真实编辑场景里，input 只能当“补充”，不能当唯一信源。
稳妥组合是：
-
input：捕获常规按键输入 -
compositionend：中文拼音上屏后必发，否则“你好”可能只存到“你” -
blur：兜底，防止用户切走页面未保存 -
MutationObserver：监听childList和characterData，尤其当你允许插图、链接或格式化时——DOM 结构变了但input不会响
别在 input 回调里直接读 innerHTML；用户粘贴恶意 HTML 会执行脚本。优先用 textContent，或白名单清洗后再存。
粘贴 Word / 网页内容怎么不崩样式、不进 XSS？
用户 Ctrl+V 粘贴，90% 带冗余 <font></font>、内联 style、嵌套 <span></span>，甚至 <script></script>。靠后端清洗已晚——前端显示早乱了，体验已毁。
必须拦截 paste 事件：
- 调
event.preventDefault() - 取
event.clipboardData.getData('text/plain')走纯文本路径最稳（适合大多数场景） - 若需保留粗体/列表，用
DOMParser解析'text/html'，递归遍历只留<p></p>、<strong></strong>、<ul></ul>/<ol></ol>/<li>，删掉所有style属性和未知标签 - 禁用
document.execCommand('insertHTML', ...)——它不校验，直接注入；改用document.execCommand('insertText', false, text)（虽废弃但目前兼容性最好）
光标定位和回车行为为什么总失控？
回车在 Chrome 插 <div>，Firefox 插 <code><p></p>，Safari 插 <br>；光标在 React/Vue 更新 DOM 后常消失，或卡在空 <p></p> 里无法删除——这不是 bug，是浏览器没义务替你管这些。
关键控制点：
- 拦截
keydown中的Enter，调e.preventDefault()，再按需插入\n或新节点（比如列表中新增<li>） - 手动管理光标：用
Range+Selection，focus()后不能只靠它；初始化空内容时，先塞一个<br>或占位文本，避免 Safari 吞焦点 - SSR 页面首次
focus()常失败，包一层requestAnimationFrame或setTimeout(..., 0)
移动端 Safari 的光标唤起和定位仍是深坑，加 role="textbox" 能提升可访问性兼容，但无法根治。真正复杂交互（如多段落格式切换），contenteditable 就不是“开个开关”能搞定的事了——它只是入口，不是编辑器。
