字节-抖音短视频-社招-5年 · 第 1 轮 · 二面

* **合理使用 `async` / `defer` 加载 JS**：避免阻塞 HTML 解析

#### 3. **首屏代码最小化（关键代码提取）**

* **路由懒加载**：非首屏模块按需加载

  ```js
  const About = React.lazy(() => import('./About'));
  ```
* **组件级拆分（如 webpack 的 SplitChunks）**：减少主包体积
* **SSR / SSG / 静态渲染**：预渲染首屏内容，降低白屏时间

#### 4. **骨架屏 + 占位图**

* 使用骨架屏组件在主内容加载前展示占位 UI

  ```html
  <div class="skeleton-loader">...</div>
  ```
* 提高用户感知速度，避免白屏

#### 5. **缓存策略**

* 使用强缓存（Cache-Control）与协商缓存（ETag）
* 使用 Service Worker 做离线缓存，提升重复访问性能

#### 6. **图片优化**

* 使用 WebP、AVIF 等新格式
* 小图 base64 内嵌、大图懒加载
* 多倍图压缩（如用 tinypng 等工具）控制首屏图体积 <200KB

---

### 三、项目实战效果举例（性能指标前后对比）

| 优化项          | 优化前   | 优化后   |
| ------------ | ----- | ----- |
| 首屏加载时间（TTFB） | 1.8s  | 0.9s  |
| JS包大小        | 1.2MB | 450KB |
| 首屏渲染（FCP）    | 3.5s  | 1.2s  |
| 可交互时间（TTI）   | 5.2s  | 1.9s  |

---

### 四、常见误区与陷阱

* **盲目使用懒加载**：过度懒加载会导致首屏核心内容延迟
* **未合理拆分 vendor 包**：导致主包过大
* **骨架屏布局不一致或闪烁**：影响用户体验

---

### 五、总结

* 首屏优化是系统性工程，涵盖网络传输、资源管理、组件拆分、渲染路径等多环节。
* 应结合业务场景按阶段优化，配合 Lighthouse/Chrome DevTools 实时评估效果。
* 目标是压缩关键资源、减少阻塞、加快首屏渲染并保障体验一致性。

</details>

## 3. 如何识别首屏关键资源 {#question-subjective-9bbab0275c1b}

### 题目要点

* 明确首屏关键资源的定义与分类
* 能列出识别方法：Performance、Lighthouse、Network、Coverage
* 能结合项目给出识别+优化的实际策略
* 有资源优先级调度、渲染阻塞等知识支撑

<details>
<summary>参考答案</summary>

### 考察点

#### ● 识别影响首屏渲染的关键资源<br>
考察候选人对渲染链路和性能瓶颈的理解。

#### ● 熟悉浏览器加载机制与资源优先级调度<br>
考察对 Chrome DevTools、Performance 面板等性能工具的使用能力。

---

### 参考答案

### 一、首屏关键资源的定义

> **首屏关键资源**是指那些**必须在首屏渲染前加载完成**，否则会**阻塞页面首屏展示**的资源。常见类型包括：

- **HTML 入口文件**：解析整个页面结构的根文档
- **CSS 样式表**：CSS 是阻塞渲染的，必须加载后才能绘制页面
- **首屏 JS 脚本**：用于首屏交互或组件逻辑初始化的 JS（例如 React/Vue 渲染逻辑）
- **首屏图片**：Banner、大图等占据首屏核心位置的可见资源
- **字体文件（可选）**：若首屏需展示特殊字体（注意 FOUT 问题）

---

### 二、识别关键资源的方法

#### 1. 使用 Chrome DevTools → Performance 面板

1. 打开页面，F12 → Performance → 开始录制
2. 观察：
   - **Loading 阶段的资源瀑布图**（Network Timing）
   - **Longest Frame Before First Paint**
   - 标出首屏时间点前加载完成的资源，即为关键资源

#### 2. 使用 Chrome DevTools → Coverage 面板

- 识别“实际使用的 CSS/JS”
- 可以看出哪些资源在首屏期间被真正用到，哪些是冗余代码

#### 3. 使用 Lighthouse 报告

- Lighthouse 中的“Diagnostics”项会指出：
  - 阻塞渲染的资源（Render Blocking Resources）
  - Critical Request Chains
  - Unused JS/CSS 提示，帮助精简非关键资源

#### 4. 查看 Chrome DevTools → Network 面板排序

- 按时间排序，查看首屏渲染前加载的资源
- 关注 `Initiator` 列，了解加载来源（HTML、JS 引入、CSS @import）

---

### 三、首屏关键资源识别的原则

| 资源类型     | 是否为关键资源 | 原因说明 |
|--------------|----------------|-----------|
| `index.html` | ✅              | HTML 是渲染入口 |
| `main.css`   | ✅              | 阻塞渲染，必须先加载 |
| `main.js`    | ✅              | 驱动页面逻辑，渲染主视图 |
| 首页大图     | ✅              | 首屏可见，未加载即白屏 |
| lazy.js      | ❌              | 延迟加载，非首屏资源 |
| 用户点击后加载的组件 | ❌       | 用户交互后才需要，不影响首屏 |

---

### 四、如何标记与优化首屏资源加载

#### ✅ 使用 `&lt;link rel="preload"&gt;` 预加载关键资源

```html
<link rel="preload" href="/styles/main.css" as="style">
<link rel="preload" href="/scripts/main.js" as="script">

* ✅ **替换重型库**：

  * moment.js → dayjs
  * lodash → 使用原生或轻量函数库
* ✅ **代码分包（SplitChunks）**：

  * 只加载首屏模块，非关键模块延迟加载

#### 2. **CSS 优化**

* ✅ **PurgeCSS / uncss**：移除未使用的 CSS 选择器
* ✅ **合并小文件、减少重复样式**
* ✅ **压缩 CSS（cssnano 等）**
* ✅ **拆分 critical CSS 与非关键 CSS**

  ```html
  <style>/* inline critical CSS */</style>
  <link rel="stylesheet" href="non-critical.css" media="print" onload="this.media='all'" />
  ```

#### 3. **图片资源优化**

* ✅ **使用现代格式（WebP / AVIF）**
* ✅ **图片压缩（tinypng、image-webpack-loader）**
* ✅ **小图 base64 内嵌，减少请求数**
* ✅ **SVG 图标代替 PNG / JPG**
* ✅ **使用 `srcset` 提供不同分辨率资源**

#### 4. **字体资源优化**

* ✅ **子集化字体（Subset Font）**：仅保留页面需要的字符
* ✅ **使用 woff2 格式压缩体积**
* ✅ **延迟加载非首屏字体**

#### 5. **HTML 优化**

* ✅ **去除冗余注释、空白字符**
* ✅ **启用 gzip / brotli 压缩**
* ✅ **减少 HTML 中内联的 JS/CSS**

---

### 三、构建工具相关配置举例（以 Webpack 为例）

```js
// webpack.config.js 中常见压缩插件配置
const TerserPlugin = require('terser-webpack-plugin');
const CssMinimizerPlugin = require('css-minimizer-webpack-plugin');

optimization: {
  minimize: true,
  minimizer: [
    new TerserPlugin({ parallel: true }),
    new CssMinimizerPlugin()
  ]
}
```

---

### 四、优化前后对比效果（示例）

| 类型      | 优化前     | 优化后     |
| ------- | ------- | ------- |
| JS 主包   | 800KB   | 290KB   |
| CSS 主样式 | 220KB   | 70KB    |
| 首页图片    | 400KB   | 120KB   |
| 总体首屏资源  | \~1.5MB | \~500KB |

---

### 五、总结

* **优化目标**：让“首屏相关资源更小、更快、更少”
* **优化策略要针对资源类型差异制定**
* **与构建工具、业务场景相结合落地**
* **建议结合 Lighthouse 报告做持续性指标跟踪**

</details>

## 5. 如何利用缓存策略提升二次加载速度 {#question-subjective-3bf5c552e4c6}

### 题目要点

* 说明强缓存 / 协商缓存的原理与设置方式
* 理解构建产物加 hash 与缓存命中之间的关系
* 熟练掌握 Service Worker 缓存核心资源的能力
* 能结合实际项目给出合理的缓存策略设计方案

<details>
<summary>参考答案</summary>

### 考察点

#### ● 是否理解浏览器缓存的原理与分类<br>
考察候选人对 HTTP 缓存、Service Worker 缓存等的认知是否全面。

#### ● 是否能针对项目合理选择缓存策略<br>
考察实际项目中缓存策略的设计能力，是否能有效提升性能。

---

### 参考答案

### 一、缓存的核心目的

> 利用缓存策略，避免用户每次访问都重新请求资源，**减少网络传输、提升加载速度、降低服务器压力**，实现“秒开体验”。

---

### 二、主流缓存策略概述

#### 1. **HTTP 缓存（浏览器缓存）**

分为两大类：

- ✅ **强缓存（强制命中，无需发请求）**<br>
  - 关键字段：`Cache-Control`（常用）、`Expires`（旧标准）<br>
  - 示例：<br>
    ```http
    Cache-Control: public, max-age=31536000
    ```
    代表资源可缓存 1 年，过期前不会重新请求。

- ✅ **协商缓存（条件命中，服务端确认）**<br>
  - 关键字段：`Last-Modified` / `ETag`<br>
  - 示例：<br>
    ```http
    If-Modified-Since: [上次时间]
    If-None-Match: [上次ETag]
    ```
    若服务端返回 304 Not Modified，则使用本地缓存资源。

#### 2. **Service Worker 缓存**

> 前端可控的离线缓存机制，可缓存页面、资源、接口数据等。

- 常用于：
  - 静态资源缓存（如 HTML、JS、CSS、图片）
  - 接口数据缓存（用于离线或弱网访问）
  - 离线加载（PWA）

#### 3. **浏览器本地存储**

- **LocalStorage / IndexedDB / Cache API**
- 常用于存储静态数据、接口返回结果、用户配置等非敏感信息

---

### 三、如何具体利用缓存策略提升二次加载速度

#### 1. **构建产物加 hash，配合强缓存**

- JS / CSS / 图片资源启用强缓存
  ```http
  Cache-Control: max-age=31536000

self.addEventListener('install', event => {
  event.waitUntil(
    caches.open('v1').then(cache =>
      cache.addAll([
        '/index.html',
        '/main.js',
        '/styles.css',
        '/logo.png'
      ])
    )
  );
});

* 或利用 CDN 的“预热”功能，提前将关键资源缓存到边缘节点

#### 5. **协同缓存控制策略设计**

* CDN 配置：

  ```http
  Cache-Control: public, max-age=31536000, immutable
  ```
* 浏览器也通过 cache-control 与 CDN 配合，提升二次访问速度
* 结合构建产物加 hash，实现**长期缓存 + 强制更新**

---

### 三、实际协同优化案例

#### 项目背景：

* 使用 React + Webpack 构建前端，部署在阿里云 OSS + CDN，启用 HTTP/2。

#### 优化点：

| 优化项                  | 说明                                          | 效果                  |
| -------------------- | ------------------------------------------- | ------------------- |
| 多路复用                 | 所有 JS/CSS 小文件并发加载                           | 首屏加载时间降低 30%        |
| 构建拆分                 | main.js 拆成 runtime.js + vendor.js + page.js | 二次访问命中率提升           |
| CDN 预热               | 页面常用资源上线前自动预热到节点                            | TTFB 从 500ms → 80ms |
| cache-control + hash | 所有静态资源都采用长缓存策略                              | 用户秒开体验显著提升          |

---

### 四、常见误区

* ❌ **HTTP/2 不等于自动性能提升**：需结合实际构建结构与网络架构
* ❌ **仍使用合并大包方式**：反而影响 CDN 缓存粒度
* ❌ **未开启 CDN 的 HTTP/2 / Brotli**：未发挥协议性能优势
* ❌ **忽略缓存配置**：导致 CDN 频繁回源，丧失加速效果

---

### 五、总结

* **HTTP/2 解决协议瓶颈，CDN 解决网络地理瓶颈**，二者结合提升加载性能效果极佳。
* 建议在项目中启用 HTTP/2 + CDN，并配合：

  * 多文件拆分策略
  * 精准缓存配置
  * CDN 节点预热
  * 现代压缩算法（Brotli）
* 实现真正的“多连接合并 + 分资源缓存 + 极速首屏体验”。

</details>

## 7. 说说 https 的握手过程 {#question-5acf760e-09cb-4979-8cc3-b34f20f8dcfe}

> 题库原题：[说说 https 的握手过程](https://fe.ecool.fun/topic/5acf760e-09cb-4979-8cc3-b34f20f8dcfe)

### 题目要点

HTTPS的详细握手过程包括以下步骤：

1. **TCP三次握手**：建立一个TCP连接。
2. **客户端发送Client Hello**：客户端发送包含TLS版本、随机数、加密套件候选列表等信息的数据包。
3. **服务端发送Server Hello**：服务端收到客户端的Client Hello后，选择一个TLS版本和加密套件，并发送Server Hello响应。
4. **服务端发送证书**：服务端发送自己的数字证书，证明其身份。
5. **服务端发送Server Key Exchange**：对于某些加密算法，服务端发送公钥参数。
6. **服务端发送Server Hello Done**：通知客户端Server Hello信息发送结束。
7. **客户端发送Client Key Exchange、Change Cipher Spec、Encrypted Handshake Message**：客户端发送公钥参数，通知使用协商的密钥和加密算法，并发送加密的握手消息以测试密钥的有效性。
8. **服务端发送New Session Ticket**：服务端发送会话票据，用于在超时时间内复用协商的密钥。
9. **服务端发送Change Cipher Spec**：服务端通知客户端后续通信将使用协商的密钥和加密算法。
10. **服务端发送Encrypted Handshake Message**：服务端发送加密的握手消息，用于验证客户端和服务端能正常加密和解密。
11. **完成密钥协商，开始发送数据**：双方使用协商的密钥加密和解密数据。
12. **完成数据发送，4次TCP挥手**：双方发送结束握手，关闭TCP连接。

整个握手过程确保了安全通信的建立，包括身份验证、密钥协商和加密配置。

<details>
<summary>参考答案</summary>

## https的详细握手过程

https在七层协议里面属于应用层，他基于tcp协议，所以，https握手的过程，一定先经过tcp的三次握手，tcp链接建立好之后，才进入https的对称密钥协商过程，对称密钥协商好之后，就开始正常的收发数据流程。

接下来拿实际网络数据包来解释https的整个详细的握手过程

打开wireshark抓包工具，并随手打开命令行，输入了如下一行命令

```
curl https://www.baidu.com

```

上面其实涉及到两个问题：

1. 为什么是wireshark，而不是fiddler 或者 charles<br>
> fiddler 和charles主要是用于抓取应用层协议https/http等上层的应用数据，都是建立链接成功后的数据，而wireshark是可以抓取所有协议的数据包（直接读取网卡数据）,我们的目的是抓取https建立链接成功前的过程，所以我们选择wireshark

2. 为什么是用curl， 而不是在浏览器打开https://www.baidu.com<br>
> curl是只发送一个请求，如果是用浏览器打开百度，那百度页面里面的各种资源也会发送请求，容易造成很多不必要的数据包

好，重点来了，开始上图：

![3.jpg](https://static.ecool.fun//article/5eb1e871-2272-4b5c-b3c2-4b997ca9cfed.jpeg)

![4.jpg](https://static.ecool.fun//article/edecff28-62c5-4063-aa63-c873697d25b8.jpeg)

遇到凡事不要慌，接下来待我给你慢慢道来（ack消息属于tcp协议里面的确认报文，不做解释）

#### 第一步

![BBDC09E23F6A440A9D8DF91C8988F884_20200706143251.jpg](https://static.ecool.fun//article/1af0a8a1-e0b9-498e-b89b-de1b1d517b1a.jpeg)

> 解释说明：tcp三次握手，这个不做解释，如果这块不清楚，比如ack，seq,mss,win都代表什么意思，这个可以在互动区留言，我视情况专门写几篇tcp的文章（这块太大了，没几篇是介绍不完的）

#### 第二步：客户端发送client\_hello

![6.jpg](https://static.ecool.fun//article/19971982-68c1-4388-b455-0cdac1618916.jpeg)

> 解释说明：客户端发送client\_hello，包含以下内容（请自行对照上图） 1\. 包含TLS版本信息 2\. 随机数（用于后续的密钥协商）random\_C 3\. 加密套件候选列表 4\. 压缩算法候选列表 5\. 扩展字段 6\. 其他

#### 第三步：服务端发送server\_hello

![0.jpg](https://static.ecool.fun//article/f217ddb9-11b9-4815-88bd-a6c145a9ec3b.jpeg)

> 解释说明：服务端收到客户端的client\_hello之后，发送server\_hello，并返回协商的信息结果 1\. 选择使用的TLS协议版本 version 2\. 选择的加密套件 cipher suite 3\. 选择的压缩算法 compression method 4\. 随机数 random\_S 5\. 其他

#### 第四步：服务端发送证书

![31.jpg](https://static.ecool.fun//article/af820a6a-12bd-4f1b-b126-6513a102aabc.jpeg)

> 解释说明：服务端发送完server\_hello后，紧接着开始发送自己的证书（不清楚证书是什么的，可以移步到[上一篇文章](https://juejin.cn/post/6845166890675863559)），从图可知：因包含证书的报文长度是3761，所以此报文在tcp这块做了分段，分了3个报文把证书发送完了

> 问自己： 1\. 分段的标准是什么？ 2\. 什么时候叫分段，什么时候叫分片？ 3\. 什么是MTU，什么是MSS

#### 第五步：服务端发送Server Key Exchange

![27.jpg](https://static.ecool.fun//article/f88e594d-8b3f-4589-8114-326c8a366560.jpeg)

> 解释说明:对于使用DHE/ECDHE非对称密钥协商算法的SSL握手，将发送该类型握手。RSA算法不会进行该握手流程（DH、ECDH也不会发送server key exchange）,也就是说此报文不一定要发送，视加密算法而定。SSL中的RSA、DHE、ECDHE、ECDH流程与区别可以参考[此篇文章](https://blog.csdn.net/mrpre/article/details/78025940)

#### 第六步：服务端发送Server Hello Done

![11.jpg](https://static.ecool.fun//article/36c979f7-35bc-4882-94fd-1e04adf3245c.jpeg)

> 解释说明:通知客户端 server\_hello 信息发送结束

#### 第七步：客户端发送.client\_key\_exchange+change\_cipher\_spec+encrypted\_handshake\_message

![10.jpg](https://static.ecool.fun//article/f7043a3f-aaed-4b76-9349-c41d24f03196.jpeg)

> 解释说明: 1\. client\_key\_exchange，合法性验证通过之后，向服务器发送自己的公钥参数，这里客户端实际上已经计算出了密钥 2\. change\_cipher\_spec，客户端通知服务器后续的通信都采用协商的通信密钥和加密算法进行加密通信 3\. encrypted\_handshake\_message，主要是用来测试密钥的有效性和一致性

#### 第八步：服务端发送New Session Ticket

![948.jpg](https://static.ecool.fun//article/de0beb4d-5eee-4d5c-8883-634773f2a2e2.jpeg)

> 解释说明:服务器给客户端一个会话，用处就是在一段时间之内（超时时间到来之前），双方都以协商的密钥进行通信。

#### 第九步：服务端发送change\_cipher\_spec

![37.jpg](https://static.ecool.fun//article/2c53bff9-2d84-49b4-953d-ae62a11911ea.jpeg)

> 解释说明:服务端解密客户端发送的参数，然后按照同样的算法计算出协商密钥，并通过客户端发送的encrypted\_handshake\_message验证有效性，验证通过，发送该报文，告知客户端，以后可以拿协商的密钥来通信了

#### 第十步：服务端发送encrypted\_handshake\_message

![03.jpg](https://static.ecool.fun//article/5fe5ee5a-eff9-4933-bb4c-d51d2ca8c80e.jpeg)

> 解释说明:目的同样是测试密钥的有效性，客户端发送该报文是为了验证服务端能正常解密，客户端能正常加密，相反：服务端发送该报文是为了验证客户端能正常解密，服务端能正常加密

#### 第十一步：完成密钥协商，开始发送数据

![0706182714.jpg](https://static.ecool.fun//article/b6823e50-f6dc-4570-b0f9-740fe0d8f5e6.jpeg)

> 解释说明：数据同样是分段发送的

#### 第十二步：完成数据发送，4次tcp挥手

![6183001.jpg](https://static.ecool.fun//article/95abd39e-df25-43d5-97fa-4861185ea860.jpeg)

> 解释说明：红框的意思是：客户端或服务器发送的，意味着加密通信因为某些原因需要中断，警告对方不要再发送敏感的数据,服务端数据发送完成也会有此数据包，可不关注

## 结语

最后用一张图来说明以下过程

![20190626125502435.png](https://static.ecool.fun//article/5fe6b973-9dc5-400c-a2c8-cdae7b5d8624.jpeg)

</details>

## 8. 为什么HTTPS能防止中间人攻击 {#question-subjective-794443b89cbc}

### 题目要点

- 懂得中间人攻击是“伪装+监听+篡改”的过程
- 能清晰解释 HTTPS 防护机制（证书 + 加密 + 完整性）
- 能对比 HTTP 的不足，说明为什么 HTTPS 更安全
- 知道 TLS 握手流程及其安全意义

<details>
<summary>参考答案</summary>

### 考察点

#### ● 是否理解 HTTPS 的加密原理和中间人攻击的本质<br>
面试官想了解候选人是否真正掌握 TLS 握手过程和公钥加密机制，而不是表面地说“HTTPS更安全”。

#### ● 是否了解证书信任机制与非对称加密的作用<br>
验证候选人是否理解数字证书如何防止数据被篡改或伪造。

---

### 参考答案

### 一、中间人攻击（MITM）的本质是什么？

> 中间人攻击（Man-in-the-Middle Attack）是指攻击者在客户端与服务器之间**截获、篡改或伪造通信内容**的一种攻击方式。

常见手段：
- 恶意 Wi-Fi 热点劫持
- DNS 污染/伪造
- 篡改请求或响应数据
- 冒充服务器与用户建立连接

---

### 二、HTTPS 的核心防护机制

HTTPS = HTTP + TLS/SSL，主要靠 **TLS 握手 + 加密通信** 实现防护。

#### 1. **非对称加密保障密钥协商安全**

- 浏览器连接服务器 → 获取服务端公钥（证书中携带）
- 客户端使用公钥加密随机生成的“对称密钥”
- 只有服务端私钥可以解密该密钥，整个过程**即便被监听，也无法解密内容**

✅ 防止：中间人获取密钥后解密数据。

#### 2. **数字证书验证服务器身份**

- 浏览器验证服务器下发的证书是否由可信 CA 签发
- 验证内容包括：
  - 证书链是否完整
  - 域名是否匹配
  - 证书是否过期/吊销
- 若证书被伪造，浏览器会拦截连接（提示证书不安全）

✅ 防止：中间人伪造服务器欺骗客户端。

#### 3. **对称加密保护通信内容**

- 握手后，客户端与服务器使用协商好的对称密钥加密通信数据
- 加密算法：如 AES、ChaCha20 等，安全性强，无法被直接破解

✅ 防止：监听数据包也无法看到明文内容。

#### 4. **完整性校验防止篡改**

- 每个数据包包含 MAC（消息认证码）或使用 AEAD 模式（如 GCM）
- 即便数据被截获，也无法修改内容而不被检测

✅ 防止：中间人偷偷修改请求或响应数据。

---

### 三、HTTPS 防止中间人攻击的完整链路过程图（简述）

```

\[浏览器] ─── TLS握手 ───► \[服务端]
│                       │
▼                       ▼
验证证书                 解密密钥
生成对称密钥          建立加密通道
│                       │
└── 加密通信 ◄────────┘

```

---

### 四、为什么 HTTP 无法防止中间人攻击？

HTTP 是明文传输，没有任何加密或验证机制，攻击者可以：
- 拦截请求/响应（抓包工具即可）
- 修改 HTML/JS 注入广告、木马
- 劫持登录信息或令牌

---

### 五、总结

HTTPS 能有效防止中间人攻击的根本原因在于：

1. **非对称加密协商密钥，不怕被窃听**
2. **数字证书验证服务器身份，防止伪造**
3. **对称加密保障通信数据机密性**
4. **完整性校验防止篡改**

只有三者结合，才能真正构建安全可信的通信链路。

</details>

## 9. HTTPS的证书链的验证过程是怎样的 {#question-subjective-ea18fae3bbd5}

### 题目要点

- 能说出证书链的组成结构（服务器证书 / 中间 CA / 根证书）
- 明确验证过程是“从服务器证书一路验证到本地根证书”
- 能说明验证项目包括签名、有效期、吊销状态、域名等
- 能指出浏览器本地信任库的重要性

<details>
<summary>参考答案</summary>

### 考察点

#### ● 是否理解 HTTPS 中的数字证书验证机制<br>
面试官希望候选人能清晰解释浏览器是如何验证服务器身份的，是否理解「信任链」的概念。

#### ● 是否掌握证书链的组成、验证步骤及信任模型<br>
关注候选人是否了解中间 CA、根证书、浏览器信任库的关系。

---

### 参考答案

### 一、什么是证书链？

HTTPS 使用的 TLS 证书（通常为 X.509 格式）并不是单独存在的，而是组成一条“信任链”。

这条证书链包含三类证书：

1. **服务器证书（Leaf Certificate）**<br>
   - 安装在网站服务器上<br>
   - 绑定域名、包含公钥信息<br>

2. **中间证书（Intermediate CA）**<br>
   - 由根证书签发<br>
   - 通常是“证书颁发机构的中继者”，实际用于签发服务器证书

3. **根证书（Root Certificate）**<br>
   - 由权威 CA 签发，并预装在浏览器/操作系统信任库中<br>
   - **信任的起点**，必须是浏览器本地“已信任”的证书

🔗 **证书链**：服务器证书 ← 中间证书 ← 根证书<br>
➡️ 服务器会将证书链（除根证书外）传给浏览器进行验证。

---

### 二、证书链验证的完整过程

> 验证目的：确保服务端证书是合法、未被伪造的。

#### ✅ 第一步：获取服务端下发的证书链

- 浏览器访问网站 → 服务端返回 TLS 证书链：
```

\[服务器证书] + \[中间 CA 证书] + ...（可能有多个中间证书）

```

#### ✅ 第二步：逐级验证签名链是否有效

浏览器按以下顺序校验：

1. **验证服务器证书的签名是否由中间证书签发**
 - 签名有效：继续
 - 否则：终止，提示“不受信任的证书”

2. **验证中间证书是否由更高级的中间 CA 签发**
 - 若存在多个中间证书，逐层验证

3. **验证顶层中间证书是否由根证书签发**
 - 查找本地「受信任的根证书列表」是否包含该根证书
 - 若找不到：终止连接，提示“不受信任的签名机构”

#### ✅ 第三步：校验证书有效性

除了验证签名链，还需检查以下内容：

- 📅 **证书是否过期（Valid Time）**
- 🔐 **证书是否被吊销（通过 CRL / OCSP 查询）**
- 🌐 **证书绑定的域名是否与当前访问域名匹配**
- 🔗 **是否为可信的签名算法（如 SHA-1 已不被信任）**

---

### 三、图示：HTTPS 证书链验证流程

```

\[浏览器信任库]
▲
\[根证书] ← \[中间CA] ← \[服务器证书]
│                     ▲
浏览器本地     服务端下发

```

---

### 四、浏览器是如何信任根证书的？

- 浏览器 / 操作系统内置一组「受信任的根证书」，称为 **信任锚（Trust Anchors）**
- 常见的根证书颁发机构（Root CA）有：
  - DigiCert
  - GlobalSign
  - Let's Encrypt
  - Sectigo（原 Comodo）

💡 用户也可以手动导入自签名根证书，用于企业内网、自建平台等场景。

---

### 五、常见面试陷阱

- ❌ **误以为证书链中一定包含根证书**<br>
  实际上浏览器会自行查找本地根证书，而不是依赖服务端提供

- ❌ **认为只验证服务器证书本身**<br>
  忽略了中间 CA 的存在，容易答漏或答错

- ❌ **不了解证书被吊销也会导致验证失败**<br>
  比如使用 OCSP Stapling 提前拉取吊销状态也是重要细节

---

### 六、总结

证书链验证过程 = **链式签名校验 + 有效性检查 + 本地信任校验**

- 🔐 保证服务端身份可信（不是伪造者）
- 🧾 浏览器利用预置的根证书，信任一整条链
- 🚨 一旦任意一环验证失败，HTTPS 连接就会被拒绝

</details>

## 10. 设置 Domain=.example.com 和 Domain=example.com 有什么区别 {#question-subjective-668a630018e4}

### 题目要点

* 明确两种写法在现代浏览器中效果相同
* 知道 `.example.com` 是旧式写法，现代推荐直接写 `example.com`
* 能结合 Cookie 跨子域共享、浏览器安全策略进行分析

<details>
<summary>参考答案</summary>

### 考察点

#### ● 是否理解 Cookie 中 Domain 属性的作用和规则<br>
面试官希望通过这道题，考察候选人对 Cookie 跨子域共享、作用域控制的理解程度。

#### ● 是否能正确解释两个写法的区别及兼容性问题<br>
了解细节差异是否会影响浏览器行为，以及如何在实际项目中正确设置。

---

### 参考答案

### 一、Cookie 中 `Domain` 属性的作用

> `Domain` 属性用于指定 Cookie 可以被哪些域名访问。

- 默认情况下（未设置 `Domain`）：
  - Cookie 只能被当前域访问（**不包含子域**）

- 设置了 `Domain`：
  - Cookie 将作用于 **指定域及其子域**（前提是设置的 domain 属于当前请求域）

---

### 二、`Domain=.example.com` 和 `Domain=example.com` 的区别

> **在大多数现代浏览器中，它们的作用是等价的**。<br>

#### ✅ 共同点：

| 设置方式               | 可被访问的域                |
|------------------------|-----------------------------|
| `Domain=.example.com`  | `example.com`、`a.example.com`、`b.example.com` |
| `Domain=example.com`   | `example.com`、`a.example.com`、`b.example.com` |

两者都会使 Cookie 在主域及子域中共享。

#### ❗ 差异来源：

- `Domain=.example.com` 是 **早期 Netscape 规范中的写法**，推荐使用点号来明确“子域可用”。
- `Domain=example.com` 是现代浏览器**更宽容且推荐**的写法，点号被视为冗余。

现代浏览器为了兼容，**两种写法都支持跨子域访问**，但有以下细微差别：

| 差异点 | 描述 |
|--------|------|
| 可读性 | `.example.com` 明确指出对子域开放访问，表达更直观 |
| 向后兼容 | 某些非常旧的浏览器（如 IE6/IE7）曾区别对待，`.example.com` 更具兼容性 |
| 语义标准 | `example.com` 已包含子域含义，点号可省略 |

---

### 三、项目中的推荐做法

- ✅ 若要让多个子域（如 `www.example.com`、`api.example.com`）共享登录状态或 token，设置：
  ```http
  Set-Cookie: token=abc; Domain=example.com; Path=/;

Set-Cookie: token=abc; Domain=example.com;

Set-Cookie: session=xyz; Path=/admin;

Set-Cookie: token=abc; Secure;

Set-Cookie: auth=abc; SameSite=None; Secure;

1. 当前 URL 的域名和路径是否匹配 Set-Cookie 的 Domain & Path？
2. 是否是 HTTPS 请求？若 Cookie 有 Secure 限制，则必须是 HTTPS。
3. 是否为跨站请求？若是，SameSite 策略是否允许？
4. 是否是第三方请求？是否设置 withCredentials？
5. 最终符合条件的 Cookie 会被自动附带到请求头中。

fetch('https://api.example.com/user', {
  credentials: 'include', // 允许携带 Cookie
});

Access-Control-Allow-Origin: https://your.frontend.com
Access-Control-Allow-Credentials: true

Set-Cookie: token=abc; Path=/user;

Set-Cookie: token=abc; Max-Age=3600; // 设置 1 小时有效期

fetch('/static/data.json', {
  credentials: 'omit',
});

Cache-Control: max-age=3600
Expires: Wed, 21 Oct 2025 07:28:00 GMT

<script src="/app.js?v=20230727"></script>
<!-- 或 -->
<script src="/app.abcdef.js"></script>

<img src="https://bank.com/transfer?amount=10000&to=attacker" />

Set-Cookie: sessionid=abc123; SameSite=Strict; Secure; HttpOnly

function Person() {
  this.name = 'Alice';
  return { name: 'Bob' };
}
const p = new Person();
console.log(p.name); // 输出 'Bob'

function Person() {
  this.name = 'Alice';
  return 123;
}
const p = new Person();
console.log(p.name); // 输出 'Alice'

const Person = () => {
  this.name = 'Alice';
};
const p = new Person(); // 报错 TypeError

console.log(0.1 + 0.2);       // 0.30000000000000004
console.log(0.1 + 0.2 === 0.3); // false

const isEqual = Math.abs((0.1 + 0.2) - 0.3) < Number.EPSILON;
console.log(isEqual); // true

总宽度 = width + padding-left + padding-right + border-left + border-right

.box {
  width: 200px;
  padding: 10px;
  border: 2px solid #000;
}

.box {
  box-sizing: border-box;
}

内容宽度 = width - padding-left - padding-right - border-left - border-right
总宽度 = width（固定值）

布局宽度 = 总宽度 + margin-left + margin-right

const el = document.querySelector('.box');
const totalWidth = el.offsetWidth; // 包含 padding + border，不含 margin
const fullWidth = el.offsetWidth +
  parseFloat(getComputedStyle(el).marginLeft) +
  parseFloat(getComputedStyle(el).marginRight);

function Outer() {
  this.value = 'outer';
  const arrow = () => {
    console.log(this.value);
  };
  arrow(); // 'outer'
}
new Outer();

function normal() {
  console.log(this);
}
normal();           // 浏览器中是 window，严格模式是 undefined
normal.call({ x: 1 }); // { x: 1 }

const fn = () => { console.log(this); };
fn.call({ x: 1 }); // 仍然是箭头函数定义时的 this，不会变

element.addEventListener('click', () => {
  this.handleClick(); // 如果 this 不是预期对象，可能报错
});

func.apply(thisArg, [arg1, arg2, ...])

Function.prototype.myApply = function(context, args) {
  if (typeof this !== 'function') {
    throw new TypeError('myApply must be called on a function');
  }

  context = context || globalThis; // window / global / self
  const fnSymbol = Symbol('fn');
  context[fnSymbol] = this;

  let result;
  if (!args) {
    result = context[fnSymbol]();
  } else {
    if (!Array.isArray(args)) {
      throw new TypeError('Second argument must be an array');
    }
    result = context[fnSymbol](...args);
  }

  delete context[fnSymbol];
  return result;
};

function greet(name, age) {
  return `${this.title}: ${name}, age ${age}`;
}

const obj = { title: 'Manager' };

console.log(greet.myApply(obj, ['Alice', 30]));
// 输出：Manager: Alice, age 30

const fakeWindow = new Proxy({}, {
  get: (target, key) => window[key],
  set: (target, key, value) => {
    target[key] = value;
    return true;
  }
});

function runInSandbox(code) {
  with (fakeWindow) {
    eval(code); // 沙箱执行
  }
}

/* 作用域前缀隔离 */
.app1 .button {
  color: red;
}

const container = document.getElementById('app');
const shadowRoot = container.attachShadow({ mode: 'open' });
shadowRoot.innerHTML = `<style>.btn { color: red; }</style><div class="btn">Click</div>`;