企业官网建设流程全解析

很多同学学到 Vue 模板语法时，最容易卡住的地方不是插值、不是 v-if 和 v-for，而是那些看起来不起眼的指令修饰符，以及 class 和 style 的绑定写法。等到开始写业务逻辑，又会被computed和watch的选择题困住：到底什么时候用计算属性，什么时候用侦听器，为什么 computed 能缓存而 methods 不行，为什么 watch 监听对象不管用。这些点单个拎出来都不难，但放到同一个项目里，就会发现它们其实是一条线：从模板到逻辑，Vue 响应式系统在不同层面的表达方式。

这篇文章把四个主题放在一起讲，不是为了凑篇幅，而是因为它们在实际开发中经常结伴出现。指令修饰符负责处理模板里的 DOM 事件细节，样式绑定解决动态类名和行内样式问题，computed 承担派生状态的声明式描述，watch 处理副作用和异步流程。理解了这一整套组合拳，你写出来的代码会明显更干净，也更符合 Vue 的"数据驱动"思维。无论你是刚入门 Vue 的新手，还是已经从 Options API 转向 Composition API 的开发者，这篇文章都值得你花 20 分钟静下心过一遍，很多你踩过的坑，其实都是这些基础点没吃透。

1. 指令修饰符：写在模板里的“语法糖”与性能开关

1.1 事件修饰符的取舍逻辑

Vue 为 v-on 提供了以点号开头的事件修饰符，比如.stop、.prevent、.capture、.self、.once、.passive。很多人把它当成"少写几行 addEventListener 配置"的语法糖，但它的价值远不止于此。以.stop为例，你真的可以这样做：

<button @click.stop="handleClick">点我</button>

它等价于你在handleClick里手动调用event.stopPropagation()。但差别在于，修饰符是声明式的：模板一眼就能看出来"这个点击不会冒泡"，而不用翻开 JS 逻辑才发现里面藏着stopPropagation。在团队协作时，这种"模板即文档"的特性非常重要，新成员接手组件，光看模板就能把握大部分交互边界。

.prevent也是同理，最常见的场景是表单提交：

<form @submit.prevent="onSubmit">

有些同学喜欢在onSubmit里写event.preventDefault()，这没问题，但要注意：如果你的提交函数还有别的逻辑，比如校验、格式化，preventDefault就容易被遗忘在某个分支里。用修饰符把它放在模板层，提交行为是否被拦截，肉眼可见，不存在漏执行的问题。

.capture和.self用得相对少，但理解它们有助于你排查事件流问题。.capture让事件在捕获阶段触发，而不是默认的冒泡阶段，适合做事件委托时希望"更早介入"的场景。.self则要求事件必须由目标元素自身触发才执行，这能有效避免子元素冒泡导致的误触发：

<div class="modal" @click.self="closeModal"> <!-- 点击遮罩关闭，点击内部内容不关闭 --> </div>

做弹窗组件时，@click.self几乎是标配写法，比在closeModal里判断event.target === event.currentTarget要清爽得多。但我得提醒一句：.self只解决"自己触发"的问题，它并不阻止冒泡。如果弹窗内部有按钮触发了事件冒泡到外层，.self是不会拦截的，该配合.stop的地方还是得配合。

.passive是个有意思的修饰符，它对应addEventListener的passive: true选项，主要用来告诉浏览器"这个滚动事件的默认行为我不会阻止，你可以放心地立即滚动"。在移动端监听touchmove时，没有.passive，浏览器会担心你在事件处理函数里调用preventDefault，从而阻塞滚动，导致页面卡顿。加上.passive之后，滚动丝滑很多：

<div @scroll.passive="onScroll">...</div>

但这里有条红线：.passive不能和.prevent同时使用，因为一旦声明了 passive，浏览器就默认你不会调用 preventDefault，你再写.prevent也是无效的，而且 Vue 会在控制台给你一条警告。实际项目中，滚动优化和阻止默认行为，大多数时候是二选一的场景，别硬凑一起。

1.2 表单修饰符与按键修饰符的实战选择

表单相关的修饰符.lazy、.number、.trim在处理用户输入时非常实用，它们直接把"原始输入值"转换成"你真正想要的数据类型"。

.lazy把input事件切换成change事件触发同步，什么意思呢？默认情况下，v-model是用户每敲一个字符，数据就更新一次。加了.lazy后，要等输入框失焦或者用户按下回车，数据才更新。这在大表单场景里特别有用，比如用户正在填写一段很长的描述，你不想让右侧的预览区域随着每个字符实时刷新，等他失焦后再统一更新，性能更好，视觉上也更稳定。当然，如果做的是带实时提示的搜索框，那就千万别加.lazy，那会让你失去"边输入边联调"的交互体验。

.trim的用途更直白：自动去掉输入内容首尾的空白字符。我见过不少同学在提交表单时用value.trim()手动处理，但在每个事件函数里重复这种操作很容易漏，尤其当表单字段很多时。写成这样：

<input v-model.trim="username" />

Vue 会帮你保证username变量里的值始终是去掉首尾空格的。不过要注意，它只处理首尾，不会压缩中间连续的空格，比如用户输入"前端 开发"，中间那个空格还在，需要的话还得配合 normalize 函数处理。

.number这个修饰符坑过不少人。文档上说"自动将用户的输入值转为数值类型"，但它的实际行为是：如果输入内容能被parseFloat解析，就转成数字，否则保留原始字符串。也就是说，输入"123abc"，结果是123；输入"abc123"，结果是"abc123"。这在做带单位或混合内容的输入框时容易造成困惑，我的建议是：如果你需要严格的数值校验，别依赖.number，还是在逻辑层处理，或者配合type="number"的输入框一起用，多数场景下还是能覆盖到的。

按键修饰符这块，最常见的是监听回车和 Esc：

<input @keyup.enter="submit" /> <button @keyup.esc="cancel">取消</button>

你还可以用@keyup.ctrl.enter这种链式写法表达组合键，或者用.exact精确控制："只有按下 Ctrl 加回车时才触发，其他键都不要"：

<input @keyup.ctrl.enter.exact="submit" />

这套方案的优势是，把键盘交互从event.keyCode那种硬编码里解放出来。以前写原生 JS 时，我记得每个键盘事件函数里都得有一行if (event.keyCode === 13)，代码一多全是魔法数字。Vue 的按键修饰符让按键语义直接出现在模板中，可读性强了不止一个量级。但别忘了，部分浏览器对某些按键组合的默认行为有差异，比如移动端软键盘的回车键行为，这部分没法完全依赖 Vue 修饰符，必要时还是要做兼容处理。

2. 样式绑定：从“三元嵌套地狱”到结构化方案的进化

2.1 class 绑定：对象语法与数组语法的适用边界

样式绑定看起来简单，不就是:class和:style吗？但实际开发中，很多人写着写着就变成了"三元表达式嵌套地狱"。比如：

<div :class="active ? 'active' : ''">...</div>

这种写法在一两个类名时还行，一旦有多个状态条件，模板就变得难以阅读：

<div :class="[isActive ? 'active' : '', isError ? 'error' : '', isDisabled ? 'disabled' : '']">

我见过有人在这种三元嵌套中把层级写到四五层深，模板看起来像 JSON 压缩包，维护起来只想离职。Vue 提供的对象语法，就是用来收拾这种局面的：

<div :class="{ 'active': isActive, 'error': isError, 'disabled': isDisabled }">...</div>

对象语法的本质是"类名到布尔值的映射"：键是类名，值是决定该类名是否存在的条件。这样写，最直观的好处是模板的语义清晰，每一个类名都对应一个明确的判断变量，不用费脑细胞去解析三元表达式。而且，Vue 会为:class的绑定合并元素本身的静态class属性，你不用担心写动态绑定就丢掉了静态类样式。

数组语法则更适合类名本身是动态集合的场景。比如某个组件接收一个extraClasses数组作为 prop，你想把手里的多个类名依次追加到这个元素上：

<div :class="['base-class', extraClasses, isBig ? 'is-big' : '']">

数组里可以混合字符串、三元表达式和对象：

<div :class="['btn', { 'btn-primary': type === 'primary', 'btn-sm': size === 'sm' }]">

这是实际业务中最常见的组合：前缀是固定的组件基础类，中间是外部传入的追加类，最后是内部状态控制的修饰类。在我的项目里，这类写法大量出现在封装按钮、标签、弹窗这些通用组件时。

需要特别提醒的是：对象语法中，如果值为undefined或null，Vue 会把它当作不存在处理，不会渲染出空的class。这比自己去拼接字符串强太多，原生开发时每次都要小心处理"类名为空字符串"的情况，在 Vue 这里不用操心。

还有一个容易被忽视的场景：组件根元素上的class。当你使用自定义组件时，写在组件标签上的class会自动应用到组件的根元素上：

<MyButton class="extra-large" />

如果组件根元素已经有class，Vue 会做合并，不会覆盖。这为组件调用方提供了极强的灵活性——外部可以控制组件根元素的样式，而不需要侵入组件内部改逻辑。

2.2 style 绑定：动态样式的正确姿势

:style绑定同样支持对象语法和数组语法，但实际开发中，我建议能不写行内样式就别写。行内样式的优先级太高，难以用外部 CSS 覆盖，而且无法利用伪类、媒体查询等 CSS 能力。行内样式的最佳使用场景，是那些必须用 JavaScript 计算的动态值，典型的是进度条宽度、坐标位置、CSS 变量等。

对象语法绑定样式时，键名既可以用驼峰式fontSize，也可以用短横线分隔的font-size，Vue 都能识别：

<div :style="{ color: textColor, fontSize: fontSize + 'px' }">

这里有个经典错误：忘记加单位。很多人写fontSize: fontSize，如果fontSize传入的是数字16，渲染出来就是font-size: 16，浏览器会当成无效值。正确做法是拼上单位，或者在数据层存储时就带好单位字符串'16px'。

数组语法则可以将多个样式对象合并：

<div :style="[baseStyle, overrideStyle]">

后面的对象会覆盖前面的同名属性，类似于Object.assign。这种写法适合处理"基础样式 + 状态覆盖"的组合，但说实话，业务中真正用得上的场景不多，普通组件还是 CSS 变量方案更优雅。

Vue 还有一个非常实用的绑定方式：绑定 CSS 变量。你可以在:style中直接设置以--开头的自定义属性：

<div :style="{ '--theme-color': primaryColor }">

然后在这个元素及其子树中，任何 CSS 规则都能通过var(--theme-color)拿到这个值。这意味着你可以通过 JavaScript 动态注入主题变量，而不需要逐个元素绑定样式。我在做多主题切换功能时，就是用这招在根节点上切换--primary-color、--bg-color等变量，配合 CSS 的var()函数，整个应用的主题瞬间切换，比给每个组件传样式 prop 或者切换不同样式文件都高效得多。

注意：对象语法中的键如果是 CSS 变量形式，Vue 2 和 Vue 3 都支持，但在 TypeScript 场景下，需要给样式对象加类型断言，否则会出现类型报错。具体的解决方案，后面的常见问题章节我会展开说。

3. computed 计算属性：为什么说它是“缓存的数据管道”

3.1 computed 与 methods 的本质差异

computed是 Vue 初学者最容易困惑的点。很多人第一次接触时会想：我定义一个 methods 方法也能返回同样的值，为什么非要用 computed？原因就两个字：缓存。

每次渲染时，methods 里的函数都会被重新执行一次，哪怕依赖的响应式数据没发生变化。而 computed 会基于它的响应式依赖进行缓存：只有依赖的响应式数据变化时，它才会重新计算；依赖没变，多次访问直接返回上一次的计算结果。

用一个直观例子说明：

const count = ref(0) const doubleCount = computed(() => count.value * 2)

当你在一个渲染流程中多次访问doubleCount，它只会计算一次count.value * 2，后续访问直接命中缓存。而如果用 method：

function getDoubleCount() { return count.value * 2 }

每次渲染时，函数都会被调用，即使count没有变化。计算简单时性能差异微乎其微，但如果计算结果涉及大量循环、遍历或正则匹配，性能差距就非常明显了。在大型列表筛选场景中，用 computed 缓存筛选结果，比在模板里嵌套方法调用要高效得多。

还有一层更隐性的优势：computed 让"派生数据"的声明式意图更清晰。你不需要在代码中找出"这个方法到底在哪里被调用、被调用了几次"，computed 就像一张数据表：输入是响应式依赖，输出是结果，变化是自动且可预期的。

Vue 3 的 computed 底层是基于调度器和 effect 实现的，它会在首次访问时记录依赖，在依赖变更时标记为 dirty，下一次访问时重新求值。这个机制在 Option API 里演进多年，在 Composition API 中实现得更加纯粹。作为使用方，你只需要记住：computed 适合描述"由已知数据推导出的新状态"，它是纯函数式的，不应该在里面执行副作用操作。

3.2 getter/setter 与依赖追踪的深入理解

大多数场景下只用到 computed 的 getter，也就是只读逻辑。但某些场景下，你需要设置计算属性——最典型的是 v-model 绑定到 computed 上。比如你想让输入框的 v-model 绑定一个经过格式化的值：

const name = ref('') const formattedName = computed({ get() { return name.value.trim().toUpperCase() }, set(newValue) { name.value = newValue.toLowerCase() } })

然后在模板里：

<input v-model="formattedName" />

此时输入框显示的是格式化的值，用户输入时会通过 setter 把值反向写回原始变量。Vue 文档对 computed setter 的提示是"避免在 setter 里做复杂逻辑"，因为 setter 一般只是在响应式链路上做一个反向写入。如果 setter 里包含副作用或者依赖了复杂状态，很快就会变得难以调试。

依赖追踪是 computed 的核心机制。一个 computed 内部读取了多个响应式数据，Vue 会把这个 computed 注册为这些数据的依赖订阅者。任何一个被读取的数据发生变化，computed 都会被标记为需要重新求值。这个"自动追踪"的能力非常强大，但也容易让人忽略一个问题：依赖必须是在 computed 函数体内同步读取的。如果你在 computed 里发起异步请求，比如：

const data = computed(async () => { const res = await fetch('/api/data') return res.json() })

那你就踩了坑。async 函数返回的是一个 Promise，computed 计算得到的会是一个 Promise 对象，而不是你想要的请求结果，而且 Promise 的状态变化不是同步的，Vue 的响应式依赖追踪根本无法嗅探到异步加载完成的那一刻。要处理异步派生数据，正确做法是用 watch 配合 ref，或者使用一些专门的数据请求库，而不是在 computed 里做异步。

还有一个值得一提的细节：computed 中读取的依赖如果粒度太粗，会导致不必要的重计算。例如：

const bigObject = reactive({ a: 1, b: 2, list: [...] }) const result = computed(() => bigObject.list.filter(x => x.visible).length)

只要bigObject上的任何属性发生变化，computed 里读取到的list引用可能不变，但因为整个bigObject被打包成了响应式对象，访问任何一个属性都会建立computed与bigObject的依赖关系吗？这里要澄清一下：Vue 3 的依赖追踪是属性级别的，不是对象级别的。computed 里只读取了bigObject.list，那它依赖的就是list这个属性。如果bigObject.a变了，是不会触发这个 computed 重新计算的。但如果你在 computed 里同时读取了a和list，那这两个属性中任何一个变化时，都会导致重新计算。

因此，一个实用原则是：computed 内部只读取你真正关心的数据，不要顺手读取无关属性。这不是什么高深理论，很多性能问题就是这么一点一滴积累起来的。

4. watch 侦听器：什么时候该用它，什么时候不该用

4.1 watch 的三种典型场景

如果把 computed 比作"数据的计算管道"，那 watch 更像是"数据变化后的动作触发器"。它的定位从来不是派生新状态，而是响应变化、执行副作用。

第一种典型场景是：当某个数据变化时，需要发起异步请求。比如用户在筛选下拉框中选择了一个城市，你需要请求该城市的天气数据：

watch(selectedCity, (newCity, oldCity) => { fetchWeather(newCity) })

这种场景你用 computed 是没法完成的，因为 computed 必须是纯函数，不能让"获取数据"进入模板渲染流程。watch 在这里就是最合适的工具：数据变化，触发动作，动作的结果再更新其他响应式状态，再渲染。

第二种场景是：需要响应数据变化对非模板状态进行操作。比如某个参数变化时，你需要手动调用第三方图表库的更新方法，或者把数据同步到 localStorage：

watch(content, (newContent) => { localStorage.setItem('draft', newContent) })

这类操作无法通过模板自动完成，因为你操作的对象是模板之外的 DOM、存储或第三方实例，必须依赖 watch 在正确的时机介入。

第三种场景是：数据变化后需要做联动调整。比如某个联动下拉框：选择省份后，城市列表需要清空或重置。这种"一个数据变化影响另一个数据"的流程，watch 写起来非常直接。

与 computed 对比，最简洁的判断原则是：如果变化后你要写一个"动词"，比如请求、写入、清空、调用，那大概率用 watch；如果变化后只是要一个新的"值"，比如筛选后的列表、格式化后的文本，那用 computed 更简单、更纯净。

4.2 deep、immediate 以及异步处理

watch 有两个经常被忽略的配置项：deep和immediate。

deep用于深层监听对象内部属性的变化。默认情况下，watch 监听一个响应式对象时，只有对象本身被重新赋值才会触发，对象内部属性变动不会触发回调。但实际需求往往是：用户修改了对象的某个字段，就要触发保存。

const form = reactive({ name: '', age: 0 }) watch(form, (val) => { console.log('form changed', val) }, { deep: true })

这时修改form.name就会触发回调了。但要注意，deep: true的代价是递归遍历对象的每一层属性，对大型对象或深层嵌套结构来说，性能开销不小。我见过有人对一个大列表使用watch(list, handler, { deep: true })，每次修改列表里某个元素的字段，都会遍历整个列表，页面开始感到明显的卡顿。更好的做法是：明确监听具体路径：

watch(() => form.address.city, (newCity) => { updateCity(newCity) })

在 Composition API 里，watch 的第一个参数可以是一个 getter 函数，这样就能精确锁定你要监听的字段，大大减少不必要的触发。这是我在进阶之后最推荐的写法：能精确监听就不做深层全量监听。

immediate配置用于让回调在监听建立之初立即执行一次。典型场景是从路由参数初始化数据：

watch( () => route.params.id, (id) => { fetchDetail(id) }, { immediate: true } )

如果不写immediate: true，首次进入页面时回调不会执行，你得额外在生命周期里手动调用一次fetchDetail，代码就重复了。加上immediate之后，相当于"首次加载也视为一次参数变化"，逻辑一致且不重复。

关于异步处理，watch 本身并不支持 await 风格，但回调里你可以自由使用 async/await。更常见的模式是配合防抖函数：

let timer = null watch(searchKeyword, (val) => { clearTimeout(timer) timer = setTimeout(() => { fetchSearchResult(val) }, 300) })

这个防抖模式在做搜索输入时几乎是标配。我也不建议把这种逻辑直接塞进 watch 回调里，更好的做法是把它抽成一个可复用的函数，watch 只负责触发：

watch(searchKeyword, (val) => { debounce(() => fetchSearchResult(val), 300) })

在 Vue 3 中，官方推荐的watchEffect会自动追踪依赖并触发，但它更偏向"依赖变化即执行"的副作用场景，缺少了 watch 的明确数据源声明。我的经验是：能明确指定数据源时用 watch，因为可读性和可控性都更好。

还有一个常被误解的点：watch 中的 oldValue 在第一次触发时会是 undefined（如果不配 immediate），配合对象或数组引用时，oldValue 可能与新值指向同一个引用，因此无法直观看到"变化前的快照"。如果必须拿到变化前的完整数据副本，就需要手动做深拷贝，或者用 computed 维护一份历史快照，但大多数业务场景其实不需要这么较真。

5. 常见问题与排查技巧实录

5.1 computed 不更新的常见原因

computed 不更新的问题，在实战中碰到过好几种变形，最典型的是"依赖被劫持"。比如你在 computed 里读取了一个普通变量，而非响应式数据：

let count = 0 const doubleCount = computed(() => count * 2) // 永远不会更新

count 没有响应式包装，Vue 根本不知道它变了。解决方案是改为 ref 或 reactive 管理。这也是为什么很多初学者把业务数据散落在普通变量中，导致 Vue 的响应式系统形同虚设。

另一种情况是：computed 依赖的数据经过了一些"非响应式操作"。比如：

const arr = ref([1, 2, 3]) const result = computed(() => arr.value.filter(x => x > 1).length)

如果你在后面修改arr.value的方法没走响应式路径，比如直接改变数组长度arr.value.length = 0，在 Vue 3 的 proxy 拦截下其实也能被捕获，但如果你把 arr 替换成非响应式的普通数组副本并赋值给另一个变量，computed 依赖就断了。核心还是那条：computed 里读取的操作数，必须是响应式对象或其响应式属性。

还有一类场景，是 computed 依赖了组件外部的非 ref 数据。例如在一个普通模块文件中定义了一个 let 变量，被多个组件读取，即使值变了，组件里的 computed 也无法感知，因为模块变量不具备响应性。想要多组件共享状态，正确方案是使用 Vuex、Pinia，或者一个独立的ref导出。

处理这类问题时，我的排查套路是：打开 Vue Devtools 的组件树，观察相关数据是否是响应式对象（显示为Ref(${value})就对了），然后手动在控制台修改这个值，确认 computed 是否会变化；如果控制台能改、页面不更新，那大概率是组件引用了非响应式副本，或者 computed 函数体依赖到了尚未解构的变量。

5.2 watch 触发时机与重复监听问题

watch 触发时机的问题，最常见的困惑是"它到底什么时候执行"。默认情况下，watch 的回调会在依赖数据变化后异步执行，也就是说，同一个 tick 内多次修改同一数据，回调只会执行一次，收到的是最终值。这在多数场景下是好事，避免了重复请求，但如果你需要每一次变化的中间状态，就得使用{ flush: 'sync' }配置。我建议不到万不得已不要用 sync 模式，因为频繁同步执行回调会打乱 Vue 更新调度，也容易出现无限循环。

重复监听问题则可能出现在组件生命周期中。Options API 下，在mounted里写 watch 很容易导致组件销毁时没有正常解绑。而 Composition API 中，watch返回一个 stop 函数，组件卸载时 Vue 会自动调用它，但这个机制只对在 setup 顶层创建的 watch 生效。如果你在路由守卫或者事件回调中创建 watch，就得手动调用 stop：

const stopWatch = watch(source, handler) // 不想要了 stopWatch()

实际开发中我还遇到过一种隐蔽的重复监听：在 watch 回调中又创建了另一个 watch。每次触发都会新增一个监听器，导致回调越滚越多，最后页面性能急剧下降。这种问题排查起来很痛苦，因为控制台并不报错，只是页面越来越卡。我的经验法则是：一个组件内的 watch 应该在 setup 顶层统一创建，不要在回调、生命周期钩子里嵌套创建；如果确实需要动态监听，一定要配对调用 stop。

5.3 指令修饰符与样式绑定的隐蔽坑

指令修饰符这块，最隐蔽的坑出现在.stop和.self的混用上。有人以为在子元素上写了@click.stop，在父元素上就不需要处理了，但不能忽视的是，stop阻止的是当前事件流的继续传播，而self只对目标元素为自身时生效，两者的语义并不完全互补。处理卡片组件的点击穿透时，我最常用的组合是：内部交互区域用.stop，外层容器用.self，双保险。

.once修饰符也要注意语义：它在事件处理函数上只执行一次，但不是"只监听一次"。如果你在.once里修改了数据，数据变化引发的重新渲染并不会让这个元素恢复可点击状态；除非你把元素销毁重建，否则它就是真的只触发一次。这对"一次性上传按钮""首次访问提示浮层"这类场景非常适用，但你要是想做一个"点击三次才生效"的按钮，就别指望靠.once的部分语义来拼装。

样式绑定的隐蔽坑，集中在 CSS 变量和 TypeScript 上。在 Vue 3 + TypeScript 项目中，直接在模板中绑定--custom变量时，类型系统会报错，因为标准 CSSProperties 中并不包含自定义属性。常规的解决方案是，使用模块声明补齐：

type CSSVariables = { '--theme-color': string }

然后在模板中使用类型断言或转换为CSSVariables。如果你用的项目框架是 pinia 结合主题色切换，这个坑几乎必踩，提前给样式对象标好类型，能省下不少跟类型报错搏斗的时间。

还有一个样式组件的坑：scoped 样式下动态 class 不生效。scoped 样式是通过在元素上添加>const form = reactive({ name: '张三', age: 20 }) const { name } = form // name 变成一个普通字符串 watch(name, (val) => { ... }) // 监控一个普通字符串，永远不会触发！

你以为你在 watch 表单的名字字段，实际上你在 watch 一个原始字符串常量。正确写法是：

watch(() => form.name, (val) => { ... })

或者用toRefs把form.name转为 ref。每次遇到"代码明明写了 watch，结果就是不触发"的问题，我第一反应就是检查有没有解构响应式对象。这是 Composition API 最经典的误用，也是从 Options API 转过来的同学最容易犯的错误之一。

在实际项目里，把这四个主题放在一起融会贯通之后，再回头写模板和逻辑，你会明显发现自己开始有意识地选择"用工具"而不是"写代码兜底"：事件拦截用修饰符、动态样式用绑定、派生值用 computed、副作用用 watch。这套基本功打牢，后面的路由、状态管理、组件通信学起来都会顺畅很多。

我个人实操中的体会是：不要急着一口气把所有修饰符、所有绑定方式都用上，而是先理解它们解决什么问题，然后在真实项目里遇到对应场景时，再回头查、再用。比如你第一次写弹窗组件时用.self关闭遮罩，那一刻你会真正记住它；第一次做筛选列表用 computed 缓存时，你会感受到"为什么不卡了"的快乐；第一次在 watch 里 debounce 搜索请求时，你会理解副作用控制的价值。知识从"看过"变成"会用"，就是这么一层层叠加出来的。