5.24

vue的token存储

在前后端完全分离的情况下，Vue项目中实现token验证大致思路如下：

1、第一次登录的时候，前端调后端的登陆接口，发送用户名和密码

2、后端收到请求，验证用户名和密码，验证成功，就给前端返回一个token

3、前端拿到token，将token存储到localStorage和vuex中，并跳转路由页面

4、前端每次跳转路由，就判断 localStroage 中有无 token ，没有就跳转到登录页面，有则跳转到对应路由页面

5、每次调后端接口，都要在请求头中加token

6、后端判断请求头中有无token，有token，就拿到token并验证token，验证成功就返回数据，验证失败（例如：token过期）就返回401，请求头中没有token也返回401

7、如果前端拿到状态码为401，就清除token信息并跳转到登录页面

强缓存和协商缓存

强缓存

当浏览器去请求某个文件的时候，服务端就在respone header里面对该文件做了缓存配置。缓存的时间、缓存类型都由服务端控制,器，控制强制缓存的字段分别是Expires和Cache-Control，其中Cache-Control优先级⽐Expires⾼。

• 第一个属性: Expires表示有限期 在一定时间内访问该接口 都会用本地的数据

• 强缓存第二个属性字段 属于1.1的标准 建议使用1.1

  • Cache-Control 服务端参数：

  • max-age: 在多少秒内有效，是一个相对时间，这样比Expires具体的时间就更精确了。

  • s-maxage: 就是用于表示 cache 服务器上（比如 cache CDN，缓存代理服务器）的缓存的有效时间的，并只对 public 缓存有效。

  • no-cache：不使用本地强缓存。需要使用缓存协商。

  • no-store：直接禁止浏览器缓存数据，每次用户请求该资源，都会向服务器发送一个请求，每次都会下载完整的资源。

  • public：可以被所有的用户缓存，包括终端用户和中间代理服务器。

  • private：只能被终端用户的浏览器缓存，不允许中间缓存代理进行缓存，默认的。

1. cache-control: max-age=xxxx，public
客户端和代理服务器都可以缓存该资源；
客户端在xxx秒的有效期内，如果有请求该资源的需求的话就直接读取缓存,statu code:200 ，如果用户做了刷新操作，就向服务器发起http请求

2. cache-control: max-age=xxxx，private
只让客户端可以缓存该资源；代理服务器不缓存
客户端在xxx秒内直接读取缓存,statu code:200

3. cache-control: max-age=xxxx，immutable
客户端在xxx秒的有效期内，如果有请求该资源的需求的话就直接读取缓存,statu code:200 ，即使用户做了刷新操作，也不向服务器发起http请求

4. cache-control: no-cache
跳过设置强缓存，但是不妨碍设置协商缓存；一般如果你做了强缓存，只有在强缓存失效了才走协商缓存的，设置了no-cache就不会走强缓存了，每次请求都回询问服务端。

5. cache-control: no-store
不缓存，这个会让客户端、服务器都不缓存，也就没有所谓的强缓存、协商缓存了。

协商缓存 (前后端一起处理)

​ 上面说到的强缓存就是给资源设置个过期时间，客户端每次请求资源时都会看是否过期；只有在过期才会去询问服务器。所以，强缓存就是为了给客户端自给自足用的。而当某天，客户端请求该资源时发现其过期了，这是就会去请求服务器了，而这时候去请求服务器的这过程就可以设置协商缓存。这时候，协商缓存就是需要客户端和服务器两端进行交互的。

​ 首先设置Cache-Control：no-cache, 使客户端不走强缓存，再判断客户端请求是否有带ifModifiedSince字段，没有就设置Last-Modified字段，并返回资源文件。如果有就用fs.stat读取资源文件的修改时间，并进行对比，如果时间一样，则返回状态码304

前端代码定义一个时间

​ etag：是当服务器响应请求时返回当前资文件的一个唯一标识(由服务器生成) 每个文件有一个，改动文件了就变了，就是个文件hash，每个文件唯一，就像用webpack打包的时候，每个资源都会有这个东西，如： app.js打包后变为 app.c20abbde.js，加个唯一hash，也是为了解决缓存问题。

​ last-modified：文件的修改时间，精确到秒

也就是说，每次请求返回来 response header 中的 etag和 last-modified，在下次请求时在 request header 就把这两个带上，服务端把你带过来的标识进行对比，然后判断资源是否更改了，如果更改就直接返回新的资源，和更新对应的response header的标识etag、last-modified。如果资源没有变，那就不变etag、last-modified，这时候对客户端来说，每次请求都是要进行协商缓存了，即：

发请求-->看资源是否过期-->过期-->请求服务器-->服务器对比资源是否真的过期-->没过期-->返回304状态码-->客户端用缓存的老资源

当服务端发现资源真的过期的时候，会走如下流程：

发请求-->看资源是否过期-->过期-->请求服务器-->服务器对比资源是否真的过期-->过期-->返回200状态码-->客户端如第一次接收该资源一样，记下它的cache-control中的max-age、etag、last-modified等。

协商缓存步骤总结：

请求资源时，把用户本地该资源的 etag 同时带到服务端，服务端和最新资源做对比。
如果资源没更改，返回304，浏览器读取本地缓存。
如果资源有更改，返回200，返回最新的资源

https://note.youdao.com/ynoteshare/index.html?id=a288acfa3a25e88737639cad0df08cf9&type=notebook&_time=1653310426354#/68B5FE62532F4C00899ECA4ECF87560C

BFC

FBC：Block Formatting Context， 名为 "块级格式化上下文"

​ W3C官方解释为：BFC它决定了元素如何对其内容进行定位，以及与其它元素的关系和相互作用，当涉及到可视化布局时，Block Formatting Context提供了一个环境，HTML在这个环境中按照一定的规则进行布局。

​ 简单来说就是，BFC是一个完全独立的空间（布局环境），让空间里的子元素不会影响到外面的布局。它是一个独立的渲染区域，只有Block-level box参与， 它规定了内部的Block-level Box如何布局，并且与这个区域外部毫不相干。

BFC布局规则：

• BFC就是一个块级元素，块级元素会在垂直方向一个接一个的排列
• BFC就是页面中的一个隔离的独立容器，容器里的标签不会影响到外部标签（解决margin-top的穿透问题）
• 垂直方向的距离由margin决定， 属于同一个BFC的两个相邻的标签外边距会发生重叠
• 计算BFC的高度时，浮动元素也参与计算（清浮动，解决页面塌陷）
• BFC的区域不会和浮动的元素重叠（同级元素）=>可以利用这个特性设置左右两栏布局，左边float右边overflow:hidden;（形成BFC且只能用这个，其他的几种如果不设置宽度只能靠内容撑开）就可以实现右边区域自适应区域且不会和左边重叠。

​ BFC也属于普通流，设置为BFC的元素，相当于一种隔离了的元素，容器内部的元素不会在布局上影响外面的元素。

如何形成BFC？

1. HTML（文档流的内容怎么排布）
2. float属性不为none（脱离文档流的元素怎么排布）
3. position为absolute或fixed
4. display为inline-block, table-cell, table-caption, flex, inline-flex
5. overflow不为visible

map与forEach的区别

forEach 方法，是最基本的方法，就是遍历与循环，默认有3个传参：分别是遍历的数组

内容 item 、数组索引 index 、和当前遍历数组 Array

map 方法，基本用法与 forEach 一致，但是不同的，它会返回一个新的数组，所以在

callback需要有 return 值，如果没有，会返回 undefined

快速的让一个数组乱序

var arr = [1,2,3,4,5,6,7,8,9,10];
arr.sort(function(){
 return Math.random() - 0.5; })
console.log(arr);

css sprite是什么,有什么优缺点

• 概念：将多个小图片拼接到一个图片中。通过 background-position 和元素尺寸调节需要显示的背景图案。

• 优点：

  • 减少 HTTP 请求数，极大地提高页面加载速度
  • 增加图片信息重复度，提高压缩比，减少图片大小
  • 更换风格方便，只需在一张或几张图片上修改颜色或样式即可实现

• 缺点：

  • 图片合并麻烦
  • 维护麻烦，修改一个图片可能需要从新布局整个图片，样式