高频状态更新卡顿主因是更新过碎过密，需在源头聚合变更；防抖适用于搜索、resize、拖拽、表格编辑等场景；推荐用hook封装并清理定时器，或在store中为语义明确action集成防抖；批量更新优先用$patch减少响应式通知次数。
高频状态更新导致卡顿，核心不是“不能更新”，而是“更新太碎、太密、太频繁”。Pinia 本身不干预更新节奏，需要你在触发源头控制——让状态变更更聚合、更可控、更贴合用户意图。
哪些操作真该防抖？
别给所有 action 加防抖，只盯住这几类由连续交互驱动、结果又无需即时反馈的操作：
- 输入框搜索：用户每敲一个字就调用 search()，会发一堆请求又丢弃前序结果
- 窗口 resize 后的布局适配：等用户停手再执行，避免反复重排重绘
- 鼠标拖拽过程中的坐标同步：只需最终位置或固定间隔采样，不必帧帧更新
- 表格编辑时的中间态保存：等用户失焦或点击确认再提交，而非每次 input change 都 patch
在组件里用防抖 Hook 封装调用
推荐在 Composition API 中封装可复用的防抖逻辑，绑定组件生命周期，避免内存泄漏：
- 用 lodash.debounce 或原生 setTimeout/clearTimeout 实现
- 在 setup 中调用，返回防抖后的函数，直接传给事件处理器（如 @input）
- 用 onBeforeUnmount 清理定时器，防止组件卸载后 still running
在 store 内部集成防抖逻辑
对业务语义明确的 action（比如搜索），把防抖写进 store 更直观：
- 用 debounce 包裹 action 函数，延迟时间按场景定（搜索常用 300ms）
- 必须用 function 声明，才能正确绑定 this（箭头函数会丢失 store 上下文）
- 注意 loading 状态、错误处理要包在防抖函数内部，确保 UI 反馈始终准确
批量更新优先用 $patch
防抖解决的是“调用太频”，$patch 解决的是“更新太散”——两者常配合使用：
- 单个 action 内多次修改 state 字段？改用 this.$patch({ a: 1, b: 2, c: true })
- 需读取当前值再计算？用函数式 this.$patch(state => { state.count++; state.list.push(x) })
- 这样无论改几个字段，都只触发一次响应式通知和一次视图更新，DevTools 也只记一条日志
