1. cookie session 的用途和区别，以及有效期1、cookie数据存放在客户的浏览器上，session数据放在服务器上。
2、cookie不是很安全，别人可以分析存放在本地的COOKIE并进行COOKIE欺骗
考虑到安全应当使用session。
3、session会在一定时间内保存在服务器上。当访问增多，会比较占用你服务器的性能
考虑到减轻服务器性能方面，应当使用COOKIE。
4、单个cookie保存的数据不能超过4K，很多浏览器都限制一个站点最多保存20个cookie。
2. vue的数据绑定原理，mvvm与mvc的区别
MVVM：
m:model数据模型层 v:view视图层 vm:ViewModel
vue中采用的是mvvm模式，这是从mvc衍生过来的
MVVM让视图与viewmodel直接的关系特别的紧密，就是为了解决mvc反馈不及时的问题
图片说明一下：
说到MVVM就要说一下双向绑定和数据劫持的原理，
MVC：
m:model数据模型层 v:view视图层 c:controller控制器
原理：c层需要控制model层的数据在view层进行显示
MVC两种方式，图片说明：
总结：
mvvm与mvc最大的区别：
MVVM实现了view与model的自动同步，也就是model属性改变的时候， 我们不需要再自己手动操作dom元素去改变view的显示，而是改变属性后该属性对应的view层会自动改变。
不懂得可以复制链接查看：
/
3. storage 的区别 sessionStorage localStorage localStorage的生命周期是永久性的。假若使用localStorage存储数据，即使关闭浏览器，也不会让数据消失，除非主动的去删除数据，使用的方法如上所示。localStorage有length属性
sessionStorage 的生命周期是在浏览器关闭前。也就是说，在整个浏览器未关闭前，其数据一直都是存在的。sessionStorage也有length属性，其基本的判断和使用方法和localStorage的使用是一致的
4.v-model双向数据原理
有一个文本框 通过v-bind绑定了value属性 值为myname 是我们在vue实例中定义的属性
传统我们获取文本框值方法 可能通过getElementById找到文本框 然后获取其value属性
但是vue中直接通过v-bind绑定了value属性 所以不需要像之前那样获取值
所以在后面的按钮中获取name值 直接获取vue实例对象data里面的myname属性即可
【数据为尊 ----数据映射到浏览器 如果数据v-model后修改（肯定input）然后到数据在有数据映射到浏览器页面 ----映射关系统称】
5.keepAlive用过吗？什么作用？缓存路由组件
使用的是vue的一个组件，参考vue的官方文档
使用这个东西可以保证我们在切换组件的时候，原来显示的组件不被销毁
-----【保障组件的数据不会被切换路由而销毁数据】
keep-alive include="Home" Home是对应的组件对象的名字，不是路由的名字
router-view/router-view
/keep-alive
6.多维数组拍平数组拍平也称数组扁平化，就是将数组里面的数组打开，最后合并为一个数组
一红六种方法吧……
了解的请看：
7.跨域的原因 解决方案跨域是指一个域下的文档或脚本试图去请求另一个域下的资源，这里跨域是广义的。
这样就可以说同源策略----协议---端口---域名
原生的src和href可以解决跨域
代理可以解决
请求头也可以携带浏览器提示的也可以解决
一般都是后端解决跨域问题
【别的需要了解看下方链接】
8.uniApp兼容问题§ 如果你使用cli创建项目（即项目根目录是package.json），不管用什么ide，即便是用HBuilderX，切记cli项目的编译器是在项目下的，HBuilderX不管怎么升级都不会影响编译器版本。你需要手动npm update来升级编译器。以及如果你想要安装less、scss等预编译器，也需要自己npm安装在项目下，而不是在HBuilderX的插件管理里安装。
§ 如果你使用离线打包，请注意HBuilderX升级后，真机运行基座和云打包对应引擎跟随HBuilderX升级，而你的sdk需要手动升级。sdk的版本升级一般滞后HBuilderX正式版升级一两天。
§ 如果你使用自定义基座，之前制作的自定义基座是不会跟随HBuilderX升级的，升级HBuilderX后你应该重新制作新版自定义基座。
§ 如果你使用wgt升级，新版HBuilderX编译的wgt，运行到之前的runtime上，一定要先测试好，看有没有兼容性问题。如果有问题，就不要wgt升级，整包升级。
§ 考虑到向下兼容，uni-app编译器在升级为新的自定义组件模式后，同时保留了对老编译模式的向下兼容。
在HBuilderX alpha版中，App端一定会使用新编译器，不理会manifest配置。
在HBuilderX 正式版中，新创建的项目会使用新编译器，老项目不会强制使用，而是开发者自己在manifest里配置开启。
§ 如果你使用其他ide开发uni-app，会经常因为拼错单词而运行失败，因为经过webpack编译一道，很多错误反应的不够直观，排错时间很长，不如从开始就依赖有良好提示的HBuilderX，避免敲错单词。
§ 云打包的引擎版本说明
HBuilderX Alpha，只有1套云打包机，不管你的HBuilderX alpha版本多少，对应的打包机一定是最新的alpha版的客户端引擎。
HBuilderX正式版，有2套打包机，一个是最新正式版，一个是次新正式版。
中间的紧急更新版本没有独立打包机。
举个例子：
HBuilderX 有1.8.0、1.8.1、1.8.2、1.9.0、1.9.1这几个正式版。
那么当前可用的打包机有1.9.1和1.8.2这2台。（即每个大版本的最后一个版本）
除了这2个HBuilderX版本外，其他版本的云打包都指向最新的1.9.1版对应的打包机。（即只保留2个大版本的云打包机）
【详情请看】
