contenteditable="true"无法聚焦是因缺少tabindex="0"、CSS禁用交互或父级contenteditable="false"；输入监听应优先用input事件，配合paste和beforeinput；获取纯文本用textContent，保留格式需清洗innerHTML并防XSS；光标定位需Range+Selection控制。
加了 contenteditable="true" 却点不动、没光标、回车乱套——不是你写错了，是浏览器根本没打算交出焦点。
为什么设置了 contenteditable="true" 却无法聚焦或输入
浏览器对可编辑区域的聚焦有硬性前提，缺一不可：
-
tabindex="0"必须显式设置；<div>、<p>等非表单元素默认不可聚焦，tabindex="-1"会禁用键盘聚焦，别用 - CSS 拦截常见但易忽略：
user-select: none、pointer-events: none或未配outline样式，会让点击失效或无反馈 - 继承链中断：父容器写了
contenteditable="false"，子元素即使写"true"也无效（“就近 false 优先”）
最小可用结构示例：<div contenteditable="true" tabindex="0" style="outline: 2px solid #007bff;">编辑我</div>
监听内容变更该用 input 还是 blur
blur 太滞后，用户切走再回来可能已改多处；input 是实时捕获的关键，但它不覆盖所有场景：
立即学习“前端免费学习笔记（深入）”；
anything-to-html
下载
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
-
input对纯文本输入、删除、回车换行有效，但对execCommand格式操作（如加粗、对齐）无响应 - 粘贴必须单独监听
paste事件，并event.preventDefault()后手动处理：用event.clipboardData.getData('text/plain')取纯文本，或用DOMPurify.sanitize()过滤 HTML - 移动端注意：iOS Safari 的
input在软键盘收起前可能漏发，可加beforeinput补充（仅 Chrome/Firefox 支持较稳）
推荐基础监听：el.addEventListener('input', () => console.log(el.textContent)); —— 优先用 textContent，避免 HTML 噪声
innerHTML 返回一堆 div/p/空标签怎么办
这不是 bug，是浏览器实现差异：Chrome 回车插 <div>，Firefox 插 <p>，Safari 可能塞空 <p></p>，粘贴 Word 更会带 style 和 data-* 属性。
- 纯文本场景：无条件用
textContent，它无视所有标签，只返回用户可见字符 - 需保留基础格式：先清洗
innerHTML，例如html.replace(/<div>/gi, '\n').replace(/<[^>]+>/g, '')（按需调整正则） - 提交前务必过滤 XSS 风险节点，比如
<img onerror="alert(1)">，不能只靠正则，业务侧需做语义校验
focus() 后光标没出现在预期位置
调用 el.focus() 只是让元素获得焦点，光标位置由浏览器自动决定，常卡在开头、末尾不一致，或因嵌套空标签（如 <p></p>）直接消失。
- 想光标落到末尾：先
selectNodeContents(el)，再collapse(false) - 清空后聚焦并光标置末：先
el.innerHTML = ''，再用Range+Selection显式控制 - 移动端 iOS Safari 对
Range支持不稳定，需 fallback 到setTimeout(() => el.focus(), 0)再重试
真正难的从来不是加属性，而是处理浏览器之间对“编辑”的不同理解——尤其是回车、粘贴、光标定位这三件事，每个都得单独兜底。
