Array.from(text).length 是最轻量且准确的字符数统计方案，它按 Unicode 码点计数，兼容 emoji 和生僻字；需配合 input + compositionend 事件监听，避免 innerText、keyup 和错误截断逻辑。
直接用 input 事件监听 textarea 或 input 元素，配合 Array.from(text).length 计算字符数，就能做出靠谱的在线字数统计工具——不需要框架、不依赖后端，但必须避开 innerText、keyup 和错误的截断逻辑这三类高频翻车点。
为什么不能用 value.length 直接当“字数”
value.length 返回的是 UTF-16 码元个数，不是用户感知的“字符数”。一个 emoji（如 "??"）在 JS 中占 4 个码元，value.length 就返回 4；但用户只看到 1 个图符。中文生僻字（如 U+30000 以上）同理。日常场景下，Array.from(text).length 是最轻量且准确的替代方案，它按 Unicode 码点（grapheme cluster）计数，和大多数编辑器、输入法显示一致。
- 不要用正则
/./g匹配，它对 emoji 和组合字符支持差 - 避免
textContent.length—— 对input或textarea无效，会返回undefined - 如果业务真要区分“汉字=2 字、英文=1 字”，得单独写逻辑：
/[\u4e00-\u9fa5]/.test(c) ? 2 : 1，别指望.length变通
input 事件漏统计粘贴内容？加 compositionend 防抖就行
Safari 和部分 iOS 输入法在粘贴或拼音上屏时，input 事件可能延迟触发或被吞掉。双绑 compositionend 是成本最低的兜底方案——它在输入法确认上屏后立即触发，且不会重复调用（compositionstart 不必监听，除非你要做输入中提示）。
- 代码只需两行：
el.addEventListener('input', update)+el.addEventListener('compositionend', update) - 不用
setTimeout防抖：字数统计是纯内存操作，加延迟反而让用户觉得反馈卡顿 - 别监听
paste：它只管粘贴动作，不保证文本已写入value，容易取到旧值
contenteditable 区域怎么取真实字数
不能直接用 textContent 或 innerText 后接 .length。前者会把多个空格、换行、
<br>全部保留，后者受 CSS 影响（比如
display: none 的节点被忽略），且在 iOS Safari 行为不一致。
立即学习“前端免费学习笔记（深入）”；
- 正确做法：遍历 DOM 节点，对
br、p、div[style*="display: block"]插入\n，对文本节点取nodeValue，最后合并字符串再走Array.from()统计 - 跳过
script、style、注释节点，否则可能把 HTML 注释内容也算进去 - 别用
innerHTML.replace(/]*>/g, '')清洗：正则无法处理嵌套标签、自闭合标签或注释，还可能误删实体编码（如&）
超限时怎么截断才不丢光标
用户在第 30 字位置粘贴一段 200 字文本，你直接 el.value = el.value.slice(0, MAX)，光标会跳到末尾——他继续打字就覆盖不到原位置。必须手动保存并重置光标。
- 核心三步：
const pos = el.selectionStart→el.value = el.value.slice(0, MAX)→el.setSelectionRange(pos, pos) - iOS Safari 对
setSelectionRange支持不稳定，可降级：超限时只高亮提示，不主动截断（用el.style.borderColor = 'red'+ 提示文案） - 禁止用
preventDefault()拦截input：它在大多数浏览器里无效，尤其对 iOS 输入法和粘贴操作
最易被忽略的是：富文本粘贴（比如从 Word 复制）会带大量不可见格式字符（\u200b、\ufeff、冗余 ），它们也计入 Array.from() 结果。如果业务要求“只算可见文字”，就得在统计前先清洗——但这已是语义层需求，和基础字数统计不在同一抽象层级。
