pinia 的 action 本身不内置重试机制，但可通过中间件或手动封装实现稳定可控的重试逻辑：统一用中间件注入重试能力，支持按错误类型、次数、退避策略精准控制；手动封装适用于需取消请求、递归重试等精细场景；配合 $onaction 可观测重试过程；需规避自动重试用户操作、无限重试、未清理副作用等陷阱。
Pinia 的 action 本身不内置重试机制，但可以通过中间件或手动封装实现稳定、可控的重试逻辑。关键不是“加几次 retry”，而是让重试行为符合业务场景——比如网络抖动时自动补救，又不干扰用户主动操作或造成状态混乱。
用中间件统一注入重试能力
把重试逻辑抽离到中间件里，避免每个 action 重复写 while 循环和 setTimeout。中间件可作用于整个 store 或指定 action，维护一致性：
- 定义最大重试次数（如 3 次）和基础退避间隔（如 500ms）
- 只对特定错误类型重试（例如网络超时、502/503，跳过 401 或 404）
- 在重试前清空上一次的 loading/error 状态，防止残留
- 最终失败时仍抛出原始错误，确保组件能捕获并展示
在 action 内部手动控制重试
适合需要精细判断的场景，比如搜索联想请求需取消前序未完成请求 + 有限重试：
- 使用 AbortController 配合 fetch，每次新请求自动 abort 上一个
- 用递归或循环 + await new Promise(resolve => setTimeout(resolve, delay)) 控制间隔
- 记录当前重试次数，失败后更新 error 字段供视图显示（如 “已重试 2 次，稍后自动重试”）
配合 $onAction 实现可观测重试过程
利用 Pinia 提供的 $onAction 监听器，把重试行为“可视化”：
- 在 onError 回调中识别是否属于重试中的失败，打标记或上报日志
- 在 after 中检查 result 是否来自重试路径，用于埋点或调试
- 结合 loading 状态，在重试发起时保持 loading = true，避免 UI 闪退
注意避开常见陷阱
重试不是万能解药，滥用反而降低体验：
- 不要对用户显式操作（如提交表单）自动重试，应交由用户确认
- 避免无限重试或指数退避失控，建议硬性限制总耗时（如 ≤ 10s）
- 重试期间若用户切换页面或离开，需及时 abort 并清理副作用
- 服务端幂等性必须保障，否则重复请求可能引发数据异常（如重复下单）
