应使用 input 事件实时监听 textarea 输入，因其能捕获键盘输入、粘贴、拖拽、自动填充等所有修改场景，而 keyup 漏粘贴、change 需失焦，均不满足实时性要求。
textarea 实时监听输入事件用哪个？
用 input 事件，不是 keyup 或 change。前者能捕获所有输入方式（包括粘贴、拖入、自动填充、剪切板操作），后者会漏掉很多场景。比如用户右键粘贴或用 Ctrl+V 粘贴大段文字，keyup 根本不触发；而 change 只在失焦后才触发，完全不符合“实时”要求。
-
input 是唯一可靠选择，现代浏览器全支持（IE9+）
- 不要给
textarea 绑定 onpaste 单独处理——它已被 input 覆盖
- 如果用了 Vue/React 等框架，确保绑定的是原生
input 事件，而非框架封装的模糊事件
怎么算“字数”？中文、英文、空格、换行都怎么计？
字数定义必须和业务一致，没有标准答案。常见三种策略：
- 按字符数（
value.length）：最简单，中英文、标点、空格、换行符各算 1，适合微博类限制（如“最多 200 字”）
- 按中文字符 + 英文单词数：需正则匹配，例如
value.replace(/[\u4e00-\u9fa5]/g, 'aa').split(/\s+/).filter(Boolean).length，但容易误判英文连字符、缩写等
- 按 UTF-16 码元数（即 JS 字符串真实长度）：就是
length，已覆盖 emoji（如 ? 占 2 个码元）、生僻汉字等，推荐直接用这个
input 是唯一可靠选择，现代浏览器全支持（IE9+）textarea 绑定 onpaste 单独处理——它已被 input 覆盖input 事件，而非框架封装的模糊事件- 按字符数（
value.length）：最简单，中英文、标点、空格、换行符各算 1，适合微博类限制（如“最多 200 字”） - 按中文字符 + 英文单词数：需正则匹配，例如
value.replace(/[\u4e00-\u9fa5]/g, 'aa').split(/\s+/).filter(Boolean).length，但容易误判英文连字符、缩写等 - 按 UTF-16 码元数（即 JS 字符串真实长度）：就是
length，已覆盖 emoji（如 ? 占 2 个码元）、生僻汉字等，推荐直接用这个
注意：value.trim().length 会忽略首尾空格，但用户可能有意留空行或缩进，除非明确要求“有效内容长度”，否则别擅自 trim。
性能问题：频繁触发会不会卡？
单纯更新一个数字 DOM 节点，每秒几十次 input 触发完全无压力。但以下情况会出问题：
- 在监听函数里做了复杂正则匹配或遍历长文本（比如每次重算“中文字符数”还带标点过滤）
- 把计数逻辑塞进 React 的
setState 或 Vue 的响应式赋值里，且没做防抖（尤其配合搜索建议时）
- 同时监听多个
textarea 且每个都执行 DOM 查询（如反复 document.getElementById）
setState 或 Vue 的响应式赋值里，且没做防抖（尤其配合搜索建议时）textarea 且每个都执行 DOM 查询（如反复 document.getElementById）建议：
- 直接用
textContent更新计数元素，避免重排重绘 - 缓存
textarea和计数span的 DOM 引用，不要每次查 - 超过 500 字后可加节流（
setTimeout延迟 100ms 更新），但多数场景没必要
兼容性坑：移动端 iOS Safari 的特殊行为
iOS Safari 对 textarea 的 input 事件有延迟，尤其在快速输入或使用拼音输入法时，可能滞后 1–2 个字符。这不是 bug，是输入法组合过程导致的。
- 不要用
selectionStart 或光标位置去“修正”字数，反而更不准
- 接受这个延迟，只要最终结果正确即可（用户提交前总会停顿，此时数值已同步）
- 别尝试用
compositionstart/compositionend 拦截输入法——它们只对中文输入法有效，且无法覆盖语音、手写等输入方式
selectionStart 或光标位置去“修正”字数，反而更不准compositionstart/compositionend 拦截输入法——它们只对中文输入法有效，且无法覆盖语音、手写等输入方式字数统计本身很简单，真正麻烦的是定义清楚“什么算一个字”，以及接受不同平台输入链路带来的天然延迟。
