大规模列表渲染性能瓶颈在于状态全量参与dom生成，而非状态管理本身；应通过shallowref冻结源数据、拆分可变状态、虚拟化可视区、精准节流更新及三层架构（源数据/逻辑/渲染）协同优化。
大规模列表的状态渲染性能问题，核心不在“状态管理”本身，而在于“状态如何被使用”——尤其是当状态直接驱动大量 DOM 渲染时。Vue 的响应式系统本身对万级数据的依赖追踪和更新是可控的，真正拖慢页面的是 一次性创建数万个响应式对象 + 渲染数万个 DOM 节点 这一组合动作。
别让状态全量参与渲染
即使你用 Pinia 或 Vuex 管理了 10 万条数据，只要在模板里写 v-for="item in list"，Vue 就会为每项生成 VNode、挂载响应式代理、创建 DOM 元素。这不是状态管理工具的问题，而是渲染策略失当。
- 对只读展示场景：用
shallowRef（Vue 3）或Object.freeze（Vue 2）包裹原始数组，跳过深层响应式代理，减少内存开销和初始化耗时 - 对需局部交互的列表（如某几行可编辑）：不要冻结整个列表，而是将“可变状态”拆离出来——比如只用一个
editingId: ref(null)记录当前编辑项 ID，渲染时按需计算样式或插槽，而非给每个 item 都加 reactive 包裹 - 避免在 store 中存冗余渲染态：例如不存
isHovered: true这类纯 UI 状态到全局 store，改用组件内ref或 CSS :hover
渲染层必须做虚拟化
状态管理再轻量，也救不了没做可视区裁剪的渲染。虚拟列表不是“可选优化”，而是万级以上数据的必要前提。
- 优先选用成熟库：如
vue-virtual-scroll-list（轻量、API 清晰）或vue-virtual-scroller（功能更全，支持动态高度） - 关键配置不能拍脑袋：
keeps（缓冲区数量）建议设为Math.ceil(containerHeight / itemHeight) + 10，太小滚动快时会闪白，太大失去优化意义 - 固定高度比动态高度高效得多；若必须支持变高，用
sizeKey或预估平均高度 + 后续异步修正，避免每次滚动都重算布局
状态更新要精准节流
当列表支持搜索、筛选、排序或实时追加时，频繁触发整个列表重渲染会抵消虚拟化效果。
- 筛选/搜索：用 computed 缓存结果，配合
shallowRef返回新数组引用，避免无意义的响应式更新 - 实时追加（如日志流）：用
unshift或push更新数据源后，主动调用虚拟列表的scrollTo(0)或forceUpdate()，而不是依赖 watch 全量刷新 - 批量操作（如全选删除）：先收集 ID，再一次性提交 mutation，避免逐项触发响应式更新和视图重绘
补充：结构分层比工具更重要
与其纠结用哪个 store，不如先厘清数据边界：
-
源数据层（raw data）：从 API 拿到的原始数组，用
shallowRef存，不响应式 -
逻辑层（computed/filter/sort）：用
computed派生出当前视图所需子集，保持响应式但不膨胀 - 渲染层（virtual list）：只接收逻辑层输出的切片数据，配合占位高度和 transform 定位，彻底隔离 DOM 压力
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
