企业官网建设流程全解析

很多初学者在接触 Vue 的时候，第一个绕不过去的概念就是data。尤其是从 Vue 2 开始，官方文档里有个非常显眼的规则：组件里的data必须是一个函数，返回一个对象。而到了 Vue 3，这个规则依然延续。但为什么必须是函数？如果写成普通对象会怎样？data函数返回的数据在 Vue 内部到底经历了什么？这些问题如果只停留在“记住规则”的层面，后面写复杂组件的时候很容易踩坑。

这篇内容我会把data函数从前到后拆开讲透：从“为什么必须函数”这个根本问题，到响应式系统的初始化流程，再到实际开发中的数据设计、常见报错和排查思路。无论你是刚看完官方教程还没动手的新手，还是已经写了几个组件但偶尔被数据更新问题卡住的初中级开发者，这篇都值得花十分钟认真过一遍。

1. 为什么 Vue 组件里的data必须写成函数

1.1 从一次组件复用事故说起

先还原一个场景。假设你用 Vue 2 写了一个计数器组件，模板长这样：

<template> <div> <p>{{ count }}</p> <button @click="count++">加一</button> </div> </template>

如果这时候你把data写成了对象：

export default { data: { count: 0 } }

然后在父组件里同时用了两个这个计数器：

<template> <div> <Counter /> <Counter /> </div> </template>

点击第一个按钮，你会发现第二个按钮的count也跟着变了。这就是最经典的“组件数据串了”的问题。原因不复杂：对象是引用类型，两个组件实例的data指向了内存里的同一个对象。你改的其实不是“第一个组件的 count”，而是“这个共享对象上的 count”。两个实例都渲染同一个值，自然一起变。

这种事情在真实项目里不是“会不会遇到”的问题，而是“什么时候遇到”的问题。尤其是封装列表项组件、弹窗组件、选项卡组件这类复用量大的通用组件时，一旦有人偷懒把data写成对象，线上就会出现一堆诡异的数据互相污染 bug，而且极难排查。因为错误信息不会直接告诉你“你这个 data 写错了”，它只会体现为“页面数字不对”“别的组件被改了”这类间接现象。

1.2 引用共享的底层逻辑

要彻底理解这个问题，得先明确 JavaScript 的数据类型机制。

Number、String、Boolean这类基础类型，赋值和比较都是按“值”进行的。但Object（包括普通对象、数组、函数）是引用类型，变量里存的不是数据本身，而是数据在内存中的地址。当你写出：

const data = { count: 0 }

然后让两个组件实例都用这个data，相当于两个人共用一个记账本。A 在本子上写了“1”，B 翻开本子看到的也是“1”。两个人手里拿的不是两本内容相同的本子，而是同一个本子的两把钥匙。

data改成函数之后，每次创建组件实例都会执行一次这个函数：

data() { return { count: 0 } }

每一次执行都新建了一个独立的对象。第一个实例调用得到本子 A，第二个实例调用得到本子 B。A 怎么写都不会影响 B。这才是组件实例之间数据隔离的正确做法。

1.3 根实例的data为什么可以是对象

可能有人会问：那根实例呢？为什么new Vue({ data: { ... } })或者createApp({ data() { ... } })也没有强制要求函数？原因在于根实例在整个应用里只有一个，不存在“多个实例共享一份数据”的隐患，所以 Vue 允许根实例直接传对象。但为了保持写法和心智模型统一，尤雨溪团队在 Vue 3 中也建议一律使用函数形式。你去看官方文档和主流项目模板，基本全是用函数。既然规则已经统一，就不要再写对象形式了，免得某天把根组件的data复制到一个子组件里的时候踩中隐藏雷区。

2.data返回值的秘密：响应式系统的起点

2.1return之后发生了什么

data函数返回的只是一个普通对象吗？是，也不是。在源代码层面，Vue 拿到这个对象之后，会立刻把它交给响应式系统做处理。

Vue 2 中，这个函数内部会遍历对象的所有属性，用Object.defineProperty把每个属性转换成 getter/setter 形式。这个过程发生在组件实例初始化阶段，具体是在initState里的initData函数中。还有一个性能相关的小细节：Vue 2 在初始化data之前，会先检查data和props、methods有没有重名。重名会直接报错，因为实例上this.xxx只有一个，命名冲突会让 Vue 不知道该给你哪个。

Vue 3 中，return出来的对象会被传给reactive函数，利用Proxy对整个对象做代理。因为Proxy是拦截整个对象的读写操作，所以 Vue 3 在响应式转换的性能和删减属性上都比 Vue 2 更优。

无论哪个版本，核心流程都是一样的：

1. 执行data函数，拿到原始数据对象。
2. 遍历（Vue 2）或代理（Vue 3）这个对象，建立响应式追踪。
3. 把处理后的响应式对象挂到组件实例上，让你能通过this.xxx访问。
4. 模板编译阶段会建立渲染函数对这个对象的依赖，数据变化时触发重新渲染。

2.2 依赖收集和触发更新的完整链路

很多人只听说过“响应式”，但不知道数据变化后视图怎么知道要更新。简单说，Vue 的响应式系统是典型的“发布-订阅”模式。

拿 Vue 3 举例。模板里写了{{ count }}，首次渲染时渲染函数会访问state.count，这一步会触发Proxy的get拦截。在拦截逻辑里，当前正在执行的副作用函数（也就是渲染函数）会被登记为这个属性的依赖。这个过程叫“依赖收集”。

当你修改state.count = 1，触发Proxy的set拦截。拦截逻辑里会找到所有依赖这个属性的副作用函数，然后通知它们重新执行。这个过程叫“派发更新”。重新执行渲染函数，拿到新的值，然后更新真实的 DOM。

理解这条链路之后，你就能明白为什么data必须初始化时就声明好所有属性。因为 Vue 3 的Proxy虽然可以代理对象，但get拦截只对“当前这个 key”的读取做依赖收集。如果你在初始化时没有count这个属性，后面直接this.count = 1，那么第一次渲染时就不会有count的依赖被收集，后续更新自然无从触发。

2.3 一个容易忽略的初始化时机问题

data函数的执行时机是在props初始化之后、computed和methods初始化之前。实际影响就是：在data函数体内，你能通过this访问到props，但访问不到computed。所以如果你看到类似这样的写法：

props: { initialCount: Number }, data() { return { count: this.initialCount || 0 } }

这是完全合法且常见的。但如果你想在data里引用一个computed属性，就会得到undefined。遇到这种需求，正确做法是在watch或created生命周期里处理，而不是硬在data里依赖computed。

3. 日常开发中data函数的设计与取舍

3.1data里的数据类型选择

data函数返回的对象里可以放任意类型的数据：基础类型、对象、数组、甚至函数。但这里有几个实际开发中的经验规则。

第一，能用基础类型表达的数据，不要套对象。比如你只需要一个开关状态，直接isVisible: false就好，不要写成status: { visible: false }。属性嵌套层级越深，Vue 递归转换响应式的开销越大，而且访问代码也更啰嗦。

第二，数组元素尽量是结构固定的对象。常见的坑是：从后端接口拿到的数据塞进data的数组之后，后续要给每个条目动态添加字段，比如“选中状态”。如果你在初始化时没有这个字段，后面this.list[index].selected = true这种写法在 Vue 2 里是非响应式的，界面不会更新。解决办法有两个：一是提前在数据进入data时就统一补好字段默认值；二是用this.$set（Vue 2）或重新赋值整个数组（Vue 3）。但从根上避免，最好在把接口数据赋给data之前，做一次map转换，把结构定死。

第三，data里千万不要放“需要通过this才能拿到的东西”。有一个经典错误：

data() { return { foo: this.bar // bar 在 methods 里定义 } }

data初始化时methods还没挂载完，this.bar是undefined。如果必须用某个方法的结果作为初始值，方法本身得是纯函数，或者放到created里再赋值。

3.2 层级深度的控制

在设计data的数据结构时，我见过不少人习惯把“整棵树”都扔进来。比如一个表单数据，直接：

data() { return { form: { user: { profile: { nickname: '', avatar: '' }, settings: { theme: 'light', notify: true } } } } }

这种深层嵌套在短期写起来很爽，但后面维护是灾难。改一个字段要写this.form.user.profile.nickname = 'xxx'，校验的时候要一层一层判空，watch的时候如果不写deep: true还监听不到变化。而deep: true又会让每次赋值都递归遍历整个对象，性能开销明显。

我个人的做法是：超过两层的结构，考虑拆成多个平级字段或者拆到子组件里，用props传入。例如上面的场景，可以把user和settings拆开：

data() { return { userProfile: { nickname: '', avatar: '' }, userSettings: { theme: 'light', notify: true } } }

这样每个字段的访问路径短，响应式追踪的粒度也更细，改动一个字段不会触发整棵树重新收集依赖。

3.3data和computed的分工

data是“源数据”，computed是“派生数据”。实际开发中很多人用混，把所有东西都塞进data，然后在模板里做各种复杂表达式，或者每次渲染都重新计算结果。

一个合理的分工逻辑是：

• 从接口拿到的、由用户交互产生的、需要在事件处理中修改的，放data。
• 由data里的数据演算而来、不需要手动修改的，放computed。

举一个常见的例子：购物车。商品列表和数量是源数据，放在data里；总价、总数量、是否满减，这些都是根据源数据算出来的结果，放computed。如果你把它们也放进data，那就需要在每次修改商品数量时手动同步一次总价。一旦某个地方漏了同步，展示就出错。

data() { return { cart: [], } }, computed: { totalPrice() { return this.cart.reduce((sum, item) => sum + item.price * item.quantity, 0) } }

这是data和computed协同的典型模式，也是面试里常考的“派生状态不要放 data”的核心体现。

3.4data的初始状态是否应该“空白”

有一种设计问题是：初始化data时，字段是保留默认值还是干脆不写？

我的建议是：所有需要响应式追踪的属性，在初始化时就写好默认值，哪怕默认值是空字符串、空数组、false。原因前文说过，缺失的属性不会被依赖收集。并且从代码可读性角度，一眼看到data就能知道这个组件有哪些状态，相当于一份“状态清单”。

但也不建议为了“完整”把所有无关字段都写进去。比如后端接口可能会返回“未来十年可能都不会用到的字段”，那就不要为了完整而放进data。响应式系统要为每个额外属性建立追踪，浪费性能不说，还会让代码看起来很臃肿。保持“用到什么就声明什么，删掉的就移除”这个习惯就好。

4.data相关的经典问题与排查思路

4.1 经典问题一：对象新增属性为什么不更新

Vue 2 时代，这是提问频率最高的问题。场景是：

data() { return { user: { name: '张三' } } }, methods: { addAge() { this.user.age = 18 // 页面上的 age 不显示 } }

因为 Vue 2 的响应式转换用的是Object.defineProperty，它是在初始化时就给已存在的属性绑定 getter/setter。属性根本不存在，后面的赋值就只是“非响应式地往对象上挂了一个普通属性”，视图自然不知道。

Vue 3 用Proxy之后，这个特定问题迎刃而解，因为Proxy拦截整个对象的操作，新增属性也可以被代理。但要注意：reactive返回的代理对象，新增属性是响应式的；但如果你用“解构赋值”把parse出来的值赋给一个普通变量，那就又是另一回事了：

let { user } = toRefs(state)

想同时保有响应式，得用toRefs转换。如果习惯性地直接const user = state.user解构，那user只是个普通对象，改它不会更新视图。这类问题经常出现在从store里取值时，很多人解构出来就丢了响应式。

4.2 经典问题二：数组下标赋值失效

Vue 2 还有一个特殊场景：数组通过下标直接赋值也不会触发更新。

this.list[0] = { name: '李四' } // 视图不更新

原因同样是Object.defineProperty的局限——Vue 2 对数组的检测是拦截push、pop、shift、unshift、splice、sort、reverse这七个方法，以及通过改写数组的原型方法实现的。直接按下标赋值不属于这七个方法之一，Vue 2 监听不到。修正方案有两种：使用this.$set(this.list, 0, newItem)，或者直接替换整个数组：

this.list.splice(0, 1, { name: '李四' })

Vue 3 的Proxy可以拦截数组的下标赋值，所以这个问题在 Vue 3 中不存在了。但如果你在项目里用Object.freeze冻结了数组，那不管哪个版本，改动都不会触发响应。因为冻结对象的属性被标记为不可配置，Proxy在设置值时会直接返回false。

4.3 经典问题三：data里放了函数对象

有人会问，data里能不能放函数？能。但必须是普通的、不依赖组件实例的函数，类似纯函数工具集。实际开发中确实有这种需求，比如组件内需要一个根据某些数据动态生成配置的映射表：

data() { return { statusMap: { 1: '待处理', 2: '处理中', 3: '已完成' }, // 纯函数，把状态码转成对应文案 getStatusText(code) { return this.statusMap[code] || '未知' } } }

这种情况把函数放methods里其实是更规范的选择。data里放函数，每次组件实例创建都会重新创建这个函数对象，白费一次内存分配。如果函数逻辑不依赖组件实例，你完全可以在组件外部定义常量函数，然后data里通过引用方式挂载：

const STATUS_TEXT_MAP = { 1: '待处理', 2: '处理中', 3: '已完成' } const getStatusText = (code) => STATUS_TEXT_MAP[code] || '未知' export default { data() { return { getStatusText } } }

这样，函数只定义一次，所有实例都复用同一个函数引用，性能和可测试性都更好。这个习惯在项目规模变大之后会非常受益。

4.4 一起追一个诡异的 bug：日志正常、视图不动

下面分享一个我实际遇到过的排查案例。现象是：点击按钮后，控制台打印this.list能看到数据已经变了，但页面列表没有反应。

第一次排查思路是看数据是否真正触发了响应式更新。在methods里打日志，打印的是this.list，因为是响应式代理对象，打出来会显示当前值，不能证明“这个赋值动作触发了派发更新”。所以我就换了一种方式：在模板渲染的列表项上临时加一个:key，把它设为列表长度，看看列表长度变了没。结果是长度变了，说明list的响应式链路正常。

继续排查，查看列表项绑定的字段。这时候注意到：模板里渲染的是item.title，但接口数据里字段叫name。因为数据结构不匹配，模板读到的始终是undefined，所以无论我怎么改item.name，界面都不可能显示。

这种“数据在变、视图不动”的问题，绝大多数不是响应式系统的问题，而是你改的数据和模板读的数据根本不是同一个字段。排查技巧就是：在模板里用调试表达式临时把整个 item 输出到页面，比如{{ item }}，一眼就能看到真实结构。这一步看起来很基础，但能帮你过滤掉一半以上的“响应式失效”问题。

4.5data初始化顺序导致的手写$set遗漏

还有一类问题，是你根本不知道字段是什么时候丢的。比如某个组件里通过接口动态渲染表单，字段结构是后端返回的，你可能基于接口数据结构直接给data赋值，但动态追加的一些 UI 状态字段（比如是否展开）并没有在初始化时声明。Vue 2 里这种字段的更新必须靠$set。我有一次在一个十分复杂的嵌套组件里，往form.list[i].children[j].expand赋值，忘了$set，排查了整整一个下午。

后来我学乖了。任何从接口拿来的数据，在进data之前，都先做一次“字段补齐”处理。用默认工厂函数把可能需要的字段都预置好：

const normalizeItem = (raw) => ({ id: raw.id, title: raw.title || '', expand: false, // 预置 UI 状态 selected: false, // 预置 UI 状态 children: (raw.children || []).map(normalizeItem) })

这种思想在 Vue 2 和 Vue 3 里都适用。等到字段本来就存在，后续更新就不会被响应式系统的边界条件坑到。

5. 从data到 Vue 3 的迁移注意事项

5.1data在 Options API 和 Composition API 中的位置差异

Vue 3 同时支持 Options API 和 Composition API。Options API 里data的写法和 Vue 2 基本一致，区别只是底层响应式实现换了。Composition API 里没有data这个概念了，你直接使用ref或reactive来创建响应式数据：

import { ref, reactive } from 'vue' setup() { const count = ref(0) const form = reactive({ name: '', age: 0 }) return { count, form } }

很多从 Vue 2 过来的人会纠结：到底用ref还是reactive？我的习惯是：单个基础类型或者“一整个我想要通过.value访问的值”用ref；结构相对固定的对象、数组，用reactive。但两者都能实现响应式，核心差别在于ref会更强调“拿到的是包裹后的引用”，而reactive则是直接给原对象加代理。

5.2reactive的防坑提醒

如果你在 Vue 3 的setup里用了reactive，有一个和 Vue 2data类似的注意事项：reactive返回的是原始对象的Proxy，但解构出来的属性会丢失响应式，除非你用toRefs包装一下：

setup() { const state = reactive({ count: 0, name: '张三' }) return { ...toRefs(state) } }

这样在模板里可以直接用count和name，且保持响应式。不过在实际开发中，如果不是特殊需求，直接返回整个state对象，然后在模板里写state.count反而最不容易出问题。

5.3 一个从 Vue 2 迁 Vue 3 时的真实案例

之前迁移一个老项目，遇到一个很典型的问题。有一个全局列表组件，data里声明了一个Map类型的字段用来存选中状态：

data() { return { selectedMap: new Map() } }

在 Vue 2 里，Map本身不是响应式的，需要手动this.selectedMap.set(id, true)然后this.$forceUpdate()来强制刷新。Vue 2 的响应式系统对Map、Set这类新数据结构支持非常有限。

Vue 3 的reactive对Map、Set做了专门的代理处理，提供了完整的响应式支持。理论上可以像操作普通对象一样愉快地map.set()然后视图自动更新。但实际迁移的时候发现，如果数据在进入reactive之后再用new Map()重新赋值，得到的仍然是一个非响应式的普通Map，赋值后响应式代理会被替换掉。正确做法是始终保持同一个引用，只更新内部内容：

const state = reactive({ selectedMap: new Map() }) // 正确：在同一个 map 里操作 state.selectedMap.set(id, true) // 错误：重新赋值，丢失响应式 state.selectedMap = new Map()

这类细节官方文档没有写得很细致，得踩过一次坑才有切身体会。总的来说，Vue 3 的响应式能力比 Vue 2 强很多，但如果你习惯于“整个对象重新赋值”的写法，切到 Vue 3 后反而比以前更容易出问题。因为以前是到处都不响应、你早有防备；现在是有的响应、有的不响应，一不小心就忽略边界条件。

6. 个人实操中的一些小技巧

回到data函数本身，最后分享几个我平时的小习惯，算是给新手的一些直接可用的建议。

第一，写data函数时，永远保持返回对象字段顺序清晰。把基础类型字段放前面，数组字段放中间，嵌套对象放最后，可读性会好很多。

第二，项目里如果有“表单重置”需求，直接把初始数据抽成一个工厂函数，然后data里调用它：

const createDefaultForm = () => ({ name: '', age: 0, tags: [], address: { province: '', city: '' } }) export default { data() { return { form: createDefaultForm() } }, methods: { resetForm() { Object.assign(this.form, createDefaultForm()) } } }

重置时再调用一次工厂函数，保证每次重置都拿到全新的、结构完整的初始状态，不会残留上一次编辑的数据。这个小模式能保护你少写很多this.form.xxx = ''这类重复代码。

第三，如果你在做代码审查，看到某个组件的data有超过五个独立字段，先考虑这是不是一个“状态过多”的信号。该拆组件就拆组件，该转computed就转computed，该提升到全局 store 就提升到 store。data的整洁程度，往往直接反映一个组件的复杂度和可维护性。

data函数是整个组件数据体系的基石，虽然代码就两行，但它和响应式系统、生命周期、组件设计都深度耦合。把这个点吃透，后面学computed、watch、状态管理才会真正顺畅。