input事件是唯一覆盖所有输入路径的监听方式，value.length是最直接可靠的字符计数依据；keyup无法捕获粘贴、拖入、输入法上屏等操作，change需失焦才触发，无法实时反馈。
input 事件是唯一能覆盖粘贴、拖入、输入法上屏、语音输入等所有路径的监听方式，value.length 是最直接可靠的字符计数依据，别绕弯。
为什么不能用 keyup 或 change
用户右键粘贴、Ctrl+V、从 Word 拖进一段文字、用 iOS 语音输入——这些操作 keyup 完全捕获不到；change 要等失焦才触发，用户写完看不到反馈，提交前才发现超限。只有 input 在值真正变更后立即触发，且在 IE9+ 和所有现代浏览器中行为一致。
常见错误现象：textarea 粘贴后字数卡住不动；中文输入法选词上屏瞬间跳变甚至超限；移动端软键盘回车后没更新——全是监听错事件导致的。
textarea 和 input 的统计逻辑一样吗
本质一样：都读 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高度，字数统计逻辑必须和高度计算解耦，否则互相干扰
最易被忽略的是：用户禁用 JS 后，maxlength 仍生效，但提示消失。所以 HTML 里得预留默认文案（如 <span id="char-count">0/100</span>），而不是靠 JS 插入整个节点。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
