直接在<div>上设contenteditable="true"并加tabindex="0"、role="textbox"、aria-multiline="true"才生效；需排除pointer-events:none、user-select:none、display:none等干扰，且移动端需真实点击触发软键盘。
contentEditable 属性怎么设才生效
直接在 <div> 上加 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 不认，会导致兼容性断裂 - 设完必须确保元素可聚焦：默认
<div>不在 tab 顺序中，加tabindex="0"才能用键盘 Tab 进入
为什么点击没光标？focus() 不起作用怎么办
常见现象是 JS 调了 element.focus() 却没反应。根本原因是该元素尚未“可聚焦”或处于隐藏/禁用状态。
- 检查是否被
display: none、visibility: hidden或opacity: 0遮挡——这些都会让focus()静默失败 - 确保 DOM 已挂载：在
DOMContentLoaded后操作，或用requestAnimationFrame延迟一次再 focus - 移动端需额外触发：iOS Safari 要求用户真实点击才能激活编辑，纯 JS
focus()无法唤出软键盘，得配合input或textarea中转
contentEditable 和 input/textarea 的核心区别
别把 contenteditable 当成“高级 textarea”。它本质是富文本编辑入口，行为差异极大：
- 输入内容会生成 HTML 片段（如换行变
<div>或<br>），不是纯文本；取值要用innerHTML，textContent会丢失格式 - 不触发表单提交（
<form>内也不会自动提交），也没有value属性，得手动同步到隐藏<input>或 JS 变量 - 剪贴板行为不可控：粘贴 HTML 会直接插入标签，可能破坏结构；想过滤就得监听
paste事件并event.preventDefault()后手动解析 - 无障碍支持弱：屏幕阅读器对
contenteditable的支持参差不齐，role="textbox"+aria-multiline="true"是必要补充
<div contenteditable="true" tabindex="0" role="textbox" aria-multiline="true" aria-label="编辑正文"> 这里可以输入文字 </div>
实际项目里最常漏掉的三件事
上线后才发现编辑区点不动、粘贴乱码、回车崩样式？大概率栽在这几个点上：
立即学习“前端免费学习笔记（深入）”；
- 没重置默认样式：浏览器会给
contenteditable元素加outline和user-modify行为，建议显式写div[contenteditable] { outline: none; -webkit-user-modify: read-write; } - 没处理空内容：空
<div contenteditable></div>在 Firefox 中无法获得焦点，至少放一个<br>或 - 没防 XSS：如果把
innerHTML直接存库再渲染，用户粘贴的<script>会执行。服务端必须剥离危险标签，前端也要用DOMPurify.sanitize()过滤
contenteditable，转向 execCommand 封装或专业编辑器 SDK。 
