全局状态高并发更新需分层控制：应用层聚合缓冲、状态层保响应性、业务层明职责边界；须用storeToRefs保持响应式，异步Action要返回Promise且不自执行，热点字段走缓冲层，跨Store依赖应在组件侧协调。

全局状态在高并发更新下容易出现数据竞争，核心在于避免多个请求同时修改同一份响应式数据导致覆盖、丢失或不一致。关键不是“锁住整个 Store”，而是分层控制：在应用层做聚合与缓冲，在状态层保响应性，在业务层明职责边界。

用 storeToRefs 保住响应式，别直接解构

组合式 Store 中，直接从 useXXXStore() 解构属性会切断响应式连接，后续更新无法触发视图刷新。这是最隐蔽也最常被忽略的坑。

• 错误写法：const { count } = useCounterStore() —— count 变成普通数字，失去响应性
• 正确写法：const { count } = storeToRefs(useCounterStore()) —— 只提取 ref、computed 等响应式成员，方法和普通字段被自动过滤
• 补充提醒：storeToRefs 不处理 action，调用方法仍需从 store 实例上取，如 const store = useCounterStore(); store.increment()

异步 Action 必须返回 Promise，且不在 setup 内自执行

并发场景下，多个组件同时调用同一个异步 action（如 fetchUser），若 action 内部没有合理控制，极易引发重复请求、状态覆盖或竞态回调。

• Action 要显式返回数据或 Promise，方便上层 await 或 Promise.all 统一协调
• 禁止在 defineStore 的 setup 函数里直接调用异步逻辑（如 loadData()），否则 Store 初始化即发请求，不可控且难以测试
• 推荐模式：action 只负责“触发 + 返回”，数据加载时机交给组件决定（比如 onMounted、watch 触发）

高频更新字段走缓冲层，不直写 Store

像点赞数、浏览量、库存余量这类热点字段，每秒可能被数千次更新，直接写入 Pinia store 会造成大量响应式依赖触发和 Vue 更新开销，还可能因 JS 单线程特性导致状态错乱。

• 方案一：前端本地聚合 + 定时批量提交（如每 2 秒汇总一次，调用 updateCount({id, delta})）
• 方案二：接入 Redis 计数器，Store 中只维护最终值快照，通过事件或轮询同步（适合强一致性要求不高的指标）
• 方案三：用消息队列中转更新（如 Kafka），后端消费后落库并广播变更，Store 仅监听变更事件更新本地状态

跨 Store 依赖放在组件侧，别在 Store 内硬耦合

一个 Store 主动 import 并调用另一个 Store 的 action，看似方便，实则埋下并发隐患：两个 Store 的异步操作可能交错执行，状态更新顺序不可预测，调试困难。

• 正确做法：在组件 setup 中同时使用多个 Store，由组件统一协调调用时序（例如先等 userStore.ready 再触发 orderStore.load）
• 进阶建议：对强依赖关系，可封装一个组合式函数（composable），把多 Store 逻辑收口，但依然保持调用权在组件
• 警惕循环依赖：A Store 用 B，B Store 又反过来读 A 的某个 ref —— 这会导致初始化失败或响应链断裂