**在Web开发中，Cookie是一种存储在客户端浏览器上的小型文本文件。它们被用于存储用户信息、用户偏好设置以及在网站之间传递数据。在JavaScript中，通过document.cookie属性来操作Cookie。**



- 不同浏览器之间cookie不共享
- cookie只会种在requestUrl中
- 发起请求时，会带上当前浏览器下该requestUrl下的所有cookie
- 谷歌安全策略，当前域名和requestUrl域名不一致时，newwork下的requset请求头会显示Provisional headers are shown，火狐当域名和requestUrl域名不一致时，可以看到完整的request信息。

## domain
### 设置domain的情况
当我们的网站向一个域名发起请求时，如果请求返回的response信息里面携带set-cookie，就会向该浏览器（如谷歌，火狐）下的该requestUrl种下一个cookie，无法跨域向其它域种下cookie。domain的作用是指定该cookie在当前requestUrl下的作用域，如domain：.myhqq.com,则这个cookie在三级域名下的www或者又是在qqq下都可以访问到该cookie。如果domain设置为requestUrl之外的地址，则此cookie不会被设置成功。

### 不设置domain的情况
默认在当前requestUrl种下cookie，如发起的请求requestUrl：www.myhqq.com，则在当前requestUrl种下cookie，此时qqq.myhqq.com下无法使用该cookie。


##  path
path：为当前requestUrl下cookie的使用路径，当path为错误时，会自动定位到第一目录下，如设定path:cs，requsetUrl:http://www.myhqq.com/weapp/get，此时path错误，被默认设为/weapp，
子路径可以访问父路径cookie，父路径无权访问子路径cookie。

## 客户端withCredentials
客户端withCredentials: true  设置为true时，
- 允许跨域设置set-Cookie 
- 并且允许发送请求的时候带上cookie 
- 如果为false时则respone返回的set-Cookie不会生效且请求时不会带上cookie

withCredentials不设置时，不允许跨域设置并且携带cookie。
同域下不设置withCredentials时，可以设置cookie并且请求时携带本域cookie

服务端需配置  Access-Control-Allow-Credentials:true（同意接收浏览器的cookie）

cookie 小知识

**在前端开发中，CSS渐进增强和优雅降级是两种重要的设计理念，用于确保网站或应用程序在各种设备和浏览器上都能够正常运行。这两种方法的目的是为了提高用户体验和可访问性，并尽可能地降低浏览器兼容性问题的影响。**




## 名词解释
渐进增强（Progressive Enhancement）：一开始就针对低版本浏览器进行构建页面，完成基本的功能，然后再针对高级浏览器进行效果、交互、追加功能达到更好的体验。

优雅降级（Graceful Degradation）：一开始就构建站点的完整功能，然后针对浏览器测试和修复。比如一开始使用 CSS3 的特性构建了一个应用，然后逐步针对各大浏览器进行 hack 使其可以在低版本浏览器上正常浏览。

其实渐进增强和优雅降级并非什么新概念，只是旧的概念换了一个新的说法。在传统软件开发中，经常会提到向上兼容和向下兼容的概念。渐进增强相当于向上兼容，而优雅降级相当于向下兼容。向下兼容指的是高版本支持低版本的或者说后期开发的版本支持和兼容早期开发的版本，向上兼容的很少。大多数软件都是向下兼容的，比如说Office2010能打开Office2007，Office2006，Office2005，Office2003等建的word文件，但是用Office2003就不能打开用Office2007，Office2010等建的word文件！

## 二者区别
优雅降级和渐进增强只是看待同种事物的两种观点。优雅降级和渐进增强都关注于同一网站在不同设备里不同浏览器下的表现程度。关键的区别则在于它们各自关注于何处，以及这种关注如何影响工作的流程。

优雅降级观点认为应该针对那些最高级、最完善的浏览器来设计网站。而将那些被认为“过时”或有功能缺失的浏览器下的测试工作安排在开发周期的最后阶段，并把测试对象限定为主流浏览器（如 IE、Mozilla 等）的前一个版本。在这种设计范例下，旧版的浏览器被认为仅能提供“简陋却无妨 (poor, but passable)” 的浏览体验。你可以做一些小的调整来适应某个特定的浏览器。但由于它们并非我们所关注的焦点，因此除了修复较大的错误之外，其它的差异将被直接忽略。

渐进增强观点则认为应关注于内容本身。请注意其中的差别：我甚至连“浏览器”三个字都没提。内容是我们建立网站的诱因。有的网站展示它，有的则收集它，有的寻求，有的操作，还有的网站甚至会包含以上的种种，但相同点是它们全都涉及到内容。这使得渐进增强成为一种更为合理的设计范例。这也是它立即被 Yahoo! 所采纳并用以构建其“分级式浏览器支持 (Graded Browser Support)”策略的原因所在。

## 案例分析
看如下这两段代码的书写顺序，表示了我们开发的着重点。
```css
.transition { /*渐进增强写法*/
  -webkit-transition: all .5s;
     -moz-transition: all .5s;
       -o-transition: all .5s;
          transition: all .5s;
}
.transition { /*优雅降级写法*/
          transition: all .5s;
       -o-transition: all .5s;
     -moz-transition: all .5s;
  -webkit-transition: all .5s;
}
```
前缀CSS3（-webkit-* / -moz-* / -o-*）和正常CSS3在浏览器中的支持情况是这样的：

很久以前：浏览器前缀CSS3和正常CSS3都不支持；
不久之前：浏览器只支持前缀CSS3，不支持正常CSS3；
现在：浏览器既支持前缀CSS3，又支持正常CSS3；
未来：浏览器不支持前缀CSS3，仅支持正常CSS3.
渐进增强的写法，优先考虑老版本浏览器的可用性，最后才考虑新版本的可用性。在时期3前缀CSS3和正常CSS3都可用的情况下，正常CSS3会覆盖前缀CSS3。优雅降级的写法，优先考虑新版本浏览器的可用性，最后才考虑老版本的可用性。在时期3前缀CSS3和正常CSS3都可用的情况下，前缀CSS3会覆盖正常的CSS3。

就CSS3这种例子而言，我更加推崇渐进增强的写法。因为前缀CSS3的某些属性在浏览器中的实现效果有可能与正常的CSS3实现效果不太一样，所以最终还是得以正常CSS3为准。如果你好奇究竟是什么属性在前缀CSS3和正常CSS3中显式效果不一样，可以看看这篇文章《需警惕CSS3属性的书写顺序》。

如何抉择
如果软件开发的预算和时间充足，就不存在抉择的问题。然而现实很残酷，要么开发周期短，要么开发预算少，或者二者兼而有之，这个时候该如何抉择？就我个人而言，讲讲我的观点。

根据你的用户所使用的客户端的版本来做决定。请注意我的措辞，我没有用浏览器，而是用客户端。因为渐进增强和优雅降级的概念本质上是软件开发过程中低版本软件与高版本软件面对新功能的兼容抉择问题。服务端程序很少存在这种问题，因为开发者可以控制服务端运行程序的版本，就无所谓渐进增强和优雅降级的问题。但是客户端程序则不是开发者所能控制的（你总不能强制用户去升级它们的浏览器吧）。我们所谓的客户端，可以指浏览器，移动终端设备（如：手机，平板电脑，智能手表等）以及它们对应的应用程序（浏览器对应的是网站，移动终端设备对应的是相应的APP）。

现在有很成熟的技术，能够让你分析使用你客户端程序的版本比例。如果低版本用户居多，当然优先采用渐进增强的开发流程；如果高版本用户居多，为了提高大多数用户的使用体验，那当然优先采用优雅降级的开发流程。

然而事实情况是怎么样的呢？绝大多数的大公司都是采用渐进增强的方式，因为业务优先，提升用户体验永远不会排在最前面。例如：新浪微博网站前端的更新，拥有这种亿级用户的网站，绝对不可能追求某个特效而不考虑低版本用户可不可用，一定是确保低版本到高版本的可访问性，再去渐进增强，采用新功能给高版本用户提供更好的用户体验。但也不是没有反例。如果你开发的是一款面向青少年的软件（或网站），你知道这个群体的人总是喜欢尝试新事物，总是喜欢酷炫的特效，总是喜欢把它们的软件更新到最新版本（而不像我们老一辈的用户）。面对这种情况，渐进增强的开发流程实为上选。

软件开发中，从来就没有银弹。具体的抉择，请读者视情况而定。

# 参考
[渐进增强 VS 优雅降级](https://www.jianshu.com/p/d313f1108862)

渐进增强和优雅降级

### 反抖：
指连续触发事件但只在最后一次触发后才执行一次处理函数的方法。在设定的时间间隔内，如果触发了多次事件，则只有最后一次事件触发后的一段时间内没有再触发事件，才会执行处理函数。例如，在用户输入搜索关键字时，我们可能需要使用防抖方法，以避免每次输入都触发请求，导致服务器压力过大。
```js
 var debounce = function(func,delay){
  let timer;
  return function(...args){
   if(timer){
     clearTimeout(timer)
  }
    timer=setTimeout(function(){
    func.apply(this,args)
    },delay)
  }
}
```
### 节流：
指在一定时间间隔内，无论触发了多少次事件，都只执行一次处理函数的方法。例如，当我们监听窗口的滚动事件时，可以使用节流方法，以避免滚动过程中触发过多的计算和渲染操作，导致页面卡顿。

```js
var throttle = function (func, wait) {
  let now, timer;
  let previous = 0;
  return function (...args) {
    now = +(new Date());
    if (now - previous >= wait) {
      timer&&clearTimeout(timer);
      func.apply(this, args);
      previous = now;
    }
    else{
      timer&&clearTimeout(timer);
      console.log(wait - now + previous)
      timer = setTimeout(() => {
        func.apply(this, args);
        previous = now;
      }, wait - now + previous)
    }
  }
}
```

#### 总之，防抖和节流都可以优化事件处理函数的执行效率和性能，但它们的应用场景和具体实现方式略有不同。需要根据具体情况来选择使用哪种方法。





节流与反抖

**Nuxt.js是一个基于Vue.js的服务端渲染(SSR)框架，它提供了一种快速构建Web应用程序的方式，既可以满足前端开发的需求，又可以让应用程序在SEO、性能优化等方面获得更好的表现。随着前端技术的不断发展，Nuxt.js已经成为了现代Web应用程序开发中不可或缺的工具之一。本文记录自己学习Nuxt需要记录的知识点。**



## asyncData运行在服务端，客户端储存的cookie，在服务端无法获取

在axios里，通过process是否在服务端，在发送的时候带上cookie
```js
// process.server   Boolean，为true时，此时环境在服务端
// process.client   Boolean，为true时，此时环境在客户端

if(process.server){  // 是否在服务端运行，如果是，则带上session
  config.headers={
    ...config.headers,
    cookie:process.headers.cookie
  }
  ```

但是process下，并不会携带headers这个属性，这个时候需要我们创造

我们可以通过middleware中间件
```js
export default function({req}){  // req是服务端的Request 对象
  process.headers = req.headers 
}
```

上面的方法是session以cookie形式时的解决方法，那么当使用token时，
```js
import Cookies from 'js-cookie'
 
if(process.server){ // token用cookie存储
  let cookies=process.headers.cookie.split('; ')
  let cookieObj={}
  cookies.forEach((key,index)=>{
    let split=key.split('=')
    cookieObj[split[0]]=split[1]
  })
  config.headers['Authorization'] =cookieObj['Authorization']
}
else{
  config.headers['Authorization'] =Cookies.get('Authorization')
}
```

## Nuxt视图
可通过添加 layouts/default.vue 文件来扩展应用的默认布局，可以在此处添加全局css

可以通过编辑 layouts/error.vue 文件来定制化错误页面

vue的head可以覆盖nuxt.config.js

```js
// 个性化布局
export default {
  layout: 'blog',
  // 或
  layout (context) {
    return 'blog'
  }
}
```

## 全局css配置
nuxt.config.js
```js
css: ['~common/css/base.scss']
```

Nuxt 学习记录


### 分享
当分享房屋页面时，用postMessage告诉小程序当前房屋的ID，当用户点击分享时，会触发
bindmessage事件，此时把房屋传递到当前的this里，在分享的时候动态添加'homeId'参数，如 path: '/pages/home/home?homeId='+this.detail.data[this.detail.data.length - 1]。
当用户打开小程序时，检测是否从分享里面进来（1007 || 1008），如果是的话，将homeId值改变，传入web-view的src
为了保证只在详情页面转发才可以进去，其它页面转发一率跳到‘/home’。在路由守卫设置，在非'‘/home/house’时，postMessage值设置为false，bindMessage会把false的值传到地址栏,然后在‘/home’页面判断地址栏解析后的值是否符合标准。


### hash路由跳转
```html
<web-view src="https://www.embracex.com/#/home/house">
```
后面不能加‘#wechat_redirect’

### 编码问题
web-view src  传参时中文会导致ios页面无法打开。需要进行编码






