1. 命名规范
由历史原因及个人习惯引起的 DOM 结构、命名不统一，导致不同成员在维护同一页面时，效率低下，迭代、维护成本极高。
目录命名
- 项目文件夹：project
- 样式文件夹：css
- 脚本文件夹：js
- 样式类图片文件夹：img
- 产品类图片文件夹： upload
- 字体类文件夹： fonts2. 备注规范
每个页面写上对应的功能以及页面中的每个函数推荐写上该函数的作用
<!--
* @Descripttion: 页面/组件功能备注
* @version:
* @Author: zhangfan
* @Date: 2020-06-02 09:21:14
* @LastEditors: zhangfan
* @LastEditTime: 2021-07-01 11:41:46
-->/**
* @description: 函数功能及传参备注
* @param {*} urls
* @param {*} datas
*/3. 接口调用规范
在请求接口的时候要有错误的回调
推荐：
/**
* @description: 获取个人用户信息
*/
selectUserInfoById() {
const vm = this;
this.axios({
}) .then(function(response) {
}).catch(function(error) {
vm.handleAjaxError(error, "用户信息失败！")
})
},
/**
* @description: 处理ajax请求错误页面提示信息
*/
handleAjaxError(error, msg) {
let vm = this;
if (error && error.response) {
vm.$message.error({
type: "error",
message: error.response.data,
})
} else {
vm.$message.error({
type: "error",
message: msg,
})
}
},不推荐：
/**
* @description: 获取个人用户信息
*/
selectUserInfoById() {
const vm = this;
this.axios({
}) .then(function(response) {
}).catch(function(error) {
console.log("error submit!!");
})
},4. 代码管理规范
1，开发之前确认自己所在的分支是否在开发分支上，
2，上传代码之前必须先要拉取后传，遇到有代码冲突的情况要根据提交日志找到对应的开发人员沟通那些代码
是要保留的那些代码是废弃的，
3，修改一部分代码后要及时提交自己修改后的代码，不要出现长时间不提交代码或者大量修改后才提交代码，
4，提交完代码后要重新拉取一下确保自己的代码上传成功，
5，需求有重大变更的时候拉取新的分支做好代码备份，5. 页面样式规范
1，各页面样式相同的部分统一抽离成公共样式，每个页面写一套样式会为后期的样式维护和统一增加很大的困难
2，页面中有和公共样式有差异的在各自页面和组件中写样式覆盖公共样式不能轻易去修改公共样式，6. 组件使用规范
1，当页面重重复出现相同的功能的时候要抽离成公共组件，并且注册成全局组件，避免在每个页面都写一遍增加后期维护成本，推荐：
//注册全局公共组件确认框组件
import confirm from '@/components/confirm/index.js'
Vue.component("confirm", confirm)7. 离开页面时销毁定时器
<script>
export default {
name:'test',
data(){
return {
time: 60,
timer:null,
}
},
methods: {
// 60s倒计时
getLastTime: function(){
this.timer = setInterval(function () {
if(this.time == 0){
this.time = 60;
clearInterval(this.timer);
}else {
this.time = this.time - 1;
}
},1000)
},
},
destroyed(){
if(this.timer) { //如果定时器在运行则关闭
clearInterval(this.timer);
}
}
}
</script>8. 离开页面时销毁echarts
beforeDestroy() {
//销毁 echarts
this.myChart.clear();
this.myChart.dispose();
this.myChart = null;
}9. el-option选项过多的时候使用计算属性来生成
推荐：
<el-form-item label="日期" prop="salaryDay" >
<el-select placeholder="请选择" clearable filterable>
<el-option
v-for="(item,index) in daySelct"
:key="index"
:value="item.value"
:label="item.label"
></el-option>
</el-select>
</el-form-item>
computed: {
daySelct() {
var daySelct = [];
for (var i = 1; i <= 31; i++) {
var obj = {};
obj.value = i;
obj.label = i;
daySelct.push(obj);
}
return daySelct;
},
}10. v-for 遍历避免同时使用 v-if
v-for 比 v-if 优先级高，如果每一次都需要遍历整个数组，将会影响速度，尤其是当之需要渲染很小一部分的时候，必要情况下应该替换成 computed 属性。
推荐：
<ul>
<li
v-for="user in activeUsers"
:key="user.id">
{{ user.name }}
</li>
</ul>
computed: {
activeUsers: function () {
return this.users.filter(function (user) {
return user.isActive
})
}
}不推荐：
<ul>
<li
v-for="user in activeUsers"
v-if="user.isActive"
:key="user.id">
{{ user.name }}
</li>
</ul>11. 合理使用v-if 和 v-show
v-if 是 真正 的条件渲染，因为它会确保在切换过程中条件块内的事件监听器和子组件适当地被销毁和重建；
也是惰性的：如果在初始渲染时条件为假，则什么也不做——直到条件第一次变为真时，才会开始渲染条件块。
v-show 就简单得多， 不管初始条件是什么，元素总是会被渲染，
并且只是简单地基于 CSS 的 display 属性进行切换。
所以，v-if 适用于在运行时很少改变条件，不需要频繁切换条件的场景；
v-show 则适用于需要非常频繁切换条件的场景。12. 组件名为多个单词
我们开发过程中自定义的组件的名称需要为多个单词，这样做可以避免跟现有的以及未来的HTML元素相冲突，因为所有的 HTML 元素名称都是单个单词的。
推荐：
Vue.component('todo-item', {
// ...
})
export default {
name: 'TodoItem',
// ...
}不推荐：
Vue.component('todo', {
// ...
})
export default {
name: 'Todo',
// ...
}13. 组件的 data 必须是一个函数
当在组件中使用 data 属性的时候 (除了 new Vue 外的任何地方)，它的值必须是返回一个对象的函数。 因为如果直接是一个对象的话，子组件之间的属性值会互相影响。
推荐：
export default {
data () {
return {
foo: 'bar'
}
}
}不推荐：
export default {
data: {
foo: 'bar'
}
}14. Prop定义应该尽量详细
prop 的定义应该尽量详细，至少需要指定其类型。
推荐：
props: {
status: String
}
// 更好的做法！
props: {
status: {
type: String,
required: true,
validator: function (value) {
return [
'syncing',
'synced',
'version-conflict',
'error'
].indexOf(value) !== -1
}
}
}不推荐：
props: ['status']15. 为 v-for 设置键值
v-for 中总是有设置 key 值。在组件上总是必须用 key 配合 v-for，以便维护内部组件及其子树的状态。
推荐：
<ul>
<li
v-for="todo in todos"
:key="todo.id">
{{ todo.text }}
</li>
</ul>不推荐：
<ul>
<li v-for="todo in todos">
{{ todo.text }}
</li>
</ul>16. 在vue中 循环 尽量别用 index 作为 key 值
当 :key=“index” 时,其中一个元素发生了变化就可能导致所有的 key 值发生变化diff 算法是比较
同级之间的不同以 key 来进行关联,假如删除第一条数据以后所有的 index 都会发生改变那么
key 自然也会跟着改变所以 index 作为 key 值是不稳定的这种不稳定性有可能导致性能的浪费所以能
不用 index 作为 key 就别用17. 完整单词的组件名
组件名应该倾向于完整单词而不是缩写，编辑器中的自动补全已经让书写长命名的代价非常之低了，而其带来的明确性却是非常宝贵的。不常用的缩写尤其应该避免。
推荐：
components/
|- StudentDashboardSettings.vue
|- UserProfileOptions.vue不推荐：
components/
|- SdSettings.vue
|- UProfOpts.vue18. 多个特性元素的每个特性分行
在 JavaScript 中，用多行分隔对象的多个属性是很常见的最佳实践，因为这样更易读。
推荐：
<MyComponent
foo="a"
bar="b"
baz="c"
/>不推荐：
<MyComponent foo="a" bar="b" baz="c"/>19. 模板中简单的表达式
组件模板应该只包含简单的表达式，复杂的表达式则应该重构为计算属性或方法。复杂表达式会让你的模板变得不那么声明式。我们应该尽量描述应该出现的是什么，而非如何计算那个值。而且计算属性和方法使得代码可以重用。
推荐：
<!-- 在模板中 -->
{{ normalizedFullName }}
// 复杂表达式已经移入一个计算属性
computed: {
normalizedFullName: function () {
return this.fullName.split(' ').map(function (word) {
return word[0].toUpperCase() + word.slice(1)
}).join(' ')
}
}不推荐：
{{
fullName.split(' ').map(function (word) {
return word[0].toUpperCase() + word.slice(1)
}).join(' ')
}}20. 尽量不手动操作 DOM
21. 删除弃用代码
22. 复制页面 name值一定要改 不然页面缓存会有问题
