Pinia 的 Actions 是处理接口请求最自然的位置，应声明为 async 函数并统一用 await；API 调用需抽离至独立模块，Action 仅负责调用、状态更新与错误处理；需管理 loading/error/data 状态，确保 finally 关闭 loading；Action 应返回 Promise 以支持组件 await；同步逻辑如校验、本地计算无需 async。
Pinia 的 Actions 是处理接口请求最自然的位置，async/await 不是必须的，但凡是涉及网络请求的 Action，都应明确声明为 async 函数，并统一用 await 等待响应，避免混用 .then()。
把 API 调用抽离到独立模块
不要在 Action 里直接写 fetch 或 axios.get。先封装好请求函数，比如：
- 新建
api/user.ts，导出getUser(id: string): Promise - Action 中只负责调用它、更新状态、处理错误，逻辑更干净
- 便于复用、单元测试，也方便后续加拦截器或统一错误处理
在 Action 内管理 loading/error/data 状态
异步过程不是“发个请求就完事”，要主动控制 UI 反馈：
- 开始前设
this.loading = true，清空旧错误this.error = null - 成功后赋值
this.profile = res.data - 失败时捕获并设置
this.error，建议优先取err.response?.data?.message - 最后在
finally块中关闭 loading，确保无论成败都重置状态
确保 Action 返回 Promise，方便组件 await
Pinia 不会自动包装返回值，但只要 Action 内部用了 await 或显式 return Promise，调用时就能 await store.fetchUser(123)：
- 组件中可直接
await userStore.fetchUserProfile(id)，再更新按钮状态或跳转 - 避免忘记
await导致状态更新滞后或竞态问题 - 若需取消请求（如用户快速切换页面），可在 Action 中接入
AbortController
同步逻辑不强制 async
表单校验、本地计算、纯状态赋值等操作无需套 async/await：
- 例如
resetForm()、updateLocalCache()直接写同步方法即可 - 混合使用
await和.then()容易导致错误无法被捕获、堆栈混乱 - 保持风格统一：有请求就 async + await，没请求就普通函数
