必须用 input 事件实现字数统计，因其覆盖粘贴、拖拽、语音、输入法上屏等所有输入路径；需避开中文输入法组合状态误判和频繁 DOM 操作导致的卡顿，通过缓存元素、避免强制布局、精准截断并保持光标位置来优化体验。
直接用 input 事件监听 textarea 或 input[type="text"] 的 value.length 就能做出可用的字数统计，不需要框架、不依赖第三方库，但必须避开中文输入法组合状态和 DOM 频繁操作这两个坑。
为什么必须用 input 事件，而不是 keyup 或 change
input 是唯一能覆盖所有真实输入路径的事件：粘贴（Ctrl+V / 右键）、拖拽文本、语音输入、自动填充、输入法上屏。而：
-
keyup在用户右键粘贴、用 iOS 软键盘长按粘贴时完全不触发；中文输入法下，拼音未确认时就发keyup，value还是空，导致计数卡住或跳变 -
change只在失焦后触发，用户打完 50 字却看不到任何反馈，根本不是“实时” - 移动端 Safari 和 Android Chrome 对
input支持良好，IE9+ 也兼容，无需降级
textarea 和 contenteditable 的字数提取逻辑完全不同
对 textarea，直接用 el.value.length —— 它返回的就是用户看到的字符总数，包括空格、换行符（\n 算 1 个）、中英文标点，全部按 1 字计，符合绝大多数场景需求。
但 contenteditable 是 HTML 容器，value 属性不存在，不能用 innerText（受 CSS display: none 干扰，且会把连续换行压成空格），也不能直接用 textContent（会带入不可见的 \u200b、
<br>对应的换行符，导致多算）。
立即学习“前端免费学习笔记（深入）”；
稳妥做法是：
- 遍历子节点，跳过
script、style - 遇到
br、p、div（display: block）插入一个\n - 对文本节点取
nodeValue，不做 HTML 解析 - 最后合并字符串，再走
Array.from(text).length计数（防 emoji 代理对）
中文输入法下怎么避免“拼音阶段误统计”
用户敲 “woai” 还没按空格，DOM 中 value 仍是旧值；一按空格，input 触发，value 突然变成 “我爱”。这不是 bug，是输入法正常行为。强行监听 compositionstart / compositionend 很容易引入耦合和状态混乱。
更轻量的解法是：不阻止、不预测，只确保 UI 更新不“抢跑”——
- 不依赖
keydown或keypress做预判 - 允许
input正常触发，但更新统计前加一层简单判断：if (el.value !== lastValue) { updateCount(); lastValue = el.value; } - 如果业务要求严格对齐“微信式字数”，用
Array.from(el.value).length替代.length，但注意 IE 不支持
性能和 DOM 操作最容易被忽略的细节
字数统计本身几乎不耗性能，value.length 是 O(1) 操作。真正卡顿的来源是 DOM 更新方式：
- 每次
input都调用document.getElementById('counter')—— 缓存它，别反复查 - 在回调里读
offsetHeight或写style.color—— 这会强制同步布局计算，尤其在低端安卓机上明显掉帧 - 超限时直接
el.value = el.value.slice(0, max)—— 光标会跳到末尾，用户继续输入就断在尾巴上；必须配合setSelectionRange(pos, pos)锁定原位置 - 不要给统计显示加
setTimeout或requestAnimationFrame节流 —— 用户会感知延迟，“打完字等半秒才看到数字变”就是失败体验
最常被绕开的问题，其实是“字数”的定义权不在 JS，而在产品需求：是服务端存储长度？微信消息计费规则？还是用户直觉里的“写了几个字”？一旦混用 value.length、trim().length、split(' ').length，统计结果就会和后端校验对不上，而这个偏差往往到上线后才暴露。
