HTML5富文本限制字数_HTML5ContentEditable输入长度截断与计数提示操作【攻略】

contenteditable 元素需监听 input 和 compositionend 事件，用 textcontent 统计可视字数并手动截断，配合 range 操作更新内容，粘贴时清洗 html 并二次校验，服务端必须兜底。

contenteditable 元素如何准确截断输入长度

直接用 maxLength 属性无效——contenteditable 是富文本容器，不认这个表单属性。真正起作用的是监听 input 事件 + 手动截断 textContent 或 innerText，但要注意 HTML 标签本身不计入“可视字数”，而用户粘贴带格式内容时，textContent 会漏掉换行、空格等渲染行为。

• 优先用 textContent 计数：它剥离所有标签，最接近用户“看到的字数”
• 截断后必须用 document.execCommand('insertText', false, truncatedText)（兼容旧版）或更稳妥的 range.deleteContents() + range.insertNode() 替换，直接赋值 innerHTML 可能破坏光标位置或丢失临时样式
• 移动端 safari 对 input 事件触发不敏感，需额外监听 compositionend 防止中文输入法超长

为什么 oninput + textContent.length 统计不准

因为 textContent 把连续空白（如多个空格、 、换行）压缩成单个空格，且完全忽略

<br>

标签——但用户实际编辑中按回车产生的

<br>

在视觉上占一行，应算作“1 个换行符长度”。更糟的是，某些编辑器（如 Draft.js 封装层）会在内部插入不可见的 ZWSP（零宽空格）用于光标定位，它们会被 textContent 吞掉，导致计数偏少。

• 需要区分场景：纯文字限制用 textContent.length；含换行/排版意图的，改用正则统计可见字符 + 显式

  <br>

  数量：

  (el.innerHTML.match(/<brs*/?>|[^<]+/g) || []).reduce((sum, s) => sum + (s === '<br>' || s === '<br/>') ? 1 : s.replace(/<[^>]*>/g, '').length, 0)

• 避免用 innerText：IE/edge 已废弃，且在隐藏元素上返回空字符串
• 服务端永远要二次校验：前端截断可被绕过，textContent 统计本身也不等于渲染后像素宽度

实时字数提示卡顿或不同步

高频 input 事件下反复读取 textContent + dom 操作，尤其在长文档里会明显掉帧。不是 JS 慢，是浏览器强制同步计算样式和布局——每次读取 textContent 都可能触发重排。

• 加节流：用 requestIdleCallback 或简单 setTimeout(..., 0) 延迟更新提示，避免阻塞输入
• 缓存上次长度：只在 textContent.length 真实变化时才更新 ui，避免重复渲染
• 不要在提示里显示“已用 120/200 字”，改用进度条或颜色渐变——DOM 更新次数减半，肉眼感知更顺滑

粘贴富文本时长度暴增的处理逻辑

用户从 word 或网页复制一段带样式的文字，innerHTML 可能瞬间膨胀 5–10 倍（一堆 span、style、注释），但 textContent 还是原来那些字——这时候按 innerHTML.length 截断会误杀大量合法内容，按 textContent.length 又无法阻止恶意构造的超长标签垃圾。

立即学习“前端免费学习笔记（深入）”；

• 粘贴时监听 paste 事件，用 Event.clipboardData.getData('text/html') 拿到原始 HTML，用 DOMParser 清洗再计数
• 清洗策略：只保留 p、br、strong、em，删掉所有 style、class、data- 属性，防止 xss 和体积膨胀
• 对清洗后的内容，仍以 textContent.length 为准截断，但允许额外 +20% 容量给必要标签（比如每段末尾的

  <br>

  ）

最麻烦的不是技术实现，是得同时应付 chrome 的 input 事件延迟、Safari 的粘贴解析 bug、还有用户一边打字一边疯狂 Ctrl+Z —— 所有长度判断必须在光标位置不变的前提下完成，否则体验直接崩掉。