contenteditable="true"需配合tabindex和CSS属性生效，支持true/false/plaintext-only三值，继承遵循“就近false优先”，编辑内容推荐用input事件监听并清理innerHTML。
contenteditable 属性怎么设才生效
直接在元素上加 实操建议： 立即学习“前端免费学习笔记（深入）”； 编辑完不能只靠 实操建议： 立即学习“前端免费学习笔记（深入）”； 不同浏览器对 实操建议： 立即学习“前端免费学习笔记（深入）”； iOS Safari 在 实操建议： 立即学习“前端免费学习笔记（深入）”；contenteditable="true" 就能开启编辑，但很多人试了没反应——常见原因是目标元素默认不可聚焦（比如 tabindex），或者被 CSS 的 pointer-events: none 或 user-select: none 拦住了。
contenteditable 接受三个值："true"、"false"、"plaintext-only"（后者会禁用富文本格式，粘贴时自动转纯文本）contenteditable="true"，别用布尔简写（contenteditable 不加值在部分浏览器行为不一致）contenteditable="false"，子元素即使设为 true 也不会可编辑（继承规则是“就近 false 优先”）如何获取和保存编辑后的内容
innerHTML 读取——它会把换行转成 textContent（纯文本）或预处理后的 innerHTML。
input 事件比 blur 更及时，适合实时保存：document.getElementById('editor').addEventListener('input', () => {
const html = document.getElementById('editor').innerHTML;
// 清理多余标签再存
});html.replace(/
（视需求决定是否保留基础标签）data-* 属性或内联样式，这些不是用户输入内容，要按业务逻辑决定是否保留
为什么回车/粘贴行为不一致？
contenteditable 的默认回车行为不同：Chrome 插入 。粘贴时还会带来源样式，导致结构混乱。
keydown 中的 Enter 键：element.addEventListener('keydown', (e) => {
if (e.key === 'Enter' && !e.shiftKey) {
e.preventDefault();
document.execCommand('insertHTML', false, '
');
}
});paste 事件，用 e.clipboardData.getData('text/plain') 获取纯文本再插入document.execCommand 做复杂格式操作——它已被废弃，Chrome 98+ 对部分命令返回 false，建议用 Selection + Range API 替代移动端光标错位和键盘兼容问题
contenteditable 区域点击时常出现光标偏移、键盘闪退或无法唤起；Android 部分 WebView 则可能不触发 input 事件。
有些细节只有真正在 iOS 微信内置浏览器里连续改三次 tabindex="0"，确保可聚焦；必要时在 touchstart 中主动调用 element.focus()
contenteditable 元素设 min-height 或 height: auto，改用 padding 和固定 min-height 组合input 事件失效，可用 setTimeout + textContent 轮询检测变化（间隔 300ms 足够）contenteditable 的 user-modify 样式才会暴露出来。
