contenteditable="true"无法聚焦或输入的主因是浏览器拒绝交出焦点，三大堵点为：tabindex缺失、CSS拦截（如user-select:none）、父容器contenteditable="false"导致继承中断；实操需显式设tabindex="0"并配focus样式，监听用input事件为主、paste事件为辅，读取优先textContent，写回须用Range+Selection API保光标。
contenteditable 属性本身不能直接构建出可用的可编辑区域——加了 contenteditable="true" 却点不动、没光标、回车乱套，是常态，不是例外。
为什么设置了 contenteditable="true" 却无法聚焦或输入
根本卡点不在属性写没写对，而在浏览器拒绝交出焦点。三个高频堵点：
-
tabindex缺失：<div>、<code><p></p>等非表单元素默认不可聚焦，必须显式加tabindex="0"（别用-1，那会禁用键盘聚焦） - CSS 拦截：
user-select: none、pointer-events: none或outline: none未配自定义焦点样式，会让点击失效或无视觉反馈 - 继承链中断：父容器设了
contenteditable="false"，子元素即使写true也无效（“就近 false 优先”规则） - 必须监听
input，但别只靠它：它对纯文本输入、删除、回车换行有效，但对 execCommand 格式操作无响应 - 粘贴需单独处理：
paste事件必须preventDefault()，再手动取event.clipboardData.getData('text/plain')或用DOMPurify.sanitize()过滤 HTML - 移动端注意：iOS Safari 的
input在软键盘收起前可能漏发，建议加beforeinput作补充（兼容性有限，仅 Chrome/Firefox 较稳） - 纯文本场景：无条件用
textContent，它无视所有标签，只返回用户可见字符 - 需保留基础格式：先正则清洗
innerHTML，例如html.replace(/]*>/gi, '')，白名单控制可留标签 - 空内容陷阱：初始为空时，部分浏览器会自动插入
<div><br></div>，读textContent得空字符串，但innerHTML非空，需统一初始化为<div><br></div>再处理 - 必须显式调用
newEl.setAttribute('contenteditable', 'true')，别用newEl.contentEditable = 'true'（大小写敏感，旧环境可能不认） - 必须补
tabindex="0"，否则focus()无效 - 如果父容器是
contenteditable="plaintext-only"，子元素设true也会被降级，这个限制无法绕过 - 首次
focus()后光标常卡在开头或消失：得手动创建Range，range.selectNodeContents(newEl)再range.collapse(false)移到末尾
实操建议：初始结构至少带 tabindex="0" 和基础 focus 样式，例如：<div contenteditable="true" tabindex="0" style="outline: 2px solid #007bff;">编辑我</div>
如何监听真实内容变更而非“假 blur”
blur 事件太滞后，用户切走再回来可能已改多处；input 事件才是实时捕获的关键，但它不触发于格式操作（如加粗、粘贴富文本），且不同浏览器对“什么算 input”认定不一。
示例监听逻辑：el.addEventListener('input', () => console.log(el.textContent)); —— 优先用 textContent 避免 HTML 噪声，除非业务明确需要保留 <strong></strong> 等语义标签。
将 Markdown 文章转换为微信公众号兼容的纯 HTML 格式。当用户要求"转成微信格式"、"生成公众号文章 HTML"、"排版到微信草稿箱"、"微信粘贴格式"时触发。输出带内联样式的纯 HTML，微信编辑器可直接渲染，无需额外适配。支持标题、段落、列表、粗体、行内代码、表格、引用块、代码块、配图的完整转换。
如何避免 innerHTML 返回一堆浏览器私货
直接读 innerHTML 几乎总是错的：Chrome 回车插 <div>，Firefox 插 <code><p></p>，Safari 可能塞空 <p></p>；粘贴 Word 更会带 style、data-*、嵌套 <span></span>。这不是 bug，是规范允许的实现差异。
真正难的不是“怎么读”，而是“读完之后，怎么把清理后的结构安全地写回去而不破坏光标位置”——这必须用 Range + Selection API 手动恢复，innerHTML = xxx 会直接丢光标。
动态添加的可编辑元素为什么点不了
用 document.createElement('li') 创建的新节点，不会继承父容器的 contenteditable 状态，也不会自动获得 tabindex，首次点击必然失败。
最易被忽略的是 shadow DOM 场景：contenteditable 在 shadow root 内完全失效，连 execCommand 都调不了——这不是兼容性问题，是规范明确定义的行为。
