大型列表过滤应避免直接.filter()卡顿，需用shallowRef+computed控制响应式深度、节流搜索关键词、服务端分页+前端缓存，并禁用模板中方法调用过滤。
大型列表过滤用 computed 本身没问题，但直接 .filter() 遍历上千条数据会卡顿。关键不是“用不用 computed”，而是怎么用、配合什么策略来压低开销。
用 shallowRef + computed 控制响应式深度
如果商品列表是万级数组，每个对象又有多层嵌套，用 reactive 会让 Vue 为每个字段都建 Proxy 和依赖追踪，浪费巨大。改用 shallowRef 存原始数据，只让 .value 层响应：
-
const list = shallowRef([])—— 列表整体替换才触发更新 -
computed中只读取list.value，不访问深层属性（如item.category.name），避免无意触发深层追踪 - 搜索时只比对
item.name或item.id这类扁平字段，不深挖嵌套结构
加节流或防抖，减少 computed 触发频次
用户在搜索框连续输入时，searchKey 每变一次，computed 就重算一次。对大列表来说，这等于每敲一个字就遍历一遍。
vue-admin-change-reviewer
下载
审查 Vue 管理后台的变更请求（Vue 2 + Element UI，Vue 3 + Element Plus）。重点关注最小化变更实现、上线风险检查以及回归检查清单生成。
- 把搜索关键词用
ref存，但实际过滤逻辑不直接依赖它，而是依赖一个节流后的副本 - 用
watch监听输入，延迟 300ms 后更新节流关键词：throttledSearchKey.value = input -
computed只依赖throttledSearchKey，这样打字过程最多只重算 1–2 次
过滤逻辑前置：服务端分页 + 前端缓存结果
前端硬扛几千条过滤，本质是设计越界。更合理的做法是：
立即学习“前端免费学习笔记（深入）”；
- 首次加载只拉第一页（比如 50 条），带
search参数请求后端筛选 - 用户翻页或换关键词时，才重新请求，避免本地全量过滤
- 若必须前端过滤（比如离线场景），把上一次的
computed结果缓存为ref，下次搜索先比对关键词是否相同，相同就直接返回缓存值
避免模板里调用方法做过滤
有人把过滤写成 methods，然后在 v-for 里调用：{{ filterList(searchKey) }} —— 这会导致每次渲染都执行，且无缓存。
- 必须用
computed，哪怕只是简单包装一层：const filtered = computed(() => list.value.filter(...)) - 确保依赖项精简：只依赖
list.value和searchKey，不要混入user.permissions这类无关响应式变量 - 如果过滤结果要排序，把 sort 也放在同一个
computed里，别拆成两个计算属性链式调用，避免中间结果重复生成
