pinia action异常链路追踪依赖分层协作机制：action内保留完整错误上下文并添加业务元数据，$onaction统一拦截并结构化日志，关联后端traceid，组件层补充脱敏用户行为快照。
Pinia 的 Action 异常链路追踪不是靠单点捕获实现的，而是一套分层协作机制：从 Action 内部主动抛出、到 $onAction 统一拦截、再到错误分类与上下文增强，最终对接监控系统。关键在于把“谁在什么时候、因为什么、在哪一步出错”这些信息串起来。
在 Action 内保留原始错误上下文
异步 Action 中不要吞掉原始错误，避免只留 message 而丢失堆栈和响应细节：
- 用 try/catch 包裹请求逻辑，但 catch 中不简单赋值 error 字符串，而是保留完整 error 对象（包括 status、url、response、stack）
- 给 error 添加业务元数据，比如：error.action = 'fetchUserProfile'、error.userId = id
- 必要时用 Error.captureStackTrace 扩展自定义错误类，确保 devtools 和 Sentry 可识别
用 $onAction 做统一入口拦截
$onAction 是链路追踪的中枢，它能拿到执行前后的完整上下文：
- 监听时提取 context.name、context.store.$id、context.args，记录 Action 调用起点
- 在 onError 回调中，把 error 与 context 合并为结构化日志对象，例如：{ action: 'fetchUserProfile', store: 'user', args: [123], timestamp: Date.now(), error }
- 避免只 console.error，应调用统一上报函数（如 reportError(log)），便于后续聚合分析
关联前端请求与后端 traceId
若后端已支持分布式追踪（如 OpenTelemetry），可在 Action 中打通链路：
- API 请求头中透传 traceId（从上一个请求或生成新 traceId）
- 在 $onAction 的 onError 中，将 traceId 注入 error 对象：error.traceId = response.headers.get('x-trace-id')
- 上报时携带 traceId，使前端错误可直接跳转到后端对应日志或 Flame Graph
组件层补充用户行为快照
单纯 Action 错误缺乏场景还原能力，需在触发点补充轻量上下文：
- 在按钮点击等调用 Action 前，临时记录当前路由、表单字段值、用户角色等关键状态
- 将快照挂载到 error 对象上：error.context = { route: '/profile/edit', formDirty: true, role: 'admin' }
- 注意脱敏处理敏感字段（如手机号、token），可用哈希或掩码替代
