vue 3 中应使用 computed 预过滤数据再配合 v-for 渲染，避免在 v-for 内用 v-if 导致重复遍历；需用稳定业务 id 作 key，复杂逻辑可分层 computed 或封装函数，禁用 methods 实现过滤以防失去缓存。
在 Vue 3 中，把 computed 和 v-for 配合做数据过滤，是提升列表渲染性能最直接有效的方式之一。核心逻辑很简单：**让过滤发生在模板渲染之前，而不是在每次循环中重复判断**。
用 computed 提前过滤，避免 v-for 内部遍历全量数组
当原始数据量较大（比如几百上千项），而实际要显示的只是其中一小部分时，如果在 v-for 中混用 v-if 做条件筛选，Vue 会先对每一项执行 v-if 判断——哪怕最终只渲染 3 条，也要遍历全部数组。这会造成不必要的计算开销。
正确做法是把过滤逻辑抽到 computed 中，利用其缓存特性：
- 只要依赖的数据没变，计算属性不会重新执行
- 模板里直接遍历过滤后的结果，
v-for只处理真正要渲染的项 - 响应式更新也更精准：只有过滤条件或源数组变化时，才会触发重新计算
注意 key 的唯一性与稳定性
过滤后仍需为 v-for 每一项提供稳定、唯一的 :key。推荐使用原始数据中的业务 ID（如 item.id），不要用过滤后数组的索引（index）。
原因很实在：过滤结果可能随条件变化而增减，索引会频繁变动，导致 Vue 无法复用已有 DOM 节点，反而引发更多创建/销毁操作。
复杂过滤逻辑可拆解为多个 computed 或封装成函数
如果过滤条件多（比如按状态、关键词、时间范围组合筛选），不建议把所有逻辑堆在一个 computed 里。可以分层处理：
- 用一个
computed做基础过滤（如只保留启用项） - 再套一层
computed做搜索匹配（如.filter(item => item.name.includes(searchTerm))） - 或者把过滤逻辑提取为普通函数，在
computed中调用，便于单元测试和复用
这样既保持逻辑清晰，又不影响缓存机制——只要输入参数不变，函数返回值就稳定，computed 依然能命中缓存。
慎用方法调用替代 computed 过滤
有人会写 v-for="item in filterItems(items)"，把过滤逻辑放在 methods 里。这看似灵活，但每次渲染都会重新执行函数，完全失去缓存能力。尤其当 filterItems 内部有较重逻辑（如深比较、正则匹配、嵌套遍历）时，性能损耗明显。
除非过滤逻辑依赖非响应式外部变量（比如时间戳、随机数），否则一律优先用 computed。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
