v-if 与 v-for 的基础认知
在Vue3的日常开发中,v-if 和v-for是最常用的两个指令:前者是"条件渲染的开关",决定元素是否出现在DOM中;后者是"列表渲染的工具",负责循环生成重复的元素。
v-if:控制渲染的"开关"
v-if通过表达式的真假来切换元素的渲染状态。比如:
vue
<template>
<!-- 当 showTitle 为 true 时显示标题 -->
<h1 v-if="showTitle">Vue3 条件渲染指南</h1>
</template>
<script setup>
import { ref } from 'vue'
const showTitle = ref(true) // 控制标题显示
</script>
当showTitle为false时,<h1>不会被渲染到DOM中------这是"真正的条件渲染",会销毁/重建元素及内部的事件监听、子组件。
v-for:循环列表的"打印机"
v-for用于遍历数组或对象,生成重复的元素。比如循环渲染待办列表:
vue
<template>
<ul>
<!-- 循环 todos 数组,每个项生成一个 <li> -->
<li v-for="todo in todos" :key="todo.id">
{{ todo.text }}
</li>
</ul>
</template>
<script setup>
import { ref } from 'vue'
const todos = ref([
{ id: 1, text: '写博客' },
{ id: 2, text: '改bug' }
])
</script>
这里要注意必须加key属性 ------Vue通过key识别列表项的唯一性,避免重新渲染时的性能问题。
v-if 与 v-for 结合的隐式优先级陷阱
当我们需要"只显示列表中满足条件的项"时,很容易想到把v-if和v-for写在同一个元素上。但Vue3的优先级规则会在这里设下"陷阱"。
优先级规则:Vue3 中 v-if 先于 v-for
Vue官方明确说明:在Vue3中,v-if的优先级高于v-for 。当两者写在同一个元素上时,v-if会先被评估,再执行v-for。
举个例子,假设我们要显示"已完成的待办项":
vue
<template>
<ul>
<!-- 错误写法:同元素混用 v-if 和 v-for -->
<li v-for="todo in todos" v-if="todo.done">
{{ todo.text }}
</li>
</ul>
</template>
在Vue3中,这段代码的执行逻辑是:先判断每个todo的done属性是否为true,再渲染这个li。虽然功能能实现,但藏着两个问题:
- 性能问题 :每个待办项都要执行一次
v-if判断,当列表很大时,渲染速度会变慢; - 逻辑混乱:模板混合了"数据过滤"和"列表渲染"的逻辑,可读性差,容易埋bug。
为什么优先级会导致问题?
再举个极端例子:如果v-if的条件不依赖循环项,比如v-if="showTodos":
vue
<template>
<ul>
<li v-for="todo in todos" v-if="showTodos">
{{ todo.text }}
</li>
</ul>
</template>
这时Vue3会先判断showTodos是否为true,再执行v-for循环。逻辑上没问题,但模板不够清晰 ------读者会疑惑"v-if到底控制的是整个列表还是单个项?"。
不推荐同元素使用的原因与改进方案
既然同元素使用有问题,那我们该怎么正确结合v-if和v-for?核心原则是:先过滤数据,再循环渲染。
不推荐同元素使用的核心原因
往期文章归档
-
Vue 3组合式API中ref与reactive的核心响应式差异及使用最佳实践是什么? - cmdragon's Blog
-
Vue 3组合式API中ref与reactive的核心响应式差异及使用最佳实践是什么? - cmdragon's Blog
-
Vue 3中watch侦听器的正确使用姿势你掌握了吗?深度监听、与watchEffect的差异及常见报错解析 - cmdragon's Blog
-
Vue 3中reactive函数如何通过Proxy实现响应式?使用时要避开哪些误区? - cmdragon's Blog
-
快速入门Vue的v-model表单绑定:语法糖、动态值、修饰符的小技巧你都掌握了吗? - cmdragon's Blog
-
只给表子集建索引?用函数结果建索引?PostgreSQL这俩操作凭啥能省空间又加速? - cmdragon's Blog
-
想抓PostgreSQL里的慢SQL?pg_stat_statements基础黑匣子和pg_stat_monitor时间窗,谁能帮你更准揪出性能小偷? - cmdragon's Blog
-
PostgreSQL 查询慢?是不是忘了优化 GROUP BY、ORDER BY 和窗口函数? - cmdragon's Blog
-
PostgreSQL选Join策略有啥小九九?Nested Loop/Merge/Hash谁是它的菜? - cmdragon's Blog
-
PostgreSQL索引选B-Tree还是GiST?"瑞士军刀"和"多面手"的差别你居然还不知道? - cmdragon's Blog
-
PostgreSQL处理SQL居然像做蛋糕?解析到执行的4步里藏着多少查询优化的小心机? - cmdragon's Blog
-
PostgreSQL备份不是复制文件?物理vs逻辑咋选?误删还能精准恢复到1分钟前? - cmdragon's Blog
-
PostgreSQL里的PL/pgSQL到底是啥?能让SQL从"说目标"变"讲步骤"? - cmdragon's Blog
-
PostgreSQL UPDATE语句怎么玩?从改邮箱到批量更新的避坑技巧你都会吗? - cmdragon's Blog
-
PostgreSQL 17安装总翻车?Windows/macOS/Linux避坑指南帮你搞定? - cmdragon's Blog
-
能当关系型数据库还能玩对象特性,能拆复杂查询还能自动管库存,PostgreSQL凭什么这么香? - cmdragon's Blog
-
如何用GitHub Actions为FastAPI项目打造自动化测试流水线? - cmdragon's Blog
免费好用的热门在线工具
- 性能开销大:每个循环项都要执行条件判断,数据量大时渲染慢;
- 逻辑可读性差:模板中混杂了业务逻辑(过滤)和渲染逻辑(循环),后期难维护;
- 优先级隐式性:新手容易忽略优先级规则,导致逻辑错误。
改进方案1:用 computed 过滤数据(推荐)
computed是Vue3中处理响应式数据的"神器"------它会缓存计算结果,只有当依赖的响应式数据变化时才重新计算。
用computed改进之前的"已完成待办"示例:
vue
<template>
<ul>
<!-- 推荐:循环过滤后的数组 -->
<li v-for="todo in doneTodos" :key="todo.id">
{{ todo.text }}
</li>
</ul>
</template>
<script setup>
import { ref, computed } from 'vue'
const todos = ref([
{ id: 1, text: '写博客', done: true },
{ id: 2, text: '改bug', done: false },
{ id: 3, text: '测功能', done: true }
])
// 用 computed 过滤"已完成"的待办项
const doneTodos = computed(() => {
return todos.value.filter(todo => todo.done)
})
</script>
这样做的好处:
- 性能优化 :
computed缓存过滤结果,避免重复计算; - 逻辑清晰:模板只负责渲染,过滤逻辑放在JS中,符合"关注点分离"原则;
- 可复用性 :
doneTodos可以在模板中多次使用,不用重复写过滤逻辑。
改进方案2:将 v-if 移至父元素(适用于全局条件)
如果v-if的条件不依赖循环项 (比如控制整个列表是否显示),可以把v-if放在v-for的父元素上:
vue
<template>
<!-- 先判断是否显示整个列表 -->
<div v-if="showTodos">
<ul>
<li v-for="todo in todos" :key="todo.id">
{{ todo.text }}
</li>
</ul>
</div>
</template>
<script setup>
const showTodos = ref(true) // 控制整个列表的显示
</script>
这种写法的逻辑更直观:v-if控制父元素的显示,v-for负责循环子元素,完全避免了优先级问题。
实战示例:从错误到最佳实践
我们用一个"电商商品列表"的场景,完整演示从错误到正确的写法。
错误用法:同元素混用导致性能问题
需求:显示"有库存的商品":
vue
<template>
<div class="products">
<!-- 错误:同元素用 v-if 和 v-for -->
<div v-for="product in products" v-if="product.inStock" :key="product.id">
{{ product.name }} - {{ product.price }}元
</div>
</div>
</template>
<script setup>
const products = ref([
{ id: 1, name: '手机', price: 5000, inStock: true },
{ id: 2, name: '电脑', price: 8000, inStock: false },
{ id: 3, name: '平板', price: 3000, inStock: true }
])
</script>
问题:每个商品都要判断inStock,当商品数量很大时,渲染速度会变慢。
最佳实践:用 computed 过滤后循环
改进后的代码:
vue
<template>
<div class="products">
<!-- 正确:循环过滤后的商品 -->
<div v-for="product in inStockProducts" :key="product.id">
{{ product.name }} - {{ product.price }}元
</div>
</div>
</template>
<script setup>
import { ref, computed } from 'vue'
const products = ref([/* 同上 */])
// 计算有库存的商品
const inStockProducts = computed(() => {
return products.value.filter(p => p.inStock)
})
</script>
这样v-for只循环过滤后的inStockProducts,不需要每个商品判断,性能提升明显。
课后 Quiz:巩固你的理解
问题:在Vue3中,为什么不推荐在同一个元素上同时使用v-if和v-for?请说明优先级规则及两种改进方案。
答案解析:
- 优先级规则 :Vue3中
v-if的优先级高于v-for,同元素使用时v-if先被评估; - 不推荐原因 :
- 若
v-if条件依赖循环项,每个项都要判断,性能差; - 模板逻辑混合过滤与循环,可读性低;
- 若
- 改进方案 :
- 方案1:用
computed过滤数据,再用v-for循环过滤后的结果(适用于条件依赖循环项的场景); - 方案2:将
v-if移至v-for的父元素上(适用于条件不依赖循环项的场景)。
- 方案1:用
常见报错与解决小贴士
报错1:v-if与v-for同元素时逻辑不符合预期
- 症状:循环的列表项显示不全,或条件判断失效;
- 原因 :Vue3中
v-if优先级更高,同元素使用时v-if先评估,若条件依赖循环项,会导致每个项都要判断,逻辑混乱; - 解决 :用
computed过滤数据后再循环。
报错2:循环列表渲染缓慢
- 症状:列表数据量大时,渲染时间长;
- 原因 :同元素使用
v-if和v-for,每个项都要执行条件判断,性能开销大; - 解决 :通过
computed或方法过滤数据,减少循环的项数。
预防建议
- 永远优先用
computed处理数据过滤,再循环; - 若条件不依赖循环项,将
v-if放在父元素上; - 避免在模板中写复杂条件,尽量把逻辑移到JS部分(
computed/methods)。