表现很差，问到了一些完全没复习的东西，估计是寄；还是和之前一样知识体系不够系统，表达不顺畅
面试官没开摄像头，沟通也不顺畅，体验不佳
cookies、session、token
HTTP 协议是一种无状态协议，即每次服务端接收到客户端的请求时，都是一个全新的请求，服务器并不知道客户端的历史请求记录；Session 和 Cookie 的主要目的就是为了弥补 HTTP 的无状态特性。
cookie
是什么： cookie是服务器发送到Web浏览器的一小块数据。浏览器得到发送过来的cookie后会进行存储，以后发送请求会携带上cookie。通常它被用来判断两个请求是否来自同一个浏览器，例如保持用户登录状态或者个性化设置。
分类： 如果没有设置到期时间就会视为会话cookie，如果设置了就是永久cookie，直到过期
HttpOnly的作用： 可以禁止Cookie被客户端脚本访问到，防止Cookie被窃取
作用域： 指定了Domin一般包含子域名，没有指定则只有当前主机。Path也会匹配子路由
session
是什么： 客户端请求服务端，服务端就会为这次请求开辟一块内存空间，存储一个Session对象，作用就是储存客户端在同一个会话中的操作记录。
Session的工作方式： 客户端第一次请求服务端，服务端就会为这次请求开辟一块Session空间，并生成一个sessionId，返回客户端并将sessionId存为会话cookie，这样以后发送请求就会带上这个cookie，服务端读取到这条信息后就能找到对应的Session对象。
缺点： 数据存储在特定服务器，如果做了负载均衡，请求被转发到别的服务器，这个session就没用了。
JSON Web Tooken
Json Web Token 的简称就是 JWT，通常可以称为 Json 令牌。它是用于安全的将信息作为 Json 对象进行传输的一种形式。JWT 中存储的信息是经过数字签名的，因此可以被信任和理解。
JWT 的原理是，服务器认证以后，生成一个 JSON 对象，发回给用户，就像下面这样。
{
"姓名": "张三",
"角色": "管理员",
"到期时间": "2018年7月1日0点0分"
}
服务器就不保存任何 session 数据了，也就是说，服务器变成无状态了，从而比较容易实现扩展。
JWT分为三个部分，Header（保存JWT元信息）、Payload（保存实际要传递的数据）、Signature（签名），前两个是用base64表示的json对象。
- JWT 不仅可以用于认证，也可以用于交换信息。有效使用 JWT，可以降低服务器查询数据库的次数。
- JWT 的最大缺点是，由于服务器不保存 session 状态，因此无法在使用过程中废止某个 token，或者更改 token 的权限。也就是说，一旦 JWT 签发了，在到期之前就会始终有效，除非服务器部署额外的逻辑。
- JWT 本身包含了认证信息，一旦泄露，任何人都可以获得该令牌的所有权限。为了减少盗用，JWT 的有效期应该设置得比较短。对于一些比较重要的权限，使用时应该再次对用户进行认证。
- 为了减少盗用，JWT 不应该使用 HTTP 协议明码传输，要使用 HTTPS 协议传输。
什么是HTTP？该如何表述
超文本传输协议，顾名思义就是用来传输超文本（也就是文字、图片、音视频以及其他多媒体文件）的一套规范。
请求报文： 起始行 + 头部 + 空行 + 实体
起始行
请求报文的起始行
GET /home HTTP/1.1
也就是方法 + 路径 + http版本。
响应报文的起始行
HTTP/1.1 200 OK
响应报文的起始行也叫做状态行。由http版本、状态码和原因三部分组成。
HTTP/2 当中废除了起始行的概念，将起始行中的请求方法、URI、状态码转换成了头字段，不过这些字段都有一个":"前缀，用来和其它请求头区分开。
头部
不管是请求头还是响应头，都有相当多的头部字段，用于传达信息
HTTP 缺点
无状态
所谓的优点和缺点还是要分场景来看的，对于 HTTP 而言，最具争议的地方在于它的无状态。
在需要长连接的场景中，需要保存大量的上下文信息，以免传输大量重复的信息，那么这时候无状态就是 http 的缺点了。
但与此同时，另外一些应用仅仅只是为了获取一些数据，不需要保存连接上下文信息，无状态反而减少了网络开销，成为了 http 的优点。
在Http1.1开始，默认长链接
明文传输
即协议里的报文(主要指的是头部)不使用二进制数据，而是文本形式。
这当然对于调试提供了便利，但同时也让 HTTP 的报文信息暴露给了外界，给攻击者也提供了便利。WIFI陷阱就是利用 HTTP 明文传输的缺点，诱导你连上热点，然后疯狂抓你所有的流量，从而拿到你的敏感信息。
HTTP2.0开始就使用二进制格式了
队头阻塞问题
当 http 开启长连接时，共用一个 TCP 连接，同一时刻只能处理一个请求，那么当前请求耗时过长的情况下，其它的请求只能处于阻塞状态，也就是著名的队头阻塞问题。
HTTP1.1解决队头阻塞： 对于一个域名允许分配多个长连接，那么相当于增加了任务队列，不至于一个队伍的任务阻塞其它所有任务，但是浏览器对一个域名能发起的长链接的数量有限，于是又出现了域名分片————一个域名下可以分出非常多的二级域名，而它们都指向同样的一台服务器，能够并发的长连接数更多了。这是一种治标不治本的方法
HTTP2.0解决队头阻塞： 原来Headers + Body的报文格式如今被拆分成了一个个二进制的帧，用Headers帧存放头部字段，Data帧存放请求体数据。分帧之后，服务器看到的不再是一个个完整的 HTTP 请求报文，而是一堆乱序的二进制帧。这些二进制帧不存在先后关系，因此也就不会排队等待，也就没有了 HTTP 的队头阻塞问题。(没太看懂) 参考文章：（建议精读）HTTP灵魂之问，巩固你的 HTTP 知识体系
http状态码
首屏加载慢（白屏）的原因，如何排查
产生原因：
由于使用React和Vue打包出的js和css文件太大，加载需要一定的时间，而js没有执行之前是不会有dom元素的，因此就出现了视觉上的白屏
解决办法：
-
视觉效果： 在HTML里加一个loading动画，当页面加载完成后消失。
-
路由懒加载： 使用路由懒加载，将文件拆分，只有在访问到对应路由时才会加载。在移动端，可以只加载可视区域的内容，剩下的等它快要进入可视区的时候加载。
-
CDN资源优化： 如果项目依赖了很多第三方包，可以在index.html里插入相应的链接，将这些包用CDN连接获取。打包的时候就不打包这些资源了
-
缓存：
- 接口缓存：一些用于获取数据的get请求使用接口缓存
- 静态数据缓存：长期不会更改的用强缓存，可能会更改的用ETag实现协商缓存。
-
终极办法——服务端渲染： 在服务端将渲染逻辑处理好，然后将处理好的HTML直接返回给前端展示，根本上解决白屏问题。
-
骨架屏： 使用骨架屏过度，在视觉上提高用户体验
如何隐藏一个元素
- display:none：隐藏元素，元素不占用文档流空间
- visibility:hidden：设置元素不可见，元素占用文档流空间
- opacity:0：透明度设置为0，元素正常渲染只是透明。也可以使用rgba(0,0,0,0)透明通道设置成透明
- 把元素定位到页面可视区域以外，使其看不到；用 overflow:hidden 隐藏超出的元素
- 把长宽设置成0，或者缩放到0%
- 使用旋转。90度就看不见了
在哪里会用到计算机网络，编译原理
git的fetch和pull
每个成员在完成自己的工作后，首先需要注意远程仓库的变化
方式一：拉取远程分支（git pull指令）
git pull指令可以理解为两个步骤：
- 获取远程分支
- 将获取的远程分支与本地分支合并
方式二：获取远程分支（git fetch指令）
git fetch指令的理解:
- 获取远端指定分支的最新版到本地（即在本地创建一个新分支内容为远端指定分支的最新版）
- 获取分支后就可以比较、查看远程分支的内容，随后若想push，可选择与获取的分支进行merge（合并）再push。
参考文章 面试题|git秘籍--多人协作冲突
