关于在使用接口获得数据时，要注意「接口调用次数过多」问题。前端接口调用次数过多，会导致后端收到的请求过多，而后端压力过大时是会“炸掉”的。
所以必须限制前端向后端请求的次数。这就要求我们在完成一个页面后，需要在「network」中去确认整个业务流程的接口请求次数是否合理、是否会造成大量请求的情况？
一个优化思路：在本次项目中的用户管理界面，其中每个子路由切换(如从用户的文章管理到沸点管理)时，都会去请求获取一次最新用户数据。这真的是有必要的吗？
仔细想来，非必要。因为用户数据基本只有用户自己有权限去修改，那么只需要在页面初始化时去请求一次数据并放入本地缓存就可以了。后续修改只需要修改这个本地数据，同时向修改接口发送请求即可。
和之前相比，之前每个页面初始化时会请求接口获取用户数据，那么现在只需要加一个if判断，判断本地存储的用户数据为空数据时才重新获取。
首先，要注意「空数据」：在未获得具体数据时，应该准备好可以渲染的「空数据」。
假设用户信息通过一个对象数据去渲染，那么其不应该仅仅是一个{}，只有一个{}在渲染时会出现“无法获取null的xxx属性"的问题。应该将具体数据也定义上：
//应该如是做，这样可以正确渲染为“空”，从而避免报错。
var data:{
id:‘‘,
username:‘‘
}
在发送请求时，要特别注意一个时间差(异步)问题。即获取返回数据需要一个时间，即如下操作：
需求：打印出返回的数据。
//定义一个数据，去接收返回数据，然后打印出来。
let returnData = null;
this.axios({
url: "http://api_devss.wanxikeji.cn/api/userAllInfo",
method: "post",
data: {
token: this.token,
},
}).then((res) => {
returnData = res.data;
console.log(returnData); //打印出的结果是正常的
});
console.log(returnData);
//打印的结果是null!因为在执行这一句的时候，返回数据还没有收取到。虽然返回数据很快，但是还是需要一定的时间，大概几十ms，而这几十ms，下边的代码已经被执行了。
//且这两次打印，是先打印下边的打印，然后打印上边的。这也说明了下边的代码是要先于返回操作中的代码执行的。
异步性要经常考虑：如果你发的第二个请求要以第一个请求的结果作为前置，那么你必须将第二个请求放在第一个请求的成功函数中。否则可能你第二个请求请求时，第一个请求还未完成。那么第二请求必然失败。
响应式变化最好在页面设置最初就设计好，至少遇到考虑到，预留出位置。否则后续调整非常麻烦，甚至要推倒重做。
vue项目想运行在IE上，需要进行一些插件：如babel-polyfidll，该插件会解决vuex的兼容问题。
一般建议兼容IE10以上即可，其他版本所占的市场份额已经极低了。
IE兼容所涉及的问题比较多，比如二者对一些标签的解释不同，一些CSS样式方面也会不通，IE也无法兼容ES6的语法等。
一般采取两个策略：「渐进增强」和「优雅降级」。我感觉「优雅降级」更佳。
优雅降级即针对高版本浏览器做开发，构建完善的功能，然后再针对低版本浏览器做兼容。因为毕竟高版本占市场份额最高，所以项目肯定要更契合高版本。
所以在做完页面之后，在IE10上运行测试即可。观察页面的不同之处以及测试功能的正常运行。
在CSS上，主要注意以下几个方面：①透明度②双边距③最小高度④图片的边框等
出弹窗和出页面的取舍：
主要参考依据还是数据量，弹窗的形式不适合大量数据量。
用户修改个人信息时，单条修改还是整体修改：
单条修改即每一条都有一个保存按键；整体修改即只有一个保存按键。
单条修改适合于移动端；整体修改适合于PC端。这是因为PC端具有大量的空间，且单挑数据修改保存更容易出BUG。
监听路由变化而出发方法：
监听路由变化而触发方法，最直观的做法就是通过watch侦听器去监听$route的变化，在{}中写上要执行的方法。
但是这 么做并不能应对所有情况产生的路由变化。
路由变化的两种可能方式有：
watch也会被重新渲染，所以虽然发生了路由改变，但是watch无法监听这次改变。router相关方法或<router-link>标签。该方法页面不会被重新渲染。即不会触发 「生命周期的钩子函数」。父页面的watch侦听器可以监听到这种变化。watch方法监听路由变化，无法应对通过在地址栏直接输入URL导致的路由变化，而可以监听在该页面中子路由的变化；生命周期的钩子函数则正相反，无法监听该页面中子路由变化，只可以监听地址栏输入URL导致的路由变化。所以两种情况还是要具体情况具体分析。
时间戳转换问题：
前后端进行时间数据的交互中，用时间戳这种”一般等价物“是非常具有优势的。方便前后端转换为其需要的数据类型。
vuex的使用范围问题：
vuex不应该被滥用。vuex主要用来解决不同组件之间的传值问题，如果不涉及不同组件间传值，其实没必要考虑用vuex。
既然是团队协作，那么就要充分意识到、发挥出团队协作的优势，明确并减少团队合作带来的不良影响。
「代码复用性」问题：在一个项目中，一定会存在多个页面中存在公共模块。
如在“掘金”网站中，沸点的显示与评论问题，既在“沸点”中显示，又在用户主页中显示。这两个板块如果由一个人做肯定是更好的，但是如果不是一个人做呢？那么两个模块的负责人就一定要去讨论这个地方该怎么做，是写成组件还是其他，是否可以完全复用，如果不能完全复用那么哪些可以复用等问题。去尽最大努力提高代码复用性。
最终所实现的效果应该是：模块出问题了，一个人去修改一处代码，全部使用的地方都生效。
如果最后两个人都做了一套，那真是十分低下的团队协作效率。
在使用git操作时，对于公共文件，如router、vuex，容易出错误。尽量去定义好每个人的区域，不要将自己的代码和别人的代码交叉写在一起。对于其他文件，也要做好管理。在views文件夹内要创建模块的子文件夹，将具体vue文件放在子文件夹内。views文件夹内不要有大量vue文件。
关于页面设计时要注意：
①响应式一开始就要设计好 ②文字兼容性处理
原文：https://www.cnblogs.com/huahongyi/p/14542486.html