Pinia 处理大型应用状态的关键是精准拆分、轻量使用和稳定更新：按业务域（如用户权限、商品目录）而非页面或组件拆分 store；控制响应式粒度，对大数据用 shallowRef/shallowReactive；采用 idMap+idList 结构和延迟加载；组件按需订阅字段，避免全量监听。
Pinia 处理大型应用中海量状态，关键不在“怎么存得多”，而在“怎么拆得准、用得轻、改得稳”。合理拆分不是为了多建几个文件，而是让每个 store 有清晰的业务边界、可控的响应式范围和可预测的数据流。
按业务域而非页面或组件拆分
一个 store 应代表一个真实存在的业务概念，比如用户权限、商品目录、订单生命周期、通知中心等。它不服务于某个 UI 区块（如 headerStore 或 sidebarStore），也不绑定某一页（如 homeStore）。这样拆分后，多个页面和组件能安全复用同一份逻辑，避免重复实现和状态不一致。
- ✅ 推荐：useUserStore 管理登录态、token 刷新、角色权限校验
- ✅ 推荐：useProductStore 封装分类加载、搜索缓存、SKU 联动
- ❌ 避免：把“弹窗开关”“折叠状态”这类纯 UI 行为塞进全局 store
控制单个 store 的响应式粒度
即使拆分了模块，若某个 store 内部 state 过于庞大（如万级商品列表），默认 reactive 仍会带来可观开销。此时需主动降级响应式深度：
- 对只读大数据集合，用 shallowRef 存储，需要时才通过 .value 访问，内存占用可显著下降
- 对需部分响应式的嵌套结构，用 shallowReactive 替代 reactive，仅代理第一层属性，子对象保持原始引用
- 避免在 state 中直接存放 Class 实例、Map、Set 等非 plain object，否则 $patch 可能无法追踪变更
扁平化 + 延迟加载，从源头减负
结构设计直接影响更新效率和首屏压力：
- 用 idMap + idList 替代深层嵌套数组：例如
{ items: { '1': { id: '1', name: 'A' } }, list: ['1', '2'] }，查找、更新、局部渲染都更高效 - 大型数据（如报表、历史日志）初始化为 null 或空数组，首次访问时再触发 action 异步加载，避免启动时拉取全部
- 对非核心字段（如富文本详情、图片元数据），考虑延迟解析或按需解构，不一次性激活所有响应式依赖
按需订阅，避免组件被无关更新触发重渲染
组件不该为整个 store “买单”。即使 store 拆得细，若组件全量引入并监听全部字段，性能损耗仍在：
- 不用
const store = useXXXStore()后直接访问store.xxx，而应配合 storeToRefs 解构真正需要的字段 - 对副作用类操作（如埋点、日志），使用
$subscribe({ detached: true })全局监听，避免随组件挂载/卸载反复注册清理 - 非 UI 场景（如定时同步、离线缓存）尽量走独立逻辑，不强耦合到 store 的响应式系统中
