实时字数统计必须用 input 事件，因其覆盖粘贴、输入法、语音等所有路径，且只在值真正改变后触发；value.length 可用于轻量提示，需视觉精准则用 Array.from().length。
实时字数统计不是 HTML 能自动完成的事，必须靠 JavaScript 主动监听并更新——input 事件是唯一覆盖所有输入路径的可靠入口，其他方案都会漏行为或误触发。
为什么只用 input 事件，不用 keyup 或 change
用户粘贴、拖入文本、用输入法选词、语音输入、自动填充……这些操作 keyup 全部捕获不到；change 只在失焦时触发，完全不是“实时”。而 input 在所有主流浏览器（包括 IE11）中对 和 都稳定支持，且只在值真正改变后才触发——比如中文输入法确认上屏才计数，不会把拼音过程误算进去。
-
keyup会高频重复触发（长按字母键），且在中文输入法下提前触发，导致计数跳变或超限误判 -
change根本不适用于实时场景，用户写完看不到反馈，提交前才发现超限 - 移动端 iOS Safari 对
input事件偶有轻微延迟，可加setTimeout(..., 50)防闪动，但别超过 100ms
value.length 是不是真实字符数？要不要处理 emoji 和代理对
value.length 返回的是 UTF-16 码元个数，对 ASCII、常用汉字、换行符 \n 都是 1，但部分 emoji（如 ?）占 2 个码元，显示为 1 个字。如果业务要求“用户感知字数”（即视觉上几个字），得用 Array.from(text).length；如果只是做前端友好提示+服务端校验兜底，value.length 更快更轻量，也足够用。
- 纯文本输入框：直接用
el.value.length，别绕弯走textContent或正则清洗 - 需匹配用户直觉（如微博显示“还剩 100 字”）：用
Array.from(el.value).length - 后端若按字节（如 MySQL
utf8mb4）校验，JS 无法精确模拟，前端只做提示，以服务端为准
怎么避免卡顿、光标错位和样式抖动
高频 input 触发下，DOM 操作是主要瓶颈。每次输入都调用 innerHTML 或频繁改样式，容易引发强制同步布局；手动截断却不重置光标，会导致用户继续输入时“跳字”或光标回到开头。
- 用
textContent更新计数器，比innerHTML轻量得多，无解析开销 - 需超限时视觉提示（如变红），用 CSS class 切换，别 inline 写
style - 必须截断时，用
setSelectionRange()手动恢复光标到截断后末尾 - 避免在事件回调里做复杂计算（如去 HTML 标签、分词）——那是提交校验该干的
中文输入法下怎么防漏算和跳变
中文输入法组合过程中，input 不触发，用户打完拼音点选词上屏瞬间才触发，UI 提示可能滞后甚至直接超限。这不是 bug，是浏览器对 IME 的标准行为。
- 监听
compositionstart临时冻结计数更新（比如加isComposing = true） - 监听
compositionend后立刻重算并更新 UI - 别用
keydown或keypress拦截，它们无法阻止粘贴和拖放，移动端基本失效 - 真实部署时建议留 1–2 字余量（如标称 100 字，设
maxlength="102"），再用 JS 提示“最多 100 字”
最常被忽略的点是：把 maxlength 当成字数统计依据。它只是浏览器原生截断机制，计数逻辑和人眼看到的“字数”不一致，且对输入法组合过程无效。你必须独立实现统计逻辑，并始终以 input 为唯一可信触发源。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
