（一）跨域
（二）网络原理
5. indexDB与localStorage的区别⭐⭐⭐⭐⭐
- indexDB类似于数据类似于数据库的概念
- 异步存储，而且支持事务（提供error、abort和complete三个事件，不会出现失败后只改写了一部分的情况）
6. 服务端渲染和客户端渲染的区别，各自的优缺点？⭐⭐⭐⭐⭐
两者本质的区别是什么？ 客户端渲染和服务器端渲染的最重要的区别就是究竟是谁来完成html文件的完整拼接， 如果是在服务器端完成的，然后返回给客户端，就是服务器端渲染，而如果是前端做了更多的工作完成了html的拼接，则就是客户端渲染。 （1）服务端渲染（SSR Server Site Rendering）
- 有利于 SEO，首屏加载快，但是重复请求次数多，开发效率低，服务器压力大
- 渲染的时候返回的是完整的 html 格式
- 应用场景：页面需要被搜索到的 （2）客户端渲染(CSR Client Site Rendering)
- 不利于 SEO
目前比如百度、谷歌的爬虫对于SPA都是不认的，只是记录了一个页面，所以SEO很差。因为服务器端可能没有保存完整的html，而是前端通过js进行dom的拼接，那么爬虫无法爬取信息。 除非搜索引擎的seo可以增加对于JavaScript的爬取能力，这才能保证seo。 - 首屏加载慢，前后端分离开发，交互速度快、体验好
- 渲染的时候返回的是 json 数据格式，由浏览器完成渲染
- 应用场景：app 内部"嵌套"的 h5页面
8. Get和Post的区别⭐⭐⭐⭐⭐
| 区别 | get | post | 备注 |
|---|---|---|---|
| 冪等/不冪等（可缓存/不可缓存） | get请求是冪等的，所以请求的数据是可以缓存的 | 而post请求是不冪等的，查询对数据是有副作用的，是不可缓存的 | |
| 传参 | 参数是在url中的 | 参数是在请求体中 | 准确的说，get传参也可以放到body中，post传参也可以放到url中，只不过不推荐使用 |
| 安全性 | get较不安全 | post较为安全 | 准确的说两者都不安全，都是明文传输，在路过公网的时候，不管是url还是header还是body，都会被访问到，要想做到安全，就需要使用https |
| 参数长度 | get参数长度有限，是较小的 | post传参长度不受限制 | 准确来说，get在url传参的时候是很小的，是url有限制 |
| 发送数据 | --- | post传参发送两个请求包，一个是请求头，一个是请求体，请求头发送后服务器进行验证 要是验证通过的话就会给客户端发送一个100-continue的状态码，然后就会发送请求体 | |
| 字符编码 | get在url上传输的时候只允许ASCII编码 | --- | --- |
11. 浏览器请求并发有限制，如何处理？ ⭐⭐⭐⭐⭐
- 雪碧图，把请求的icon 合并成一张图片。
- 对 js和 css打包，资源合并
- 给资源做缓存
- 图片按需加载
- 给资源做 Hash，请求到不同域下（因为只有相同域才有并发限制）
12.讲一讲登录实现⭐⭐⭐⭐⭐
- 用户第一次登录的时候，后端生成该用户对应的token（唯一的并且有时效性的） 并返回给前端；
- 前端收到token之后存储在localStorage里面，并且记录用户的登录状态；
- 下次在发送用户相关的请求的时候需要携带上token；
- （后端需要设置
Access-control-allow-headers:token避免跨域问题），
- （后端需要设置
- 后端给每个用户相关的请求接口都加上token校验。
- 每次用户切换界面的时候都进行路由守卫的拦截验证，如果登录状态为true，则可以访问，如果为false，则不允许访问
13.什么是token?⭐⭐⭐⭐⭐
- 用户第一次登陆的时候，后端生成该用户对应的token（唯一并且有时效性），并存在数据库里（如果太多用户登陆的话会造成大量空间浪费，可以使用JWT），返回给前端。
- 前端把它存储在
localStorage中，下一次发送请求时（关于用户的请求，比如修改头像、密码或者自动登录）带上token并放在header中- 不配合后端的话会出现跨域问题，后端需要设置Access-control-allow-headers ： token）
- 后端给每个用户相关的接口都加上验证token操作，token正确则返回对应的数据，错误则报错处理。
- 当用户退出登录的时候删掉对应的token
14. 什么是JWT(Json Web Token)？ ⭐⭐⭐⭐⭐
（1）在没有 JWT 之前，验证客户端的方式就是通过 token,具体方式如下
- 用户输入账号密码以后，向服务端发起请求，
服务端生成token返回给客户端，
然后下次客户端请求数据的时候会携带着 token，
服务端收到之后，会与之前保存的 token进行验证，验证通过以后返回数据，验证不通过就不返回。 - 不过这种方式的扩展性很差，因为如果有上万个用户发起请求的话就需要保存上万条 token，这样对服务端而言无疑是压力巨大的 （2）后来出现了 JWT，这种方法可以把 token 保存在客户端
JWT 相当于把数据转换成 JSON 对象，这个特殊的 JSON 对象分为三部分：头部、负载、签名,他们之间分别用.区分开
| 标题 | |
|---|---|
| 头部（header） | 保存的是JWT 的元数据,表明所使用的 hash 算法，以 JSON 对象的方式存储，然后转换成 Base64URL 的格式 |
| 负载（payload） | 也是 JSON 对象格式，用来存放自己的数据 |
| 签名（Signature） | 确保消息的完整性 |
13.Data URL 和 Blob URL 的区别
| Data URL | Blob URL | |
|---|---|---|
| 格式 | 前缀为data:协议的 URL | 前缀为 blob:的 URL |
| 解释 | 不可变的二进制类文件对象 | |
| 生命周期 | 可以用在所有 URL 能用到的地方，链接不变，保存了可以以后使用 | 和创建它的窗口的 document 绑定 |
| 使用场景 | 多用来预览本地图片 | |
| 长度 | ||
- Blob是不透明的：能对它们进行直接操作的就只有获取它们的大小（以字节B为单位）、MIME类型以及将它们分割成更小的Blob。
- Blob URL 只能在当前应用内部使用,把Blob URL复制到浏览器的地址栏中,是无法获取数据的
- Blob 对象表示一个不可变、原始数据的类文件对象。
