Pinia Actions需显式返回Promise以支持await，所有分支应统一返回Promise类型，推荐try/catch后return数据或re-throw错误；组件中可用await+try/catch安全处理结果，可选返回结构化对象并结合AbortController解决竞态请求。
Pinia 的 Actions 本身不自动包装返回值，但只要内部返回 Promise（无论是直接 return 还是 async 函数隐式返回），调用方就能用 await 或 .then() 获取执行结果。
确保 Action 显式返回 Promise
async 函数默认返回 Promise，但若中间有逻辑提前 return 非 Promise 值（比如错误时直接 return false），就会破坏 await 链。务必让所有分支都返回一致的 Promise 类型。
- 推荐写法：在 try/catch 后统一 return 成功数据，或让 catch 中 re-throw 错误
- 避免写法：catch 里只设 this.error 而不 throw，会导致组件 await 后拿到 undefined
- 示例正确返回：
return res.data（在 try 内），或throw err（在 catch 内）
在组件中安全 await Action 调用
组件内调用异步 Action 后，可直接 await，拿到 resolved 值；如需区分成功/失败，配合 try/catch 使用。
- 成功时：await 返回的是 Promise resolve 的值（比如 API 响应体中的 data）
- 失败时：若 Action 中抛出错误，await 会中断并进入 catch，可做 UI 提示或重试
- 注意：不要忽略 rejected 状态，否则错误会静默丢失
返回结构化结果（可选但实用）
不强制要求，但为提升组件层处理一致性，可在 Action 中统一返回 { success, data, error } 形式的对象。
- 避免组件反复判断 this.error 是否存在、this.data 是否有效
- 例如：
return { success: true, data: res.data }或{ success: false, error: '网络超时' } - 这样组件只需解构一次，逻辑更清晰，也方便后续加 loading 状态联动
竞态请求场景下的返回控制
当连续触发同一 Action（如搜索框输入），后发请求应覆盖前发请求的结果。此时返回值应只对应最后一次调用的 Promise。
- 靠 AbortController 取消旧请求，保证当前 await 拿到的一定是最新响应
- 不取消时，可能出现“先返回的慢请求覆盖了后返回的快结果”，造成 UI 错乱
- 返回值语义始终绑定到本次调用，与内部是否取消无关
