必须用 input 事件实现 HTML 字数实时统计，因其覆盖键盘、粘贴、输入法等所有变更路径；需配合 compositionstart/end 处理中文输入；value.length 返回 UTF-16 码元数，用户感知字数应使用 Array.from(str).length。
HTML字数统计本身没有强制要求“实时”，但几乎所有实际业务场景（如评论框、微博发布、表单提交限制）都依赖实时计数——因为用户需要即时反馈，而服务端校验永远滞后。
为什么必须用 input 事件而不是 keyup
常见错误现象：keyup 在右键粘贴、拖拽文本、语音输入、自动填充后完全不触发，导致字数卡在旧值；change 只在失焦时触发，彻底失去“实时”意义。
-
input是唯一能覆盖所有内容变更路径的事件：键盘输入、粘贴（Ctrl+V / 右键）、剪切、撤销（Ctrl+Z）、输入法上屏、甚至 Chrome 的自动填充 - IE9+ 全面支持，无需降级方案；移动端 Safari/Chrome 同样可靠
- 注意中文输入法场景：需配合
compositionstart和compositionend避免把拼音过程中的未确认字符计入（例如打“nihao”还没按空格，不应算6字）
value.length 统计的是什么长度？
它返回的是 UTF-16 码元数量，也就是 JavaScript 字符串的原生 .length 值。对绝大多数场景（含中文、emoji、标点、空格、换行）都准确，但要注意：
- 一个普通汉字 = 1，一个基础 emoji（如 ?）= 2（代理对），一个带肤色修饰的 emoji（如 ??）可能达 4–7 个码元
- 如果后端要求“Unicode 字符数”（即用户感知的“字数”），得用
Array.from(str).length或[...str].length，但性能略低，高频输入下需节流 - 别用
trim()后再算长度——空格和换行往往是有效内容，截断或校验逻辑应由业务决定，不是统计环节该干的事
如何避免 DOM 更新引发布局抖动？
每次 input 都更新 textContent 是安全的，但若同步读取元素尺寸（比如用 offsetHeight）、或频繁操作样式，会强制浏览器触发回流（reflow），造成卡顿。
立即学习“前端免费学习笔记（深入）”；
- 纯文本计数器（如
<span id="counter">0 / 100</span>）只改textContent即可，零布局成本 - 避免在
input回调里调用getBoundingClientRect()、offsetWidth等会触发布局的 API - 如果要做超长截断，用
textarea.value = value.slice(0, maxLength)后，务必手动调用setSelectionRange()恢复光标位置，否则用户会丢失编辑焦点
真正容易被忽略的不是事件选错或长度算错，而是中文输入法组合状态和 DOM 更新时机的耦合——compositionstart 到 compositionend 之间的 input 事件，内容是临时的，不该计入最终字数，但也不该阻断后续正常计数。
