contenteditable="true"不能直接使用，因其存在blur事件不可靠、光标默认在开头、粘贴富文本引发XSS、回车插入div而非br等硬伤；应改用dblclick动态插入input并做好焦点管理、XSS过滤与跨端兼容。
contenteditable 是最轻量、原生支持的方案，但直接设为 true 会带来焦点管理、XSS、样式错乱等实际问题，不能一设了之。
为什么不能直接写 contenteditable="true" 就完事
看似一行属性就能让 <p></p> 或 <div> 可编辑，但真实场景中会立刻暴露几个硬伤：<ul>
<li>
<code>blur 事件不可靠：用户点击空白处、切换标签页、按 Tab 键都可能触发，但你无法区分“是想保存”还是“只是临时切走”
innerHTML 直接存入 DOM，XSS 风险真实存在（比如粘贴含 <script></script> 的内容）<div contenteditable> 中按 Enter 会插入 <code><div>，而多数业务只要换行（<code><br>）
dblclick + 动态插入 <input> 的实操要点
用原生 <input> 替代 contenteditable，能彻底规避富文本干扰，也更容易控制行为。关键不是“能不能”，而是“怎么插得干净”：
- 必须先判断当前是否已处于编辑态：
if (el.querySelector('input, textarea')) return，否则双击多次会叠一堆输入框 - 替换内容时别用
innerHTML = '<input...>'</input...>，改用textContent提取原文本，再用appendChild()插入新元素，避免 HTML 被二次解析 - 聚焦后要手动选中文本：
input.select()或input.setSelectionRange(0, input.value.length)，否则用户还得拖选 -
blur回调里，建议对比修改前后值：if (input.value !== originalText) { /* save */ }，避免无意义请求
jQuery 里绑定 dblclick 容易漏掉的兼容细节
jQuery 的 .on('dblclick', handler) 在移动端根本不会触发 —— iOS/Android 没有双击概念，只会发 click 事件。所以：
生成可在 deepbi 沙箱 iframe 内运行或作为独立文件运行的交互式 HTML 页面，使用 `window.deepbi` JS SDK 实现数据查询、空间管理、文件浏览及用户操作。当用户提出以下需求时启用该能力： - 创建 KPI 仪表盘、数据表格、文件浏览器、成员列表、管理页面； - 明确要求“转成 dhtml”、“转译成 HTML”、“把 XX 页面转成……”、“控制台页面”、“管理后台”、“DeepBI 页面迁移”； - 提及位于 `apps/console/src/featur
立即学习“前端免费学习笔记（深入）”；
- 不要依赖
$(el).on('dblclick', ...)做跨端方案 - 如果必须支持触屏，改用「单击延时判定」：记录首次点击时间戳，200ms 内再点一次即视为双击
- 或者干脆放弃双击，改用长按（
touchstart+setTimeout）更符合移动直觉 - 桌面端也要注意：Chrome/Firefox 对
dblclick的触发时机略有差异，测试时务必用真实鼠标，别只靠模拟点击
保存前必须做的 XSS 过滤动作
无论用 contenteditable 还是 <input>，只要最终把用户输入塞进 innerHTML，就必须消毒：
- 别自己写正则过滤 HTML 标签 ——
string.replace(/]+>/g, '')会被绕过 - 用成熟库如
DOMPurify.sanitize(inputValue)，它专为 HTML 上下文设计 - 如果只是纯文本展示，优先用
textContent而非innerHTML，这是最彻底的防护 - 后端同样不能信任前端过滤，保存前仍需服务端校验
双击编辑看着简单，真正上线时卡住的几乎全是焦点逻辑和 XSS 边界处理 —— 光让文字变可编辑只是第一步，让用户改得安心、改得可控，才是落地的关键。
