Vue长列表实时过滤应采用computed替代watch实现缓存计算，结合防抖延迟更新关键词，并配合虚拟滚动仅渲染可视区域，超复杂场景可启用Web Worker后台过滤。
Vue.js 中对长列表进行实时过滤时，监听器（watch）若直接触发全量遍历或重新计算，极易引发卡顿、响应延迟甚至页面冻结。核心问题不在监听本身，而在于**过滤逻辑是否可缓存、是否同步阻塞主线程、是否触发不必要的响应式更新**。优化关键在于“懒计算 + 懒更新 + 懒渲染”三层协同。
用 computed 替代 watch 做响应式过滤
监听器默认是命令式、同步执行的，容易在输入频繁时反复调用耗时函数；而 computed 具备缓存机制，仅当依赖项变化时才重新求值，天然适合过滤这类派生数据。
- 把过滤逻辑从
watch移入computed，例如：filteredList依赖rawList和searchTerm - 确保
rawList和searchTerm是响应式数据（ref 或 reactive），Vue 自动追踪依赖 - 避免在
computed中做副作用（如发请求、修改 state），只返回新数组
加防抖 + 异步更新，切断高频输入与计算的强绑定
用户连续输入时，每敲一个字都触发一次过滤，对上千条数据来说开销巨大。需将“输入事件”和“实际过滤”解耦。
vue-admin-change-reviewer
下载
审查 Vue 管理后台的变更请求（Vue 2 + Element UI，Vue 3 + Element Plus）。重点关注最小化变更实现、上线风险检查以及回归检查清单生成。
- 用
lodash.debounce或原生setTimeout包裹搜索关键词更新，例如延迟 300ms 后才赋值searchTerm - 或使用
watch监听输入框的input事件，内部节流后更新关键词，再交由computed自动响应 - 不推荐在
watch内直接调用filter()—— 这会绕过 computed 缓存，失去优化意义
大列表配合虚拟滚动，避免 DOM 渲染瓶颈
即使过滤逻辑变快，若渲染 5000 条匹配结果，浏览器仍会因创建大量 DOM 节点而卡死。此时过滤性能已不是瓶颈，渲染才是。
立即学习“前端免费学习笔记（深入）”；
- 引入虚拟滚动方案（如
vue-virtual-scroller或virtuoso），只渲染可视区域内的 20~30 条 - 确保
filteredList作为源数据传入虚拟滚动组件，它只负责切片，不参与过滤 - 避免对
filteredList做v-for全量遍历渲染——这是最常见却最致命的误用
进阶：Web Worker 处理超重过滤逻辑
当过滤条件极其复杂（如多字段模糊匹配 + 正则 + 自定义评分），且数据量达万级，连 computed 在主线程执行也会阻塞 UI。
- 将过滤函数抽离为独立模块，通过 Web Worker 在后台线程执行
- 主线程只发送
rawList和searchTerm，Worker 返回过滤后 ID 列表或精简数据 - 注意：Worker 无法直接访问 Vue 响应式对象或 DOM，需传递纯 JSON 数据
- 适用于管理后台、数据分析类场景，普通搜索一般无需此级优化
