CORS请求中，是如何触发预检请求的
在CORS（跨源资源共享）请求中，预检请求的触发通常基于以下几种情况：
- 请求方法非GET、HEAD和POST中之一：默认请求下，跨域请求仅支持GET、HEAD和POST三种方法；
- POST请求的Content-Type不是简单的请求头之一：一般情况下，POST请求的Content-Type字段的值为application/x-www-form-urlencoded、multipart/form-data或text/plain这三种简单请求头之一；
- 请求设置了自定义的头信息；
- 请求中包含了可读流；
预检请求的流程
- 当满足以上任一条件时，浏览器会首先发送一个OPTIONS请求到服务器（OPTIONS请求就是所谓的预检请求）；
- 服务器在接收到预检请求后，会检查请求中的特殊头信息，并基于这些信息来判断是否允许实际请求的发送；
- 如果预检请求被允许，浏览器才会继续发送实际的CORS请求；如果被拒绝，则浏览器会阻止实际请求的发送，并向开发者报告一个错误。
HTTP中的HSTS是什么
HSTS（HTTP Strict-Transport-Security）：安全策略，通过HTTP头部告诉浏览器只能通过安全的HTTPS连接访问网站，从而增加网站的安全性。HSTS有助于防止恶意攻击者通过中间人攻击窃取敏感信息。
HSTS的主要作用
- 强制使用HTTPS；
- 防止SSL剥离攻击；
- 增加网站的安全性；
HSTS工作原理
- 首次访问：用户首次通过HTTPS访问网站，服务器在响应头中包含HSTS头部，指定网站的HSTS策略；
- 以后的访问：一旦浏览器接收到包含HSTS的头部的响应后，在接下来的
max-age参数有效期内，将强制使用HTTS访问该网站，即便用户尝试通过HTTP访问。
HTTP中的CSP
CSP：Content-Security-Policy，内容安全策略，一种用于增强网站安全性的安全策略机制。通过指定浏览器只能加载指定来源的资源，以减少恶意攻击的风险。
CSP主要目标是防止和减缓特定类型的攻击，比如XXS（跨站脚本攻击）、数据注入攻击等。通过配置CSP，网站管理员可以告诉浏览器哪些资源是被信任的，从而减少恶意代码的执行。
Content-Security-Policy: default-src 'self'; script-src 'self' example.com; img-src 'self' data:;
常见配置项
- default-src：默认情况下从哪些来源加载资源（
self：同一站点） - script-src：允许加载脚本的来源；
- style-src
- img-src
- media-src
- iframe-src
CSP支持使用meta标签配置：
<meta http-equiv="Content-Security-Policy" content="default-src 'self'; script-src 'self' example.com; img-src 'self' data:;">
meta标签配置的CSP，仅对当前页面生效。建议使用HTTP头部设置CSP规则，因为它是对整个站点生效。
SSR（服务器端渲染）
SSR：应用程序的UI是在服务器端渲染完成后，再将整个渲染好的HTML、JS、CSS发送给客户端，进行web应用的渲染。在SSR中，客户端发出请求时，服务器会根据请求数据动态生成对应的HTML内容。这意味着首屏内容不需要等待客户端JS的执行，减少首屏加载时间。
- 优点：更快的首屏加载速度；更好的搜索引擎优化；更好的用户体验；
- 与CSR（客户端渲染）的区别：CSR是通过JS在客户端动态加载数据并更新页面内容的，这种方式提高了网页的交互性，但首屏加载速度慢，且对SEO不友好；
- 实现方式：现在Vue、React都提供了SSR的支持，通常使用Node.js作为服务器端运行环境，通过特定的配置和插件来实现；
- 注意事项：SSR会增加服务器端负担；由于需要动态生成HTML内容，需要额外的网络传输成本；并且对复杂的交互效果和动画，可能需要在客户端进行额外的JS处理等；
SEO优化
SEO优化：涉及多个方面来确保网站在搜索引擎结果中获得更好的排名。
- 关键词的研究和使用：主要关键词和长尾关键词，在合适的位置合理使用关键词；
- 网站结构优化：
- 清晰结构
- 优化URL
- 语意HTML标签
- 内容优化
- 关键词自然融入
- 内容有价值
- 多媒体元素嵌入
- 外部链接策略
- 高质量的反向链接
- 合理的锚文本
- 技术优化
- 移动端优化
- 网站速度优化
- 安全性
- 监测和分析：使用Google Analytics、Google Search Console等工具跟踪关键词排名、流量来源和用户行为等数据。根据分析结果，做出分析、调整和优化；
- 新趋势和方向：人工智能与机器学习、语音搜索优化都是比较新的优化方向；
- 注意事项：避免黑帽SEO、持续更新和维护，一面被搜索引擎惩罚哦~
URL从输入到输出的过程
URL从输入到输出主要步骤：
- 用户地址栏输入URL；
- 浏览器解析和检查：非URL或者含非法字符，可能将内容丢给搜索引擎；
- 查找本地缓存：有且未过期，直接拉取加载；
- DNS解析：域名 → IP地址（查询浏览器缓存、操作系统缓存、路由缓存、ISP的DNS服务器、知道找到对应的IP地址）；
- 建立TCP连接：TCP协议，三次握手；
- 发送HTTP请求；
- 服务器处理请求；
- 返回HTTP响应：HTTP响应报文，通过TCP连接返回给浏览器；
- 关闭TCP连接（HTTP/1.1之前的版本）：在HTTP/1.1之前的版本中，每次请求和响应后都会关闭TCP连接（四次挥手）。但在HTTP/1.1及之后的版本中，为了提高性能，支持了持久连接（keep-alive），允许多个请求和响应复用一个TCP连接。/；
- 浏览器解析资源和数据：页面渲染；
https的连接过程
客户端发起请求 → SSL/TLS握手开始 → 服务端发送证书 → 客户端验证证书 → 生成会话秘钥（公钥+随机数进行加密 → 私钥解密随机数 → 随机数+其它参数生成一个会话密钥，即对称密钥） → 使用会话密钥加密通信 → 数据传输 → 连接结束（四次挥手的过程来确保TCP连接关闭）
为什么用Web Worker？
Web Worker允许将耗时的任务放在后台线程中执行，从而避免阻塞主线程，这表示即使执行了长时间的任务，Web应用的UI仍可以保持响应，因此适用于处理大量数据、执行复杂计算、图像处理、数据解析等计算密集型任务。
- 提高性能：Web Worker可以让应用利用多核CPU的并行计算能力，充分发挥硬件性能；；
- 改善用户体验：耗时的任务转移后台进行，可避免UI的卡顿和延迟；
- 处理复杂任务；
- 后台持续运行；
- 线程间通信：虽然Web Worker不能直接访问DOM或某些浏览器接口对象，但它可以通过消息传递（如postMessage和onmessage事件）与主线程进行通信。这种通信是双向的，允许主线程和Web Worker之间交换数据和命令。；
- 避免渲染阻塞：将费时任务分流到后台线程，确保主线程能够及时处理渲染任务；
