直接写死 contenteditable="true" 易导致光标错位、粘贴污染、回车异常、移动端失焦、seo 泄露及首次 focus 失败；应动态设置 contenteditable 和 tabindex，并用 input 事件监听+range/selection 精准控光标。
直接加 contenteditable="true" 能让元素可编辑，但多数情况下会出问题——光标错位、粘贴污染、回车异常、移动端失焦、SEO 泄露，甚至首次 focus 失败。
为什么 contenteditable="true" 写死在 HTML 里大概率翻车
浏览器对 contenteditable 的生效有隐式依赖：父级不能是 contenteditable="false"，不能被 user-select: none 或 pointer-events: none 锁定，也不能在 Shadow DOM 或 iframe designMode=on 环境下；更关键的是，写死属性会让空元素首次点击不聚焦、搜索引擎抓取到未审核的编辑态内容、权限切换时无法同步状态。
推荐做法是用 JS 动态设置：
- 激活编辑前：
el.contentEditable = "true"+el.tabIndex = "0" - 禁用时：
el.contentEditable = "false"+el.tabIndex = "-1"+el.style.userSelect = "none" - SSR 渲染后首次 focus，必须包裹在
requestAnimationFrame或setTimeout(..., 0)中
input 事件监听比 blur 更靠谱
contenteditable 元素没有 change 事件，也不响应 form.submit()。靠 blur 取值容易漏掉粘贴后立刻点保存、或快速切 Tab 导致未触发的情况。
真正稳定的做法是监听 input：
- 它在每次按键、删除、粘贴、拖拽插入后都触发
- 但注意：
el.textContent返回纯文本（安全），el.innerHTML返回带标签的 HTML（需白名单过滤） - 别用
el.value—— 这个属性根本不存在
示例：
el.addEventListener('input', () => {
console.log('当前纯文本：', el.textContent);
// 上线前务必过滤 innerHTML，防 XSS
console.log('原始 HTML：', el.innerHTML);
});
光标定位不能只靠 focus()
调用 el.focus() 后，光标常卡在开头、消失，或停在空 <p></p> 标签里——因为浏览器不会自动判断“该落在哪”。必须手动用 Range 和 Selection 控制。
常见需求及写法：
- 光标移到末尾：
range.selectNodeContents(el); range.collapse(false); selection.addRange(range); - 清空后聚焦并光标置末：先
el.innerHTML = ''，再创建空白文本节点插入并定位 - 移动端 Safari 不稳定，建议额外加
role="textbox"提升可访问性兼容
双击编辑场景，优先用 input 替换而非 contenteditable
如果只是改一两行纯文本（比如表格单元格、标题、标签名），contenteditable 是过度设计：回车插入 <div>、粘贴带样式 HTML、移动端双击触发系统放大，都是真实线上 bug。
<p>更可控的方案是双击时动态插入 <code><input>：
- 双击后
e.stopPropagation()阻止冒泡 -
input.select()确保文字全选，不用用户再点一次 - 按 Enter 或 blur 时对比新旧值，没变就还原，避免无意义 DOM 更新
- 移动端需加
style="user-select: text; touch-action: manipulation;"防止误触发
这个模式绕开了所有 contenteditable 的底层不确定性，尤其适合中后台列表编辑。
真正难的不是“怎么让它可编辑”，而是“怎么让它每次都表现一致”——DOM 结构差异、浏览器版本、移动端输入法、焦点管理时机，任何一个变量没控住，光标就失踪，粘贴就炸开，用户就投诉。别省那几行 JS。
