高频 Emit 卡顿本质是事件回调密集挤占主线程，导致渲染滞后；易卡顿场景包括输入、拖拽/滑动、滚动监听和实时上报；应依意图选防抖（重最终结果）或节流（保稳定节奏）；推荐手写轻量节流 emit 工具函数，并配合响应式优化。
高频触发的 Emit 事件卡顿，本质不是 Vue 或框架本身的问题，而是事件回调执行过于密集，挤占主线程资源，导致渲染滞后、响应延迟。尤其当 Emit 后立刻触发计算属性重算、watch 响应、DOM 更新或网络请求时，短时间大量任务堆积，浏览器来不及完成一帧（约16ms），就会掉帧、卡顿。
哪些 Emit 场景最容易卡顿？
并不是所有 Emit 都需要限流——关键看它是否由高频用户行为驱动，且后续操作有开销：
-
输入类：子组件通过
emit('update:modelValue')频繁同步输入内容，父组件又用该值做搜索建议或校验 -
拖拽/滑动类：拖动滑块、地图缩放、画布移动等持续触发
emit('change')，每次携带坐标或缩放级别 -
滚动监听类：子组件封装了滚动容器，内部
emit('scroll')暴露原生事件，父组件据此更新吸顶状态或懒加载 -
实时状态上报类：如音视频播放器频繁
emit('progress')，用于更新进度条或同步服务端播放位置
防抖 vs 节流：怎么选？
二者都靠闭包保存状态，但触发逻辑不同，适用动作意图也不同：
-
用防抖（Debounce）：当你只关心“最终结果”，不介意中间过程被丢弃。比如输入搜索框，用户敲完停顿 300ms 后才发请求，中间所有
emit都被忽略 - 用节流（Throttle）：当你需要“稳定节奏”，不能等太久，也不能太密。比如滚动中每 100ms 最多通知一次位置，保证父组件能及时响应，又不至于每像素都触发
在 Composition API 中优雅限流
推荐封装一个可复用的限流工具函数，直接作用于 emit 调用点，不侵入业务逻辑：
示例：基于时间戳的节流 emit
function throttleEmit(emit, eventName, limit = 100) {
let lastTime = 0
return function (...args) {
const now = Date.now()
if (now - lastTime >= limit) {
emit(eventName, ...args)
lastTime = now
}
}
}
<p>// 在 setup 中使用
export default {
setup(props, { emit }) {
const throttledEmit = throttleEmit(emit, 'update:position', 160)</p><pre class="brush:php;toolbar:false;">const handleDrag = (x, y) => {
throttledEmit(x, y) // 每160ms最多触发一次
}
return { handleDrag }} }
补充建议：若限流逻辑较复杂（如需支持取消、立即执行首次调用），可引入 lodash.throttle 或 lodash.debounce，但注意它们返回的是新函数，需确保 this 和参数传递正确；Vue 3 的 setup 中更推荐手写轻量实现，避免额外依赖。
别忘了配合响应式优化
限流只是第一步。如果 emit 后的响应逻辑本身低效，比如在 watch 里做深克隆、遍历大数组、强制触发多次 nextTick，卡顿仍会发生。建议：
- 将耗时计算移到
computed或使用useMemo类似逻辑缓存结果 - 对大数据列表更新，采用虚拟滚动或分页，而非全量重绘
- 非必要 DOM 操作，改用
requestAnimationFrame批量合并
