直接在上设contenteditable="true"并加tabindex="0"、role="textbox"、aria-multiline="true"才生效；需排除pointer-events:none、user-select:none、display:none等干扰，且移动端需真实点击触发软键盘。
contentEditable 属性怎么设才生效
直接在 常见现象是 JS 调了 别把 上线后才发现编辑区点不动、粘贴乱码、回车崩样式？大概率栽在这几个点上： 立即学习“前端免费学习笔记（深入）”；contenteditable="true" 就能编辑，但很多人设了没反应——通常是因为父容器有 pointer-events: none、CSS 禁用了用户选择（user-select: none），或 JS 里调用了 event.preventDefault() 拦截了焦点事件。
contenteditable 是布尔属性，写成 contenteditable、contenteditable="" 或 contenteditable="true" 都行；"false" 和空字符串以外的值（如 "inherit"）会被当作 true
contenteditable="plaintext-only" —— 这不是标准值，Chrome 虽支持但 Firefox 不认，会导致兼容性断裂tabindex="0" 才能用键盘 Tab 进入
为什么点击没光标？focus() 不起作用怎么办
element.focus() 却没反应。根本原因是该元素尚未“可聚焦”或处于隐藏/禁用状态。
display: none、visibility: hidden 或 opacity: 0 遮挡——这些都会让 focus() 静默失败DOMContentLoaded 后操作，或用 requestAnimationFrame 延迟一次再 focusfocus() 无法唤出软键盘，得配合 input 或 textarea 中转contentEditable 和 input/textarea 的核心区别
contenteditable 当成“高级 textarea”。它本质是富文本编辑入口，行为差异极大：innerHTML，textContent 会丢失格式
内也不会自动提交），也没有 value 属性，得手动同步到隐藏 或 JS 变量paste 事件并 event.preventDefault() 后手动解析contenteditable 的支持参差不齐，role="textbox" + aria-multiline="true" 是必要补充实际项目里最常漏掉的三件事
真正难的不是设属性，而是控制它输出什么、接受什么、如何与表单流程对齐。尤其当需求写着“支持粗体/链接/图片”，就得立刻放弃原生 contenteditable 元素加 outline 和 user-modify 行为，建议显式写 div[contenteditable] { outline: none; -webkit-user-modify: read-write; }
在 Firefox 中无法获得焦点，至少放一个
innerHTML 直接存库再渲染，用户粘贴的 会执行。服务端必须剥离危险标签，前端也要用 DOMPurify.sanitize() 过滤contenteditable，转向 execCommand 封装或专业编辑器 SDK。
