解决竞态问题需分离触发与执行、用storeToRefs保持响应式、action返回Promise由组件协调、高频字段缓冲处理、跨Store依赖收口至组件层。
处理多个组件同时修改同一状态的竞态问题，关键不是阻止并发，而是让并发行为可预测、可控制、可收敛。核心思路是：分离“触发”与“执行”，明确数据流向，避免响应式层直接受扰。
用 storeToRefs 保住响应式连接
直接解构 store 中的属性会切断响应式，导致视图不更新，看似没报错，实则埋下竞态隐患——不同组件读到的可能是过期快照。
- ❌ 错误写法：const { count } = useCounterStore() → count 变成普通数字，后续 store.count++ 不触发任何组件更新
- ✅ 正确写法：const { count } = storeToRefs(useCounterStore()) → 仅提取 ref/computed 类响应式包装，保持依赖追踪
- 注意：action 方法必须从 store 实例调用，如 const store = useCounterStore(); store.increment()
异步操作必须返回 Promise 并由组件协调
多个组件同时调用同一个异步 action（比如 fetchUserInfo），若 action 内部没有收敛机制，极易出现重复请求、状态覆盖、回调乱序。
vue-component-analyzer
下载
递归分析 Vue 项目组件依赖，从入口文件生成组件层级图，支持 Vue 2/3，输出组件名、文件路径和属性。适用于分析组件结构、排查依赖或了解项目架构。
- Action 本身只负责封装逻辑和返回 Promise，不主动执行；禁止在 defineStore 的 setup 中直接调用异步函数
- 组件侧统一控制调用时机，例如：onMounted(() => store.load()) 或配合 watch 触发
- 需要并发协调时，用 Promise.all([p1, p2]) 或 await 显式等待，确保状态更新顺序可控
高频字段走缓冲层，不直写 Store
点赞数、库存余量等每秒被多次修改的字段，若每次变更都同步写入 Pinia，会频繁触发依赖收集、diff 和 patch，还可能因 JS 单线程造成中间态丢失。
立即学习“前端免费学习笔记（深入）”；
- 前端本地聚合：将多次增量暂存，定时（如 2 秒）批量提交 updateCount({ id, delta: +5 })
- 后端托管：Store 中只保留最终值快照，通过 WebSocket 或轮询同步 Redis 计数器结果
- 消息队列中转：前端发更新事件到 Kafka，后端消费落库并广播变更，Store 监听事件更新本地状态
跨 Store 依赖收口到组件层
一个 Store 直接 import 并调用另一个 Store 的 action，会让更新链路不可见、不可测、不可控，尤其在并发下容易出现交错执行和状态错乱。
- Store 之间保持松耦合，只暴露清晰的 state 字段和 action 接口
- 依赖关系应在组件 setup 中显式组织，例如先 await userStore.fetch()，再调用 orderStore.loadByUserId(userStore.id)
- 必要时用组合式函数封装跨 Store 流程，把协调逻辑上提到可测试、可复用的层级
