必须用 input 事件而非 keyup 或 change，因其能捕获粘贴、拖入、语音输入、输入法上屏等所有变更，且在 ie9+ 和现代浏览器中行为一致；keyup 漏掉非键盘操作，change 延迟反馈。
input 事件是唯一能覆盖所有输入路径的监听方式，value.length 是最直接可靠的字符计数依据。别绕弯，也别用 keyup 或 change。
为什么必须用 input 事件而不是 keyup
用户右键粘贴、Ctrl+V、从 Word 拖进一段文字、用 iOS 语音输入——这些操作 keyup 完全捕获不到；change 要等失焦才触发，用户写完看不到反馈，提交前才发现超限。只有 input 在值真正变更后立即触发，且在 IE9+ 和所有现代浏览器中行为一致。
常见错误现象：textarea 粘贴后字数卡住不动；中文输入法选词上屏瞬间跳变甚至超限；移动端软键盘回车后没更新——全是监听错事件导致的。
-
input覆盖键盘输入、粘贴、拖入、撤销（Ctrl+Z）、自动填充、输入法上屏 -
keydown/keypress会破坏中文输入法体验，导致丢字或卡顿 -
propertychange是 IE 专有旧事件，2026 年已无兼容必要
textarea 和 input[type="text"] 的统计逻辑一样吗
本质一样：都读 element.value.length。区别只在 DOM 结构和交互习惯：textarea 支持换行，\n 算 1 个字符；input[type="text"] 是单行，但长度计算方式完全相同。
- 不要用
innerText或textContent读取它们的值——对表单控件无效，会返回空或意外字符串 - 不需要
.trim()，也不必.replace(/\s/g, '')，除非业务明确要求“仅统计非空白字符” -
emoji和中文标点都按 1 个字符计，value.length已反映真实显示长度（注意：代理对如 "??" 在部分老环境可能被算作 2，但 2026 年主流浏览器已普遍支持Array.from(text).length补齐）
怎么防中文输入法导致的统计滞后
搜狗、百度、iOS 原生键盘在拼音阶段不更新 value，input 事件也不触发，直到用户确认上屏。这时 UI 显示的“还剩 5 字”可能是假象，提交时实际超限。
- 监听
compositionstart：暂停统计更新，避免显示错误中间态 - 监听
compositionend：立刻重新计算并更新显示 - 把
maxlength设得略宽松（比如标称 100 字，设maxlength="102"），给输入法留缓冲空间 - 服务端必须二次校验——前端提示只是友好辅助，不是防线
更新显示时容易踩的坑
每次 input 都调 document.getElementById('counter')？DOM 查询太勤会卡顿，尤其长文编辑场景。
- 把计数器元素缓存为常量：
const counterEl = document.getElementById('char-count'); - 更新只改
textContent，别碰innerHTML（无必要且有 XSS 风险） - 别在回调里同时操作光标位置（如
setSelectionRange）和更新计数——DOM 重排可能错位，分开做更稳 - 如果页面用了自动伸缩
textarea高度，字数统计逻辑必须和高度计算解耦，否则互相干扰
真正容易被忽略的不是事件选错或长度算错，而是中文输入法组合状态和 DOM 更新时机的耦合——compositionstart 到 compositionend 之间的 input 事件，内容是临时的，不该计入最终字数，但也不该阻断后续正常计数。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
