Pinia 的 action 异步监控依赖 $onAction AOP 机制，精准捕获开始、成功、失败节点，兼容 async/await；支持耗时统计、分级错误上报、loading 状态联动及生命周期安全订阅。
Pinia 的 action 异步调用监控，核心靠 $onAction 实现——它不是“监听调用”，而是深入执行生命周期的 AOP 机制，能精准捕获开始、成功、失败三个关键节点，且天然兼容 async/await。
统一注入耗时与结果日志
在每个 action 执行前记录起始时间，利用 after 和 onError 分别处理成功与失败路径，自动等待 Promise 完成：
- 用
Date.now()记录执行起点，避免手动维护 timer 变量 -
after回调接收最终返回值（包括await后的 resolve 值） -
onError同时捕获同步throw和异步reject，无需额外 try/catch 包裹 action 内部 - 示例中可直接打印
name、args、耗时、结果或错误，便于快速定位慢接口或高频失败动作
集中式错误分类与上报
不把所有错误一视同仁，而是按 action 名称、错误类型（网络超时 / 4xx / 5xx / 业务码）、是否重试中等维度做分流处理：
- 检查
context.name匹配特定前缀（如'fetch'或'submit'），决定是否触发 Sentry 上报 - 从
error.response?.status或自定义error.code判断错误等级，低优先级错误仅本地打点，高危错误立即通知监控平台 - 对登录、支付类关键 action，可在
onError中自动触发用户登出或跳转错误页
配合 loading 状态做可视化联动
虽然 $onAction 本身不操作 state，但可通过 store 实例直接更新配套的 loading 字段，实现跨 action 的加载态统一管理：
- 在
before阶段（即回调函数主体）设context.store.loading = true - 在
after或onError中设为false，确保无论成功失败都收尾 - 注意：避免在多个并发 action 间互相覆盖 loading 状态，可改用计数器（
loadingCount++ / --）或 Map 记录各 action 独立状态
订阅生命周期管理与移除时机
监控逻辑需与使用场景生命周期对齐，防止内存泄漏或误触发：
- 在组件
setup()中调用$onAction，默认随组件卸载自动清理 - 若需全局长期监控（如埋点 SDK），传入
{ detached: true }并自行保管返回的unsubscribe函数 - 对路由级 store（如用户信息），建议在路由守卫中动态启用/禁用监控，避免后台页面持续采集无意义数据
