跨域

跨源资源共享 (CORS) （或通俗地译为跨域资源共享）是一种机制，该机制使用附加的 HTTP 头来告诉浏览器，准许运行在一个源上的Web应用访问位于另一不同源选定的资源。 当一个Web应用发起一个与自身所在源（域，协议和端口）不同的HTTP请求时，它发起的即跨源HTTP请求。

产生情况

端口/协议/域名 有任何一个不匹配会导致跨域

浏览器处理情况

对比请求体的 Origin 字段，是否与响应头中的 Access-Control-Allow-Origin 字段是否匹配

简单请求

直接发送请求到服务器，然后浏览器会拦截响应报文

复杂请求

复杂请求(除简单请求之外的)，浏览器会发送option预检请求，看服务器是否允许

笔记

“预检请求“的使用，可以避免跨域请求对服务器的用户数据产生未预期的影响。
猜测是因为复杂请求不安全，容易导致服务器数据变化，所以会先发送预检请求，然而简单请求并不会有风险。
Access-Control-Max-Age，设置后，浏览器会缓存发送option的时间
这个缓存很可能跟域名绑定，这样设置后可以减少预检请求的次数
为什么只在浏览器中跨域？
实际上每发出一个请求，都是在独立请求一个资源，而不是在一个网站返回的页面里，再去请求另外一个网站/端口的资源。自然也就不会造成跨域了。
浏览器外的请求不会被跨域，会不会不安全
postman类似的工具确实可以模拟浏览器发送请求，请求的一些验证信息也可以带上，可是从哪里取到(类似token这类的信息)，除非你自己伪造自己，登录自己的账号取到token然后到postman模拟，你是很难伪造成别人的。

从输入URL到页面展示，这中间发生了什么

  • 用户输入url并回车
  • 浏览器进程检查url，组装协议，构成完整的url
  • 浏览器进程通过进程间通信（IPC）把url请求发送给网络进程
  • 网络进程接收到url请求后检查本地缓存是否缓存了该请求资源，如果有则将该资源返回给浏览器进程
  • 如果没有，网络进程向web服务器发起http请求（网络请求），请求流程如下：
    • 进行DNS解析，获取服务器ip地址，端口（端口是通过dns解析获取的吗？这里有个疑问）
    • 利用ip地址和服务器建立tcp连接
    • 构建请求头信息
    • 发送请求头信息
    • 服务器响应后，网络进程接收响应头和响应信息，并解析响应内容
  • 网络进程解析响应流程；
    • 检查状态码，如果是301/302，则需要重定向，从Location自动中读取地址，重新进行第4步 （301/302跳转也会读取本地缓存吗？这里有个疑问），如果是200，则继续处理请求。
    • 200响应处理：检查响应类型Content-Type，如果是字节流类型，则将该请求提交给下载管理器，该导航流程结束，不再进行后续的渲染，如果是html则通知浏览器进程准备渲染进程准备进行渲染。
  • 准备渲染进程
    • 浏览器进程检查当前url是否和之前打开的渲染进程根域名是否相同，如果相同，则复用原来的进程，如果不同，则开启新的渲染进程
  • 传输数据、更新状态
    • 渲染进程准备好后，浏览器向渲染进程发起“提交文档”的消息，渲染进程接收到消息和网络进程建立传输数据的“管道”
    • 渲染进程接收完数据后，向浏览器发送“确认提交”
    • 浏览器进程接收到确认消息后更新浏览器界面状态：安全、地址栏url、前进后退的历史状态、更新web页面

      事件循环

      One go-around of the event loop will have exactly one task being processed from the macrotask queue (this queue is simply called the task queue in the WHATWG specification). After this macrotask has finished, all available microtasks will be processed, namely within the same go-around cycle. While these microtasks are processed, they can queue even more microtasks, which will all be run one by one, until the microtask queue is exhausted.

      What are the practical consequences of this?

      If a microtask recursively queues other microtasks, it might take a long time until the next macrotask is processed. This means, you could end up with a blocked UI, or some finished I/O idling in your application.
      However, at least concerning Node.js’s process.nextTick function (which queues microtasks), there is an inbuilt protection against such blocking by means of process.maxTickDepth. This value is set to a default of 1000, cutting down further processing of microtasks after this limit is reached which allows the next macrotask to be processed)

      So when to use what?

      Basically, use microtasks when you need to do stuff asynchronously in a synchronous way (i.e. when you would say perform this (micro-)task in the most immediate future). Otherwise, stick to macrotasks.

      Examples

      macrotasks: setTimeout, setInterval, setImmediate, requestAnimationFrame, I/O, UI rendering
      microtasks: process.nextTick, Promises, queueMicrotask, MutationObserver

package.json中字段

module

当使用 import from 的时候，会走 module 指向的文件

main

main一般指向编译过的es5代码