计算属性不解决长列表卡顿，卡顿主因是全量渲染与频繁重排；需将耗时排序移出响应式链、用虚拟滚动等策略优化渲染，并确保key稳定和结构收敛。
计算属性本身不直接解决长列表卡顿，它只是响应式地派生数据；真正卡顿的根源在于全量渲染 + 频繁重排。当用计算属性对上万条数据做排序后直接 v-for 渲染，浏览器仍要一次性创建海量 DOM 节点——这会阻塞主线程、拖垮帧率。所以关键不是“怎么排序”，而是“排序后的结果怎么高效展示”。
先让排序不拖慢响应
大批量数据排序（如 10 万条）若在 computed 中同步执行，会明显卡住页面交互。应把耗时排序移出响应式链：
- 用 useMemo / computed({ lazy: true }) 包裹，仅在首次访问或依赖变更时执行，避免每次渲染都重算
- 排序逻辑本身加防抖或节流：用户还在输入搜索关键词时，暂不触发完整排序
- 前端排序有瓶颈？超过 5 万条建议交由后端完成，前端只接收已排序分页结果
- 若必须前端排序，可用 Intl.Collator 替代 localeCompare，性能提升约 30%；数字字段直接用
a.id - b.id，避免字符串转换开销
排序完的数据，别全量渲染
即使排序很快，渲染仍是瓶颈。此时计算属性输出的只是“有序数组”，后续必须配合渲染优化策略：
- 虚拟滚动（推荐）：只渲染可视区域 ±20 条，滚动时动态更新 slice 范围；容器设固定高度，用 translateY 定位，DOM 节点数恒定在 30–50 个
- 时间分片：用 requestIdleCallback 分批插入 DOM，每帧最多渲染 20 条，保证滚动和输入不卡顿
- 懒加载分页：排序后不全传给模板，而是按页缓存（如 pageData[1] = sorted.slice(0,30)），用户点击“下一页”再取下一段
key 和结构必须稳住
排序后若用索引作 key（:key="index"），顺序一变所有 key 都错位，Diff 算法强制卸载重建——等于白优化。务必做到：
- 每一项用稳定业务 id 作 key，如
:key="item.uuid"或:key="item.id" - 列表项组件内部结构收敛：避免条件渲染频繁切换标签类型（
div↔p），子组件用 React.memo / Vue.shallowRef 缓存 - 内联函数、对象不要写在模板里：
@click="() => select(item)"改为@click="select" :data-id="item.id"
额外提两个易忽略点
很多团队做了排序优化却仍卡，常因以下细节：
- 图片未懒加载：可视区外的
loading="lazy"或 IntersectionObserver 控制 - 高度未固定：虚拟滚动依赖预估项高来计算范围；若列表项高度不一致又没配置动态高度测量，会出现白屏或错位；优先设固定高度（如
h-16），次选使用vue-virtual-scroller的 dynamic mode
