前言这里是官方的 Vue 特有代码的风格指南。如果在工程中使用 Vue，为了回避错误、小纠结和反模式，该指南是份不错的参考。

规则归类

优先级 A：必要这些规则会帮你规避错误，所以学习并接受它们带来的全部代价吧。这里面可能存在例外，但应该非常少，且只有你同时精通 JavaScript 和 Vue 才可以这样做。

优先级 B：推荐这些规则能够在绝大多数工程中改善可读性和开发体验。即使你违反了，代码还是能照常运行，但例外应该尽可能少且有合理的理由。

优先级 C：谨慎使用有些 Vue 特性的存在是为了照顾极端情况或帮助老代码的平稳迁移。当被过度使用时，这些特性会让你的代码难于维护甚至变成 bug 的来源。这些规则是为了给有潜在风险的特性敲个警钟，并说明它们什么时候不应该使用以及为什么。

优先级 A 的规则：必要的 (规避错误)

组件名为多个单词 必要组件名应该始终是多个单词的，根组件App 以及 、 之类的 Vue 内置组件除外。这样做可以避免跟现有的以及未来的 HTML 元素相冲突，因为所有的 HTML 元素名称都是单个单词的。

反例

Vue.component('todo', {

// ...

})export default {

name: 'Todo',

// ...

}

好例子

Vue.component('todo-item', {

// ...

})export default {

name: 'TodoItem',

// ...

}

组件数据 必要组件的data 必须是一个函数。当在组件中使用 data 属性的时候 (除了 newVue 外的任何地方)，它的值必须是返回一个对象的函数。

详解当 data 的值是一个对象时，它会在这个组件的所有实例之间共享。想象一下，假如一个 TodoList 组件的数据是这样的：

data: {

listTitle: '',

todos: []

}我们可能希望重用这个组件，允许用户维护多个列表 (比如分为购物、心愿单、日常事务等)。这时就会产生问题。因为每个组件的实例都引用了相同的数据对象，更改其中一个列表的标题就会改变其它每一个列表的标题。增删改一个待办事项的时候也是如此。取而代之的是，我们希望每个组件实例都管理其自己的数据。为了做到这一点，每个实例必须生成一个独立的数据对象。在 JavaScript 中，在一个函数中返回这个对象就可以了：data: function () {

return {

listTitle: '',

todos: []

}

}

反例

Vue.component('some-comp', {

data: {

foo: 'bar'

}

})export default {

data: {

foo: 'bar'

}

}

好例子

Vue.component('some-comp', {

data: function () {

return {

foo: 'bar'

}

}

})// In a .vue file

export default {

data () {

return {

foo: 'bar'

}

}

}

// 在一个 Vue 的根实例上直接使用对象是可以的，

// 因为只存在一个这样的实例。

new Vue({

data: {

foo: 'bar'

}

})

Prop 定义 必要Prop 定义应该尽量详细。在你提交的代码中，prop 的定义应该尽量详细，至少需要指定其类型。

详解细致的 prop 定义有两个好处：它们写明了组件的 API，所以很容易看懂组件的用法；

在开发环境下，如果向一个组件提供格式不正确的 prop，Vue 将会告警，以帮助你捕获潜在的错误来源。

反例// 这样做只有开发原型系统时可以接受

props: ['status']

好例子

props: {

status: String

}// 更好的做法！

props: {

status: {

type: String,

required: true,

validator: function (value) {

return [

'syncing',

'synced',

'version-conflict',

'error'

].indexOf(value) !== -1

}

}

}

避免 v-if 和 v-for 用在一起 必要一般我们在两种常见的情况下会倾向于这样做：为了过滤一个列表中的项目 (比如 v-for='user in users'v-if='user.isActive')。在这种情形下，请将 users 替换为一个计算属性 (比如 activeUsers)，让其返回过滤后的列表。

为了避免渲染本应该被隐藏的列表 (比如 v-for='user in users'v-if='shouldShowUsers')。这种情形下，请将 v-if 移动至容器元素上 (比如 ul, ol)。

详解当 Vue 处理指令时， v-for 比 v-if 具有更高的优先级，所以这个模板：

• v-for='user in users'

  v-if='user.isActive'

  :key='user.id'

  >

  {{ user.name }}

将会经过如下运算：this.users.map(function (user) {

if (user.isActive) {

return user.name

}

})因此哪怕我们只渲染出一小部分用户的元素，也得在每次重渲染的时候遍历整个列表，不论活跃用户是否发生了变化。通过将其更换为在如下的一个计算属性上遍历：

computed: {

activeUsers: function () {

return this.users.filter(function (user) {

return user.isActive

})

}

}

• v-for='user in activeUsers'

  :key='user.id'

  >

  {{ user.name }}

我们将会获得如下好处：过滤后的列表只会在 users 数组发生相关变化时才被重新运算，过滤更高效。

使用 v-for='user in activeUsers' 之后，我们在渲染的时候只遍历活跃用户，渲染更高效。

解藕渲染层的逻辑，可维护性 (对逻辑的更改和扩展) 更强。为了获得同样的好处，我们也可以把：

• v-for='user in users'

  v-if='shouldShowUsers'

  :key='user.id'

  >

  {{ user.name }}

更新为：

• v-for='user in users'

  :key='user.id'

  >

  {{ user.name }}

通过将 v-if 移动到容器元素，我们不会再对列表中的每个用户检查 shouldShowUsers。取而代之的是，我们只检查它一次，且不会在 shouldShowUsers 为否的时候运算 v-for。

反例

• v-for='user in users'

  v-if='user.isActive'

  :key='user.id'

  >

  {{ user.name }}

• v-for='user in users'

  v-if='shouldShowUsers'

  :key='user.id'

  >

  {{ user.name }}

好例子

• v-for='user in activeUsers'

  :key='user.id'

  >

  {{ user.name }}

• v-for='user in users'

  :key='user.id'

  >

  {{ user.name }}

优先级 B 的规则：推荐 (增强可读性)

组件文件 推荐只要有能够拼接文件的构建系统，就把每个组件单独分成文件。当你需要编辑一个组件或查阅一个组件的用法时，可以更快速的找到它。

反例

Vue.component('TodoList', {

// ...

})

Vue.component('TodoItem', {

// ...

})

好例子components/

|- TodoList.js

|- TodoItem.js

components/

|- TodoList.vue

|- TodoItem.vue

组件名中的单词顺序 推荐组件名应该以高级别的 (通常是一般化描述的) 单词开头，以描述性的修饰词结尾。要注意在你的应用中所谓的“高级别”是跟语境有关的。比如对于一个带搜索表单的应用来说，它可能包含这样的组件：components/

|- ClearSearchButton.vue

|- ExcludeFromSearchInput.vue

|- LaunchOnStartupCheckbox.vue

|- RunSearchButton.vue

|- SearchInput.vue

|- TermsCheckbox.vue你可能注意到了，我们很难看出来哪些组件是针对搜索的。现在我们来根据规则给组件重新命名：

components/

|- SearchButtonClear.vue

|- SearchButtonRun.vue

|- SearchInputExcludeGlob.vue

|- SearchInputQuery.vue

|- SettingsCheckboxLaunchOnStartup.vue

|- SettingsCheckboxTerms.vue因为编辑器通常会按字母顺序组织文件，所以现在组件之间的重要关系一目了然。你可能想换成多级目录的方式，把所有的搜索组件放到“search”目录，把所有的设置组件放到“settings”目录。我们只推荐在非常大型 (如有 100+ 个组件) 的应用下才考虑这么做，因为：在多级目录间找来找去，要比在单个 components 目录下滚动查找要花费更多的精力。

存在组件重名 (比如存在多个 ButtonDelete 组件) 的时候在编辑器里更难快速定位。

让重构变得更难，因为为一个移动了的组件更新相关引用时，查找/替换通常并不高效。

反例components/

|- ClearSearchButton.vue

|- ExcludeFromSearchInput.vue

|- LaunchOnStartupCheckbox.vue

|- RunSearchButton.vue

|- SearchInput.vue

|- TermsCheckbox.vue

好例子

components/

|- SearchButtonClear.vue

|- SearchButtonRun.vue

|- SearchInputQuery.vue

|- SearchInputExcludeGlob.vue

|- SettingsCheckboxTerms.vue

|- SettingsCheckboxLaunchOnStartup.vue

完整单词的组件名 推荐组件名应该倾向于完整单词而不是缩写。编辑器中的自动补全已经让书写长命名的代价非常之低了，而其带来的明确性却是非常宝贵的。不常用的缩写尤其应该避免。

反例components/

|- SdSettings.vue

|- UProfOpts.vue

好例子

components/

|- StudentDashboardSettings.vue

|- UserProfileOptions.vue

Prop 名大小写 推荐在声明 prop 的时候，其命名应该始终使用 camelCase，而在模板和 JSX 中应该始终使用 kebab-case。我们单纯的遵循每个语言的约定。在 JavaScript 中更自然的是 camelCase。而在 HTML 中则是 kebab-case。

反例props: {

'greeting-text': String

}

好例子

props: {

greetingText: String

}

多个特性的元素 推荐多个特性的元素应该分多行撰写，每个特性一行。在 JavaScript 中，用多行分隔对象的多个属性是很常见的最佳实践，因为这样更易读。模板和 JSX 值得我们做相同的考虑。

反例

好例子

src='https://vuejs.org/images/logo.png'

alt='Vue Logo'

>

foo='a'

bar='b'

baz='c'

/>

简单的计算属性 推荐应该把复杂计算属性分割为尽可能多的更简单的属性。

详解更简单、命名得当的计算属性是这样的：易于测试当每个计算属性都包含一个非常简单且很少依赖的表达式时，撰写测试以确保其正确工作就会更加容易。

易于阅读简化计算属性要求你为每一个值都起一个描述性的名称，即便它不可复用。这使得其他开发者 (以及未来的你) 更容易专注在他们关心的代码上并搞清楚发生了什么。

更好的“拥抱变化”任何能够命名的值都可能用在视图上。举个例子，我们可能打算展示一个信息，告诉用户他们存了多少钱；也可能打算计算税费，但是可能会分开展现，而不是作为总价的一部分。小的、专注的计算属性减少了信息使用时的假设性限制，所以需求变更时也用不着那么多重构了。

反例computed: {

price: function () {

var basePrice = this.manufactureCost / (1 - this.profitMargin)

return (

basePrice -

basePrice * (this.discountPercent || 0)

)

}

}

好例子

computed: {

basePrice: function () {

return this.manufactureCost / (1 - this.profitMargin)

},

discount: function () {

return this.basePrice * (this.discountPercent || 0)

},

finalPrice: function () {

return this.basePrice - this.discount

}

}

优先级 C 的规则：谨慎使用 (有潜在危险的模式)

没有在 v-if/ v-else-if/ v-else 中使用 key 谨慎使用如果一组v-if + v-else 的元素类型相同，最好使用 key (比如两个