web前端需要知道的浏览器基础知识

一、浏览器架构与进程模型

多进程架构

• 主进程：管理界面、用户交互、子进程及存储
• 渲染进程：每个标签页独立进程，负责HTML/CSS/JS解析与渲染（沙箱隔离）
• GPU进程：处理CSS 3D变换、页面合成等图形任务
• 网络进程：资源加载、HTTP缓存管理
• 插件进程：隔离易崩溃插件（如Flash）

单线程的JavaScript运行时

• 设计原因：避免多线程操作DOM的同步问题
• Web Worker：子线程处理计算密集型任务，但无法操作DOM
• 事件循环机制：任务队列分宏任务（setTimeout）与微任务（Promise），决定代码执行顺序

二、渲染引擎工作流程（关键路径优化）

解析与构建

DOM树：

HTML解析生成，遇<script>阻塞解析（除非加async/defer）

CSSOM树：

CSS解析生成，不阻塞DOM解析但阻塞渲染树合成

⚠️ 关键规则：CSS阻塞JS执行（防止JS获取过时样式） 分层优化：will-change、transform提升为GPU层，避免重排

浏览器渲染中的分层概念

浏览器将网页元素组织成不同的图层(Layers)，每个图层独立绘制，最后组合成最终页面。理解分层机制是优化网页性能的关键。

为什么需要分层优化？

当页面元素发生变化时：

• 重排(Reflow)：元素几何属性改变（位置、大小）→ 重新计算布局
• 重绘(Repaint)：外观属性改变（颜色、背景）→ 重新绘制元素
• 合成(Composite)：图层位置/透明度改变 → 直接重新合成

分层优化通过创建独立图层，使变化仅影响该图层，避免触发重排和重绘。

GPU加速的核心属性

transform属性

.element {
  /* 创建独立图层 */
  transform: translateZ(0); /* 常用技巧 */

  /* 动画示例 */
  transition: transform 0.3s ease;
}
.element:hover {
  transform: scale(1.05); /* 仅触发合成 */
}

will-change属性

.animated-element {
  /* 提前告知浏览器元素将变化 */
  will-change: transform, opacity;

  /* 实际变化 */
  transition: transform 0.4s, opacity 0.2s;
}

opacity属性

.fade-element {
  opacity: 1;
  transition: opacity 0.3s;
}
.fade-element.hidden {
  opacity: 0; /* 仅触发合成 */
}

传统动画 vs GPU加速

动画类型	触发操作	CPU使用	帧率	功耗
left/top动画	重排 → 重绘 → 合成	高	低	高
transform动画	合成	低	高	低

// 性能测试示例
function testAnimation() {
  const element = document.getElementById('box');

  // 传统方式：使用left/top
  let pos = 0;
  function animateTraditional() {
    pos = (pos + 2) % 300;
    element.style.left = `${pos}px`;
    requestAnimationFrame(animateTraditional);
  }

  // GPU加速方式：使用transform
  function animateGPU() {
    pos = (pos + 2) % 300;
    element.style.transform = `translateX(${pos}px)`;
    requestAnimationFrame(animateGPU);
  }

  // 运行测试...
}

三、缓存与存储体系

HTTP缓存策略

强缓存：

强缓存通常通过设置HTTP响应头中的 Cache-Control 和 Expires 来控制，Cache-Control 的优先级高于 Expires。Cache-Control: max-age=31536000（1年有效）

• 特点：直接从缓存中读取资源，不发送任何请求到服务器
• 状态码：200 (from cache)
• 触发条件：缓存未过期时

协商缓存：

当强缓存过期时，浏览器会发起请求到服务器进行验证，这时会使用协商缓存。协商缓存基于服务器返回的资源的唯一标识符，如 ETag 或 Last-Modified 来判断资源是否发生了变化。ETag（文件哈希） vs Last-Modified（时间戳），返回304复用缓存

• 特点：需要向服务器发送请求，服务器判断资源是否更新
• 状态码：304 (Not Modified) 或 200 (资源已更新)
• 触发条件：强缓存失效后

首次访问流程图

缓存有效期内访问（强缓存）

缓存过期后访问（协商缓存）

浏览器存储方案对比

类型	容量	生命周期	特性
Cookie	≤4KB	可设过期时间	自动携带在请求头
Web Storage	5~10MB	永久（Local）/会话（Session）	同源策略隔离
IndexedDB	≥250MB	永久	事务型NoSQL数据库

四、关键机制与优化策略

并发限制：

• 浏览器为每个域名维护一个连接池
• 桌面浏览器最大并发数：6-8个TCP连接/域名
• 移动浏览器最大并发数：4-6个TCP连接/域名
• HTTP/2多路复用突破限制

Http 1.1 特性：

• 默认启用Connection: keep-alive
• 单个TCP连接可处理多个请求
• 通过Keep-Alive: timeout=5, max=100参数控制：
  • timeout：空闲超时时间（秒）
  • max：最大请求数

Http 1.1 问题：

队头阻塞(Head-of-Line Blocking)：同一个TCP连接上，前一个请求没有完成时，后续请求必须等待的现象，即使后续资源可复用连接，也必须等待前面请求完成

HTTP/2 关键概念

1. 连接（Connection）

• 一条 TCP连接，在客户端和服务端之间保持活动。
• 整个连接是双向的、长生命周期的。

2. 流（Stream）

• 一个逻辑上的独立通道，承载一次完整的请求-响应交换。
• 每个流都有唯一的 Stream ID。
• 可以并发存在多个流，每个流可以独立关闭（half-closed, closed 等状态）。

3. 消息（Message）

• 包含完整的 HTTP 请求或响应。
• 由一组帧（Frame）组成。

4. 帧（Frame）

• HTTP/2 中传输的最小单位，每个帧属于一个流。
• 如：HEADERS、DATA、PRIORITY、RST_STREAM 等。
• 多个帧可以交错发送，并通过 Stream ID 归属到不同的流。

HTTP/2 四大核心机制

1. 二进制分帧层（Binary Framing Layer）

帧是http/2的最小通讯单位，HTTP/1.1协议以换行符作为纯文本的分隔符，而HTTP/2将所有传输的信息分割为更小的消息和帧，并采用二进制格式对它们编码，这些帧对应着特定数据流中的消息，他们都在一个TCP连接内复用

2. 多路复用（Multiplexing）

在一条 TCP 连接上并行交错传输任意数量的“流”（Stream）。

• HTTP/2 可以在一个TCP连接上同时传输多个数据流，每个数据流都有唯一的ID
• 多个数据流的帧可以乱序发送，接收端根据帧头部中的流ID进行重组，解决了HTTP/1.1中的队头阻塞问题

3. 头部压缩 HPACK（Header Compression）

HTTP/2 使用HPACK算法对头部进行压缩，减少了头部数据的大小，进一步提高了传输效率

4. 服务器推送（Server Push）

HTTP/2 允许服务器主动向客户端推送资源，而无需客户端显式请求，进一步提高了页面加载速度

预加载：

<link rel="preload">提前获取关键资源。

安全模型

同源策略：限制跨域脚本访问（协议/域名/端口一致）

地址	是否同源（与左侧比较）	原因说明
http://example.com	✅ 是	相同协议、域名、端口
https://example.com	❌ 否	协议不同
http://sub.example.com	❌ 否	子域不同
http://example.com:8080	❌ 否	端口不同
http://example.com/page1	✅ 是	路径不同不影响同源

同源策略主要限制了以下跨源读取操作：

类型	说明
❌ DOM 操作	不能访问嵌入的 <iframe> 或 <window.open> 的页面 DOM
❌ Cookie、LocalStorage	无法读取其他源下的 Cookie、localStorage 等
❌ Ajax	请求响应读取可以发送跨源请求，但不能读取响应内容（除非 CORS）
✅ 跨源资源引用	<img>, <script>, <link> 等标签不受限制（但有风险）

跨域解决方案： CORS头（Access-Control-Allow-Origin）、JSONP、PostMessage API、代理

安全威胁防护：

XSS（反射型XSS、存储型XSS、DOM型XSS）

三种典型XSS

反射型XSS	存储型XSS	DOM型XSS
1. 攻击者构造含恶意脚本的URL（如?search=） 2. 用户被诱骗点击URL 3. 服务器未过滤参数，直接返回含脚本的页面 4. 浏览器执行脚本，数据被窃取	1. 攻击者向服务器提交含恶意脚本的内容 2. 服务器存储到数据库（如评论、用户资料） 3. 普通用户访问正常页面 4. 服务器返回存储的恶意内容 5. 所有访问者的浏览器自动执行脚本	1. 攻击者构造含恶意片段标识的URL（如 #<img src=x onerror=attack()>） 2. 服务器返回的HTML本身是安全的 3. 客户端JavaScript读取URL片段（location.hash） 4. 动态DOM操作触发脚本执行 5. 攻击完全在客户端完成

CSRF

• 本质是利用浏览器自动携带身份凭证的特性，让用户“被动”完成操作，开发者需主动验证每一次操作的“发起者身份”。

• CSRF Token 是一种服务器端校验机制：

  - 每个用户请求页面时服务器生成一个不可预测的 token
  - 该 token 被写入 HTML 页面（如表单）
  - 请求提交时，客户端将 token 带上（作为参数或 header）
  - 服务器检查 token 是否匹配、有效，决定是否放行
  

• 优点：

  - 与浏览器行为无关
  - 与请求方式无关（GET/POST/PUT）
  - 与 Cookie 无关（可用于 token-based 身份验证）
  

• 防御

核心防御	深度防御	框架优先	监控审计
- 敏感操作使用 CSRF Token - 关键Cookie设置SameSite=Lax/Strict		- 使用框架内置CSRF保护 - 保持框架安全更新	- 记录Token验证失败 - 监控异常操作模式 - 定期安全扫描

现代浏览器API

• Service Worker：离线缓存、消息推送（PWA核心）
• WebAssembly：高性能代码执行（C++/Rust编译运行）

五、前端开发必知实践

1. DOM操作优化
   • 使用document.createDocumentFragment()批量操作节点
   • 读写分离：避免交替读布局属性（如offsetHeight）和写样式，触发强制重排。
2. 渲染性能工具
   • Chrome DevTools：
   • Performance面板分析帧率
   • Layers视图检查合成层
   • Coverage定位未使用CSS/JS