pinia 的 actions 本身不内置防抖能力，防抖必须在调用源头（如组件中）通过自定义 hook 或 watch + lodash.debounce 实现，并配合 abortcontroller 取消过期请求，确保仅执行最后一次稳定输入的搜索。
Pinia 的 Actions 本身不内置防抖能力，搜索关键字的防抖必须在调用源头控制节奏——不是阻止更新，而是确保只对“稳定输入”发起请求。核心在于把防抖逻辑放在触发点（如输入事件响应处），而非 store 内部硬编码，兼顾可复用性、this 绑定和生命周期安全。
推荐方式：在组件中用自定义 Hook 封装防抖调用
这是最灵活、最符合 Composition API 思想的做法。防抖函数在组件作用域内创建，能自然访问响应式状态、自动绑定 this，并可在卸载时清理定时器：
- 使用 lodash.debounce 或手写 setTimeout 版本，延迟执行 store 中的搜索 action
- 将防抖函数与 watch 或 @input 结合，监听搜索关键词变化
- 务必在 onBeforeUnmount 中清除定时器，避免内存泄漏或 this 失效
- 示例：输入框值变化后 300ms 才调用
searchStore.search(keyword)
可行方式：在 Store action 内部集成 debounce
适合语义明确、复用范围窄的搜索场景（如全局搜索 store）。注意 this 绑定和函数声明方式：
- 用 function 关键字 声明 action（不能用箭头函数），否则 debounce 返回的新函数会丢失 this
- 直接 import lodash/debounce，对整个异步函数做防抖包装
- 防抖后的 action 仍需处理 loading、error、结果赋值等完整流程
- 缺点：无法动态调整 delay，也不便于在不同组件中差异化配置
必须配合：AbortController 取消过期请求
仅防抖还不够——若用户快速输入 “reac” → “react” → “reactive”，前两个请求可能仍在 pending。为防止返回乱序覆盖正确结果，应在每次新搜索前中断旧请求：
- 在 store 中用 ref 存储 AbortController 实例
- 每次调用 search 前先
controller.abort()，再新建 controller 并传入 fetch 的signal选项 - 搭配防抖后，实际生效的是“最后一次输入 + 最后一次未被取消的请求”，双重保障结果一致性
补充建议：搜索状态与 UI 解耦
不要让输入框的每一次 change 都触发 store 更新。更优路径是：
- 组件内用 ref 或 reactive 管理本地搜索词（如
const keyword = ref('')） - 仅在防抖触发时，才调用
store.search(keyword.value) - 搜索结果、loading、error 等状态由 store 统一提供，组件用 storeToRefs 安全解构使用
- 这样既避免高频 patch，又让表单交互与数据加载职责分离
