直接监听input事件会导致卡顿，因其每敲一键即触发，若含DOM查询、正则匹配或重排操作，易超16ms帧预算而掉帧；应改用requestAnimationFrame配合节流与状态标记延迟执行且去重更新。
为什么直接监听 input 事件会导致卡顿
用户每敲一个键就触发一次字数统计，如果逻辑里包含 DOM 查询（比如 textContent.length）、正则匹配或频繁重排（如更新 <span> 文本），浏览器可能在 16ms 内完不成，掉帧就明显。尤其在富文本编辑器或长文档中，input 触发频率远高于屏幕刷新率（例如连按会密集触发），盲目同步执行等于主动压垮主线程。
requestAnimationFrame 应该在哪儿调用
不是在 input 事件里直接写统计逻辑，而是只做“标记需更新”，把真正计算和渲染延迟到下一帧空闲时执行。关键点是：必须确保同一帧内多次触发只执行一次更新——靠节流 + 状态标记实现。
常见错误写法：input.addEventListener('input', () => requestAnimationFrame(countWords)) —— 这会在每次输入都注册新帧任务，没去重，仍可能堆积。
正确做法：
立即学习“前端免费学习笔记（深入）”；
let pending = false;
function scheduleCount() {
if (pending) return;
pending = true;
requestAnimationFrame(() => {
countWords();
pending = false;
});
}
input.addEventListener('input', scheduleCount);
统计逻辑里哪些操作必须避开
实时字数统计看似简单，但几个细节极易引发重排/重绘：
- 避免在
countWords()中反复读取element.innerText或textContent—— 如果编辑器内容结构复杂（含嵌套标签、<br>、零宽字符），解析开销大；建议缓存原始输入值或监听更干净的数据源（如contenteditable元素的textContent，而非innerHTML） - 避免每次更新都调用
el.textContent = `${count}`—— 即使值没变，也会触发 DOM 更新。加一层判断：if (el.textContent !== String(count)) el.textContent = String(count) - 不要在统计函数里调用
getBoundingClientRect()、offsetHeight等强制同步布局的 API
兼容性与降级要考虑什么
requestAnimationFrame 在 IE10+ 和所有现代浏览器都支持，但要注意：
- 服务端渲染（SSR）环境没有
window，直接调用会报ReferenceError: requestAnimationFrame is not defined—— 需包裹判断：if (typeof requestAnimationFrame === 'function') { ... } - 某些编辑器（如 CodeMirror、Monaco）有自己的事件循环机制，
input事件可能被拦截或延迟派发，此时应改用编辑器提供的钩子（如onDidChangeModelContent）并同样套用requestAnimationFrame节流 - 移动端软键盘弹出时，部分 Android WebView 会暂停
requestAnimationFrame，导致字数延迟显示，可加超时兜底：setTimeout(scheduleCount, 200)作为 fallback
最常被忽略的是：字数统计本身不该成为性能瓶颈，但一旦混入 DOM 操作、正则全局匹配（尤其是处理大量中文或 emoji 时）、或未防抖的样式读写，requestAnimationFrame 就只是给慢操作包了层糖衣。优化得从数据源和更新粒度开始，而不是只换一个调度方式。
