Pinia 大规模状态更新优化包括：$patch 批量合并（对象式/函数式）、shallowReactive/shallowRef 控制响应式深度、拆分 Store + storeToRefs 按需订阅、扁平化 state 与延迟加载。

处理大规模状态更新时，Pinia 的核心优化目标是减少响应式开销、避免重复渲染、控制依赖追踪范围，并提升批量操作效率。以下四类手段经过中大型项目（如 wzry 图鉴、电商后台）验证，效果显著。

用 $patch 批量合并更新

单次触发响应式系统，比逐个赋值快 6–7 倍，重渲染次数从 N 次降为 1 次：

• 对象式：适用于同层级字段的简单合并，类型安全、可读性高
  store.$patch({ name: 'Alice', status: 'active', updatedAt: Date.now() })
• 函数式：适合数组操作、条件逻辑或需读取当前 state 的场景，直接操作响应式代理，不丢失引用
  store.$patch(state => { state.items.push(item); state.total += item.price; })
• 避免在 $patch 中执行耗时计算或 API 调用，应前置到 action 内完成

精准控制响应式深度

对万级数据或深层嵌套结构，避免默认 reactive 带来的性能惩罚：

• 用 shallowReactive 替代 reactive：仅代理第一层属性，子对象保持原始引用
  const list = shallowReactive([{ id: 1, detail: { ... } }])
• 对只读大数据集，改用 shallowRef + 手动 .value 访问，内存占用可降 40% 以上
• 避免在 state 中直接存 Class 实例、Map、Set 等非 plain object，$patch 可能无法正确追踪变更

拆分 Store + 按需订阅

降低单个 store 的响应式负担，让组件只响应真正关心的状态片段：

• 按业务域拆分为细粒度 store（如 useProductStore、useFilterStore），而非一个巨型 useAppStore
• 组件中不用 const store = useXXXStore() 全量引入，改用 storeToRefs 精确解构所需字段
  const { filteredItems, totalCount } = storeToRefs(productStore)
• 对非 UI 副作用（如日志、埋点），使用 $subscribe({ detached: true }) 全局监听，避免随组件卸载反复注册/清理

状态结构与初始化策略优化

从源头减少无效响应和启动压力：

• 扁平化 state：用 idMap: { [id]: item } + idList: string[] 替代嵌套数组，提升查找与更新效率
• 延迟加载大型数据：state 初始化为空或 null，首次访问时再通过 action 异步加载
  largeReport: null → loadReport() { this.largeReport = await api.fetch() }
• 避免 deep watch：如需监听数组长度或存在性，watch () => store.items.length 而非整个数组