阅读视图

发现新文章,点击刷新页面。

手把手写几种常用工具函数:深拷贝、去重、扁平化

同学们好,我是 Eugene(尤金),一个拥有多年中后台开发经验的前端工程师~

(Eugene 发音很简单,/juːˈdʒiːn/,大家怎么顺口怎么叫就好)

你是否也有过:明明学过很多技术,一到关键时候却讲不出来、甚至写不出来?

你是否也曾怀疑自己,是不是太笨了,明明感觉会,却总差一口气?

就算想沉下心从头梳理,可工作那么忙,回家还要陪伴家人。

一天只有24小时,时间永远不够用,常常感到力不从心。

技术行业,本就是逆水行舟,不进则退。

如果你也有同样的困扰,别慌。

从现在开始,跟着我一起心态归零,利用碎片时间,来一次彻彻底底的基础扫盲

这一次,我们一起慢慢来,扎扎实实变强。

不搞花里胡哨的理论堆砌,只分享看得懂、用得上的前端干货,

咱们一起稳步积累,真正摆脱“面向搜索引擎写代码”的尴尬。

1. 开篇:有库可用,为什么还要自己写?

lodashramda 等库已经提供这些工具函数,但在面试、基础补强、和「读懂库源码」的场景里,手写一遍很有价值:

  • 搞清概念:什么算「深拷贝」、什么算「去重」
  • 踩一遍坑:循环引用、NaNDateRegExpSymbol
  • 形成习惯:知道什么时候用浅拷贝、什么时候必须深拷贝

下面按「深拷贝 → 去重 → 扁平化」的顺序,每种都给出可直接用的实现和说明。

2. 深拷贝

2.1 浅拷贝 vs 深拷贝,怎么选?

场景 推荐方式 原因
只改最外层、不改嵌套对象 浅拷贝({...obj}Object.assign 实现简单、性能好
需要改嵌套对象且不想影响原数据 深拷贝 避免引用共享
对象里有 DateRegExp、函数等 深拷贝时需特殊处理 否则会丢失类型或行为

一句话:只要会改到「嵌套对象/数组」,就考虑深拷贝。

2.2 常见坑

  1. 循环引用obj.a = obj,递归会栈溢出
  2. 特殊类型DateRegExpMapSetSymbol 不能只靠遍历属性复制
  3. Symbol 做 keyObject.keys 不会包含,需用 Reflect.ownKeysObject.getOwnPropertySymbols

2.3 实现示例(含循环引用与特殊类型处理)

function deepClone(obj, cache = new WeakMap()) {
  // 1. 基本类型、null、函数 直接返回
  if (obj === null || typeof obj !== 'object') {
    return obj;
  }

  // 2. 循环引用:用 WeakMap 缓存已拷贝对象
  if (cache.has(obj)) {
    return cache.get(obj);
  }

  // 3. 特殊对象类型
  if (obj instanceof Date) return new Date(obj.getTime());
  if (obj instanceof RegExp) return new RegExp(obj.source, obj.flags);
  if (obj instanceof Map) {
    const mapCopy = new Map();
    cache.set(obj, mapCopy);
    obj.forEach((v, k) => mapCopy.set(deepClone(k, cache), deepClone(v, cache)));
    return mapCopy;
  }
  if (obj instanceof Set) {
    const setCopy = new Set();
    cache.set(obj, setCopy);
    obj.forEach(v => setCopy.add(deepClone(v, cache)));
    return setCopy;
  }

  // 4. 普通对象 / 数组
  const clone = Array.isArray(obj) ? [] : {};
  cache.set(obj, clone);

  // 包含 Symbol 作为 key
  const keys = [...Object.keys(obj), ...Object.getOwnPropertySymbols(obj)];
  keys.forEach(key => {
    clone[key] = deepClone(obj[key], cache);
  });

  return clone;
}

// 使用示例
const original = { a: 1, b: { c: 2 }, d: [3, 4] };
original.self = original; // 循环引用
const cloned = deepClone(original);
cloned.b.c = 999;
console.log(original.b.c); // 2,原对象未被修改

要点:WeakMap 解决循环引用,Date/RegExp/Map/Set 单独分支,Object.getOwnPropertySymbols 保证 Symbol key 不丢失。

3. 去重

3.1 场景与选型

场景 方法 说明
基本类型数组(数字、字符串) Set 写法简单、性能好
需要兼容 NaN 自己写遍历逻辑 NaN !== NaNSet 能去重 NaN,但逻辑要显式写清楚
对象数组、按某字段去重 Mapfilter 用唯一字段做 key

3.2 几种实现

1)简单数组去重(含 NaN)

// 方式一:Set(ES6 最常用)
function uniqueBySet(arr) {
  return [...new Set(arr)];
}

// 方式二:filter + indexOf(兼容性更好,但 NaN 会出问题)
function uniqueByFilter(arr) {
  return arr.filter((item, index) => arr.indexOf(item) === index);
}

// 方式三:兼容 NaN 的版本
function unique(arr) {
  const result = [];
  const seenNaN = false; // 用 flag 标记是否已经加入过 NaN
  for (const item of arr) {
    if (item !== item) { // NaN !== NaN
      if (!seenNaN) {
        result.push(item);
        seenNaN = true; // 这里需要闭包,下面用修正版
      }
    } else if (!result.includes(item)) {
      result.push(item);
    }
  }
  return result;
}

// 修正:用变量
function uniqueWithNaN(arr) {
  const result = [];
  let hasNaN = false;
  for (const item of arr) {
    if (Number.isNaN(item)) {
      if (!hasNaN) {
        result.push(NaN);
        hasNaN = true;
      }
    } else if (!result.includes(item)) {
      result.push(item);
    }
  }
  return result;
}

注意:Set 本身对 NaN 是去重的(ES2015 规范),所以 [...new Set([1, NaN, 2, NaN])] 结果正确。需要兼容 NaN 的,多是旧环境或面试题场景。

2)对象数组按某字段去重

function uniqueByKey(arr, key) {
  const seen = new Map();
  return arr.filter(item => {
    const k = item[key];
    if (seen.has(k)) return false;
    seen.set(k, true);
    return true;
  });
}

// 使用
const users = [
  { id: 1, name: '张三' },
  { id: 2, name: '李四' },
  { id: 1, name: '张三2' }
];
console.log(uniqueByKey(users, 'id'));
// [{ id: 1, name: '张三' }, { id: 2, name: '李四' }]

4. 扁平化

4.1 场景

  • [1, [2, [3, 4]]] 变成 [1, 2, 3, 4]
  • 有时候需要「只扁平一层」或「扁平到指定层数」

4.2 实现

1)递归全扁平

function flatten(arr) {
  const result = [];
  for (const item of arr) {
    if (Array.isArray(item)) {
      result.push(...flatten(item));
    } else {
      result.push(item);
    }
  }
  return result;
}

console.log(flatten([1, [2, [3, 4], 5]])); // [1, 2, 3, 4, 5]

2)指定深度扁平(如 Array.prototype.flat)

function flattenDepth(arr, depth = 1) {
  if (depth <= 0) return arr;

  const result = [];
  for (const item of arr) {
    if (Array.isArray(item) && depth > 0) {
      result.push(...flattenDepth(item, depth - 1));
    } else {
      result.push(item);
    }
  }
  return result;
}

console.log(flattenDepth([1, [2, [3, 4]]], 1)); // [1, 2, [3, 4]]
console.log(flattenDepth([1, [2, [3, 4]]], 2)); // [1, 2, 3, 4]

3)用 reduce 递归写法(另一种常见写法)

function flattenByReduce(arr) {
  return arr.reduce((acc, cur) => {
    return acc.concat(Array.isArray(cur) ? flattenByReduce(cur) : cur);
  }, []);
}

5. 小结:日常怎么选

函数 生产环境 面试 / 巩固基础
深拷贝 优先用 structuredClone(支持循环引用)或 lodash cloneDeep 自己实现,要处理循环引用和特殊类型
去重 基本类型用 [...new Set(arr)],对象用 Map 按 key 去重 要能解释 NaNindexOf 等细节
扁平化 用原生 arr.flat(Infinity) 手写递归或 reduce 版本

自己写一遍的价值在于:搞清楚边界情况、循环引用、特殊类型,以后选库或读源码时心里有数。


学习本就是一场持久战,不需要急着一口吃成胖子。哪怕今天你只记住了一点点,这都是实打实的进步。

后续我还会继续用这种大白话、讲实战方式,带大家扫盲更多前端基础。

关注我,不迷路,咱们把那些曾经模糊的知识点,一个个彻底搞清楚。

如果你觉得这篇内容对你有帮助,不妨点赞收藏,下次写代码卡壳时,拿出来翻一翻,比搜引擎更靠谱。

我是 Eugene,你的电子学友,我们下一篇干货见~

BFC布局

在前端开发的历史长河中,CSS 布局一直是重难点。很多初学者甚至有经验的开发者,在面对“父元素高度塌陷”、“外边距合并”或是“文字环绕”等问题时,往往通过死记硬背 overflow: hidden 或 clearfix 来解决,却知其然不知其所以然。

这一切背后的核心机制,就是 BFC(Block Formatting Context,块级格式化上下文) 。本文将从浏览器渲染机制的角度,带你彻底理解这一概念。

一、引言:从“消失的背景”说起

我们先来看一个经典的 CSS 布局“Bug”。

现象复现

我们构建一个父容器 .container(绿色背景)和一个子元素 .box(红色背景,左浮动)。

Html

<div class="container">
  <div class="box"></div>
</div>

CSS

.container {
  background-color: green;
  /* 此时未设置高度,期望由子元素撑开 */
}

.box {
  width: 100px;
  height: 100px;
  background-color: red;
  float: left; /* 子元素浮动 */
}

运行结果:  绿色背景消失了。父容器的高度变成了 0。

原理解析

这是典型的 父元素高度塌陷
原因在于 CSS 的 文档流(Normal Flow)  机制。当元素设置了 float 属性后,它会 脱离文档流。对于父容器而言,在计算自身高度时,默认只计算文档流内的元素。由于 .box 已经“漂”在了上面,父容器认为自己内部是空的,因此高度为 0。

要解决这个问题,我们需要强制父容器在计算高度时,将浮动元素也包含在内。这正是 BFC 的核心能力之一。

二、深度解析:什么是 BFC

BFC (Block Formatting Context) ,直译为“块级格式化上下文”。

不要被这个学术名词吓到。从渲染引擎的角度来看,BFC 就是一个 独立的、隔离的渲染区域

你可以将其理解为一个个封闭的“箱子”或“结界”。在这个箱子里,有一套属于自己的布局规则。

BFC 的核心渲染规则

  1. 内部隔离:BFC 内部的元素布局不会影响到外部的元素,反之亦然。
  2. 高度计算:计算 BFC 的高度时,浮动元素也参与计算(解决高度塌陷的核心)。
  3. 布局互斥:BFC 的区域不会与 float 盒子重叠(两栏布局的核心)。
  4. 垂直排列:内部的 Box 会在垂直方向,一个接一个地放置。
  5. Margin 合并:属于同一个 BFC 的两个相邻 Box 的垂直 Margin 会发生重叠。

如何触发 BFC(召唤结界)

BFC 不是一个可以直接设置的属性(例如没有 bf-context: true),而是通过特定的 CSS 属性隐式触发的。

以下是常见的触发方式及其副作用对比:

触发方式 属性值 副作用评估 推荐指数
现代标准 display: flow-root 无副作用。这是 CSS3 专门为触发 BFC 设计的属性。 ⭐⭐⭐⭐⭐
常用方案 overflow: hidden / auto 内容溢出时会被裁剪或出现滚动条。 ⭐⭐⭐⭐
布局方案 display: flex / grid 改变了子元素的布局模式(从块级变为弹性/网格项)。 ⭐⭐⭐
定位方案 position: absolute / fixed 元素脱离文档流,宽度可能坍塌。 ⭐⭐
浮动方案 float: left / right 元素脱离文档流,影响后续兄弟元素。 ⭐⭐

注意:  很多资料会提到 position: absolute 会触发 BFC。确实如此,但请注意,BFC 仅处理文档流和浮动流的布局关系。BFC 本身并不会成为绝对定位元素的包含块(Containing Block) ,除非该元素同时设置了 position: relative/absolute。

三、实战演练:BFC 能解决什么问题

1. 清除浮动(解决高度塌陷)

场景:如引言所述,父元素高度为 0。
原理:利用 BFC 规则—— “计算 BFC 的高度时,浮动元素也参与计算”

CSS

.container {
  background-color: green;
  /* 触发 BFC */
  display: flow-root; 
  /* 或者使用兼容性更好的 overflow: hidden; */
}

.box {
  float: left;
  width: 100px;
  height: 100px;
  background-color: red;
}

结果:父容器高度被撑开,绿色背景正常显示。


2. 防止 Margin 重叠(外边距合并)

场景:两个相邻的 div,上一个 margin-bottom: 20px,下一个 margin-top: 20px。
现象:实际间距是 20px,而不是 40px。这是 CSS 的默认行为(Margin Collapse)。

原理:利用 BFC 规则—— “BFC 就是一个隔离容器” 。只有属于 同一个 BFC 的子元素才会发生 Margin 合并。如果我们让其中一个元素处于 另一个 BFC 中,合并就会被阻断。

Html

<div class="box">Box 1</div>

<!-- 创建一个 BFC 容器包裹 Box 2 -->
<div class="bfc-wrapper">
  <div class="box">Box 2</div>
</div>

CSS

.box {
  margin: 20px 0;
  height: 50px;
  background: blue;
}

.bfc-wrapper {
  /* 触发 BFC,形成隔离墙 */
  display: flow-root; 
}

结果:两个盒子之间的间距变为 40px。


3. 自适应两栏布局(防止文字环绕)

场景:左侧固定宽度浮动,右侧不设宽度(自适应)。
现象:如果不处理,右侧的文字会环绕在左侧浮动元素的下方(像报纸排版一样)。虽然这是 float 设计的初衷,但在布局应用中通常是不被希望的。

原理:利用 BFC 规则—— “BFC 的区域不会与 float 盒子重叠” 。当右侧元素触发 BFC 后,它会像一堵墙一样,把自己限制在浮动元素的旁边,不再“钻”到浮动元素底下。

Html

<div class="layout">
  <div class="sidebar">左侧浮动</div>
  <div class="main">右侧内容区(自适应)</div>
</div>

CSS

.sidebar {
  float: left;
  width: 200px;
  background: lightblue;
  height: 300px;
}

.main {
  /* 关键点:触发 BFC */
  display: flow-root; 
  /* 若不触发 BFC,main 的内容会环绕 sidebar,且背景色会延伸到 sidebar 下方 */
  
  background: lightcoral;
  height: 400px;
}

结果:.main 区域会自动计算剩余宽度,且与 .sidebar 泾渭分明,形成标准的左右两栏布局。

四、面试指北:满分回答模版

面试官提问:“请说说你对 BFC 的理解,它有什么用,怎么触发?”

参考回答:

1. 定义核心:
BFC 全称是块级格式化上下文。从原理上讲,它是一个独立的渲染区域或隔离容器。BFC 内部的布局规则是独立的,内部元素再怎么变化也不会影响到外部的元素,反之亦然。

2. 触发方式:
触发 BFC 的方式有很多,最现代且无副作用的方式是使用 display: flow-root。
在旧项目中,最常用的是 overflow: hidden(前提是内容不需要溢出)。
此外,设置 float 不为 none,position 为 absolute/fixed,或者 display 为 flex/inline-block 等也能触发,但会带来改变元素定位或显示模式的副作用。

3. 核心应用场景:
我在实际开发中主要用它解决三个问题:

  • 清除浮动:因为 BFC 在计算高度时会包含浮动元素,可以解决父元素高度塌陷的问题。
  • 布局隔离:BFC 区域不会与浮动盒子重叠,常用于实现“左侧固定、右侧自适应”的两栏布局,防止文字环绕。
  • 解决外边距合并:通过将元素包裹在不同的 BFC 中,可以阻止垂直外边距(Margin)的合并。

字符串处理实战:模板字符串、split/join、正则的 80% 用法

前言

前端里接口参数拼接、搜索条件、富文本简单处理,几乎都绕不开字符串:拼 URL、拆 query替换/截断文案。很多人习惯用 + 拼到眼花,或者到处 indexOf/substring,写多了难维护也容易出 bug。
用**模板字符串split/join正则**这三类能力,可以把「替换/匹配」写得更短、更稳。本文用 10 个左右常见场景,把日常该怎么选、为什么这么选、容易踩的坑讲清楚,只讲 80% 会用到的部分,不求覆盖所有正则语法。

适合读者:

  • 会写 JS,但对模板字符串/正则什么时候用、怎么写有点模糊
  • 刚学 JS,希望一开始就养成清晰的字符串写法
  • 有经验的前端,想统一团队里的 URL 拼接、搜索条件、简单富文本处理

一、先搞清楚:模板字符串split/join正则分别在干什么

能力 在干什么 典型用法
模板字符串 `${} 把变量嵌进字符串,支持换行 URL、拼文案、多行字符串
split 按分隔符把字符串拆成数组 query 拆成键值对、按逗号/换行拆列表
join 把数组用分隔符拼成字符串 把参数数组拼成 query、把标签数组拼成文案
正则 按模式匹配、替换、提取 替换占位符、校验格式、简单富文本处理
// 传统 + 拼接:多参数时很难看
const url = baseUrl + '/api/user?id=' + id + '&name=' + encodeURIComponent(name);

// 模板字符串:一眼看出「URL 长什么样」
const url = `${baseUrl}/api/user?id=${id}&name=${encodeURIComponent(name)}`;

记住一点:能一眼看出「最终长什么样」就用模板字符串;要「按规则拆开或拼起来」就用 split/join;要「按模式匹配或替换」就用正则

二、模板字符串的常见用法

1. 接口 URLquery 拼接(模板字符串 + 一层编码)

应用场景

  • 你要调一个列表接口(比如商品列表、用户列表),需要把「搜索关键词」「页码」「每页显示多少条」这些信息拼在接口地址后面,比如拼出 ?keyword=张三&page=1&pageSize=10 这种格式。

先搞懂一个核心问题:为啥不能直接拼?

  • 就像咱们寄快递要写规范的地址(省 - 市 - 区 - 街道),URL(接口地址)也有自己的「书写规范」—— 有些字符(比如中文、空格、&、=)直接写进去,服务器会 “看不懂”,甚至理解错意思。

举个最直白的例子

你要搜「用户 输入」(关键词里有空格),如果直接拼地址:/api/list?keyword=用户 输入&page=1

服务器会把「空格」当成 “参数分隔符”,以为「keyword = 用户」是一个参数,「输入 & page=1」是另一个参数,直接解析错了!

const baseUrl = '/api/list'; // 接口基础地址
const params = {
  keyword: '用户 输入',  // 要搜索的关键词(有中文+空格,是“违规字符”)
  page: 1,              // 第1页
  pageSize: 10          // 每页显示10条
};

// ✅ 推荐写法:用 URLSearchParams 当“翻译官”(自动处理违规字符)
// 你可以把 URLSearchParams 理解成:专门处理URL参数的“小工具”
const query = new URLSearchParams({
  keyword: params.keyword,
  page: String(params.page),    // 这个小工具只认字符串,数字要转一下
  pageSize: String(params.pageSize),
}).toString(); // 把处理好的参数转成字符串

// 用模板字符串拼最终地址,结构一眼能看懂
const url = `${baseUrl}?${query}`;
console.log('自动处理后的地址:', url);
// 输出:/api/list?keyword=%E7%94%A8%E6%88%B7+%E8%BE%93%E5%85%A5&page=1&pageSize=10
// 你看:“用户 输入”被翻译成了 %E7%94%A8%E6%88%B7+%E8%BE%93%E5%85%A5,服务器能看懂了!

// ❌ 反面示例:直接拼(不翻译违规字符)—— 服务器看不懂
const badUrl1 = `${baseUrl}?keyword=${params.keyword}&page=${params.page}&pageSize=${params.pageSize}`;
console.log('直接拼的错误地址:', badUrl1);
// 输出:/api/list?keyword=用户 输入&page=1&pageSize=10(空格、中文没翻译,服务器解析错)

// ⚠️ 手动翻译写法(麻烦,容易漏):
// encodeURIComponent 就是“单个字符翻译器”,只能翻译一个参数值
const encodedKeyword = encodeURIComponent(params.keyword); // 只翻译关键词
const encodedPage = encodeURIComponent(params.page);       // 翻译页码
const encodedPageSize = encodeURIComponent(params.pageSize); // 翻译每页条数
const goodUrlByHand = `${baseUrl}?keyword=${encodedKeyword}&page=${encodedPage}&pageSize=${encodedPageSize}`;
console.log('手动翻译的正确地址:', goodUrlByHand);
// 输出和自动处理的一样,但要写3次 encodeURIComponent,参数多了容易漏!

更直观的表格说明

名词 小白版解释 什么时候用
encodeURIComponent 单个 URL 参数的 “翻译器”:把中文、空格这些服务器看不懂的字符,翻译成服务器能懂的 “编码”(比如把 “用户” 译成 % E7%94% A8% E6%88% B7 手动拼接 URL 参数时,给每个参数值单独翻译
URLSearchParams 批量处理 URL 参数的 “智能翻译机”:你把所有参数丢给它,它会自动调用 encodeURIComponent 给每个参数翻译,还能拼成规范的参数串 推荐优先用!不管参数多少,一次搞定,不翻车

关键注意点(小白必看)

  1. 只要参数里有中文空格&= 这些字符,就必须 “翻译”,否则接口会调失败 / 返回错误数据;
  2. URLSearchParams 是 “懒人神器”:不用记 encodeURIComponent 怎么写,不用怕漏翻译某个参数,丢进去就自动处理;
  3. 小细节:URLSearchParams 只认字符串,所以数字类型的参数(比如 page:1)要转成 String (page),否则会报错。

2. 搜索条件:有值才带参数(过滤掉空值再拼)

场景: 只有 keyword 有值才带 keyword,只有 status 有值才带 status,避免 ?keyword=&status= 这种无意义参数。

const baseUrl = '/api/search';
const search = {
  keyword: '张三',  // 有实际值
  status: '',       // 空值(无意义)
  type: '1',        // 有实际值
};

// 第一步:筛选出非空的参数(去掉空字符串、全空格、null/undefined)
// Object.entries:把对象拆成[key, value]的数组,方便批量检查
// filter:筛选器,只留满足条件的参数
// trim():去掉字符串前后空格(比如用户只输空格也算空值)
const filtered = Object.fromEntries(
  Object.entries(search).filter(([_, value]) => {
    // 条件:值不是null/undefined,且去掉空格后不是空字符串
    return value != null && String(value).trim() !== '';
  })
);

// 第二步:用URLSearchParams自动编码参数,转成query字符串
const query = new URLSearchParams(filtered).toString();

// 第三步:拼接最终URL(有参数加?,没参数直接用基础地址)
const url = query ? `${baseUrl}?${query}` : baseUrl;
// 最终结果:/api/search?keyword=%E5%BC%A0%E4%B8%89&type=1
// 对比:如果没过滤,会是 /api/search?keyword=%E5%BC%A0%E4%B8%89&status=&type=1(多了无用的status=)
);
const query = new URLSearchParams(filtered).toString();
const url = query ? `${baseUrl}?${query}` : baseUrl;
// /api/search?keyword=%E5%BC%A0%E4%B8%89&type=1

核心名词小白解释:

代码片段 通俗理解
Object.entries(search) {keyword:'张三', status:'', type:'1'}拆成[['keyword','张三'], ['status',''], ['type','1']],方便逐个检查值是否为空
Object.fromEntries(数组) 把筛选后的数组(比如[['keyword','张三'], ['type','1']])还原成对象{keyword:'张三', type:'1'}
value.trim() 去掉字符串前后的空格,比如' 张三 '变'张三',' '变空字符串(避免 “只输空格” 被当成有效值)
filter(...) 只保留 “非空” 的参数,把status:''这种空值过滤掉

适用: 列表筛选项、搜索表单、任何「按条件带参」的接口。


3. 多行字符串、拼文案(模板字符串天然支持换行)

场景: 弹窗文案、邮件正文、多行提示。

const userName = '李四';
const count = 3;

const message = `尊敬的 ${userName}:
您有 ${count} 条待处理消息,请及时查看。`;
// 换行、变量都保留,不用 \n 和 + 拼

三、split / join 的常见用法

1. 把 URL 上的 search 拆成对象(split + 一次遍历)

场景:?id=1&name=test 得到 { id: '1', name: 'test' }

const search = '?id=1&name=test';

// 推荐:直接用 URLSearchParams 解析(和上面「拼」对应)
const params = Object.fromEntries(new URLSearchParams(search));
// { id: '1', name: 'test' }

// 若不能用地道 API,再用 split
const params2 = search
  .replace(/^\?/, '')
  .split('&')
  .reduce((acc, pair) => {
    const [key, value] = pair.split('=');
    acc[decodeURIComponent(key)] = decodeURIComponent(value ?? '');
    return acc;
  }, {});

注意: 值里可能带 =,所以「按第一个 = 拆」更稳,这里用 split('=') 只适合简单 value;复杂 query 建议统一用 URLSearchParams


2. 把「逗号分隔的 id」拆成数组,再拼回去(split + join)

场景: 接口返回 ids: "1,2,3",要转成数组处理;提交时再拼成 "1,2,3"

const idsStr = '1,2,3';

const ids = idsStr.split(',').map((id) => id.trim()).filter(Boolean);
// ['1', '2', '3']

// 提交时再拼回去
const idsStrAgain = ids.join(',');
// '1,2,3'

注意: split(',') 后习惯加 .map(s => s.trim()).filter(Boolean),避免空串和前后空格。


3. 按换行拆成数组(split('\n'))

场景: 用户输入多行标签、多行关键词,一行一个。

const input = '  tag1  \ntag2\n  tag3  ';
const tags = input.split('\n').map((s) => s.trim()).filter(Boolean);
// ['tag1', 'tag2', 'tag3']

四、正则的 80% 用法(小白友好版:从基础到实战)

先搞懂:正则的 “基础积木”(小白版) 先记住这几个最常用的符号,就像搭积木一样,组合起来就能实现大部分匹配 / 替换需求:

符号 / 语法 小白版解释 举例子
/内容/ 正则的 “容器”,所有匹配规则都写在两个/之间 /abc/ 表示匹配字符串里的 abc
/内容/g g = global(全局),表示匹配所有符合规则的内容,不是只匹配第一个 'aaa'.replace(/a/g, 'b')bbb(不加 g 只替换第一个 a,变成 baa
\w 匹配「字母、数字、下划线」(简单记:匹配 “单词字符”) /\w+/能匹配 name123order_001
\d 匹配「单个数字」(0-9) /\d/匹配 5/\d\d/ 匹配88
+ 表示 “前面的规则至少出现 1 次” /\d+/ 匹配 1 个或多个数字(比如 1123
* 表示 “前面的规则出现 0 次或多次”(用得少,优先记+ /\d*/ 能匹配空字符串1123
{n} 表示 “前面的规则正好出现 n 次” /\d{10}/匹配正好 10 个数字
^ 匹配 “字符串的开头”(锚定开头) /^1/只匹配以 1开头的字符串(比如 1380000 能匹配,a138 不能)
$ 匹配 “字符串的结尾”(锚定结尾) /\d$/ 只匹配以数字结尾的字符串
[^>] [] 表示 “匹配其中任意一个字符”,^ [] 里表示 “排除” /[^>]+/匹配 “除了 > 之外的任意字符,至少 1 个”
() 捕获组:把匹配到的内容 “抓出来”,后续能用到 /\{(\w+)\}/ 里的 (\w+) 会把 {name} 里的 name 抓出来
有没有同学看不懂 /\{(\w+)\}/ 的?

看这里:

  • \ 是转义符:正则里想匹配 {} / [] / () 等特殊符号本身时,必须加\
  • /\{(\w+)\}/ 的核心是匹配 {xxx} 格式的字符串,其中:
    • \{ / \} 匹配普通的{}
    • (\w+) 抓出 {} 中间的字母 / 数字 / 下划线(比如 name);
  • 新手写正则时,只要想匹配 “特殊符号本身”,先加 \ 转义,就不会出错。

用法 1:占位符替换(把 {name} 换成真实值)

场景:服务端返回模板 " 您好,{name},您的订单{orderId}已发货 ",前端替换成当前用户和订单。 步骤拆解(小白能懂):

1. 规则/\{(\w+)\}/g 解析:

  • \{:匹配左大括号 {(因为 { 是正则特殊符号,要加\ 转义,告诉正则 “这就是普通的 {”);
  • (\w+):捕获组,匹配字母 / 数字 / 下划线(比如 nameorderId),并把匹配结果存起来;
  • \}:匹配右大括号 }
  • g:全局匹配,把所有 {xxx} 都找出来。

2. replace 回调函数:(_, key) => data[key] ?? ''

  • 第一个参数 _:表示整个匹配的内容(比如 {name}),用不到就用 _ 占位;
  • 第二个参数 key:就是捕获组 (\w+) 抓到的内容(比如 name);
  • data[key] ?? '':从 data 里取对应的值,没有就用空串填充。
const template = '您好,{name},您的订单{orderId}已发货';
const data = { name: '王五', orderId: 'ORD001' };

// 核心代码
const result = template.replace(/\{(\w+)\}/g, (_, key) => data[key] ?? '');
console.log(result); // 输出:'您好,王五,您的订单ORD001已发货'

// 小白试错:如果不加g,只会替换第一个占位符
const badResult = template.replace(/\{(\w+)\}/, (_, key) => data[key] ?? '');
console.log(badResult); // 输出:'您好,王五,您的订单{orderId}已发货'

用法 2:富文本简单处理:去掉 HTML 标签只留纯文本

**场景:**列表摘要只展示纯文本,需要把 <p>xxx</p> 里的 xxx 拿出来,或去掉所有标签。 规则 /<[^>]+>/g 解析

  • <:匹配左尖括号;
  • [^>]+:匹配 “除了>之外的任意字符,至少 1 个”(比如 pstrongdiv class="title");
  • >:匹配右尖括号;
  • g:全局替换,把所有标签都去掉。
const html = '<p>这是一段<strong>加粗</strong>的文字&nbsp;还有空格</p>';

// 第一步:去掉所有HTML标签
const textWithoutTag = html.replace(/<[^>]+>/g, '');
console.log(textWithoutTag); // 输出:'这是一段加粗的文字&nbsp;还有空格'

// 第二步:还原常见的HTML实体(比如&nbsp;换成空格)
const text = textWithoutTag
  .replace(/&nbsp;/g, ' ')  // 空格实体转空格
  .replace(/&lt;/g, '<')    // < 实体转 <
  .replace(/&gt;/g, '>');   // > 实体转 >
console.log(text); // 输出:'这是一段加粗的文字 还有空格'

⚠️ 重要提醒:这个规则只适合「简单、可控」的富文本(比如自己系统生成的短文本)。如果是复杂 HTML(比如带注释、<script>标签、属性里有>的),正则会失效,建议用 DOM 或专业库(如 cheerio)处理。

用法 3:富文本简单处理:限制摘要长度(截断 + 省略号)

场景:列表里摘要最多显示 20 个字符,超出用 ...。 (先去标签再截断,避免截到标签中间,比如把<p>这是一段很长的文字</p>截成 <p>这是一段很长的文,导致标签不闭合)

// 封装成通用函数,小白直接用
const getSummary = (html, maxLen = 20) => {
  // 第一步:先去标签和还原实体
  const pureText = html
    .replace(/<[^>]+>/g, '')
    .replace(/&nbsp;/g, ' ')
    .replace(/&lt;/g, '<')
    .replace(/&gt;/g, '>');
  // 第二步:判断长度,截断加省略号
  if (pureText.length > maxLen) {
    return pureText.slice(0, maxLen) + '...';
  }
  return pureText;
};

// 测试
const longHtml = '<div>这是一段非常非常长的富文本内容,需要截断显示</div>';
console.log(getSummary(longHtml, 10)); // 输出:'这是一段非常非常长...'

用法 4:简单格式校验(手机号、纯数字)

场景:表单里「手机号」「纯数字」的简单校验,用 正则.test(要校验的字符串),返回 true/false

1. 手机号校验

规则 /^1\d{10}$/ 解析:

  • ^:字符串开头;
  • 1:第一个字符必须是 1(手机号开头都是 1);
  • \d{10}:后面跟正好 10 个数字;
  • $:字符串结尾; → 整体表示:整个字符串必须是 “1 + 10 个数字”,长度正好 11 位。
// 封装手机号校验函数
const isPhoneValid = (phone) => {
  // 先排除空值、非字符串情况
  if (!phone || typeof phone !== 'string') return false;
  return /^1\d{10}$/.test(phone);
};

// 测试
console.log(isPhoneValid('13800138000')); // true(正确手机号)
console.log(isPhoneValid('1380013800'));  // false(只有10位)
console.log(isPhoneValid('12345678901')); // false(开头不是1)
console.log(isPhoneValid('1380013800a')); // false(包含字母)

2. 纯数字校验

规则 /^1\d{10}$/ 解析:

  • ^:开头;
  • \d+:至少 1 个数字;
  • \d{10}:后面跟正好 10 个数字;
  • $:结尾; → 整体表示:整个字符串只能是数字,不能有其他字符,且不能为空。
// 封装纯数字校验函数
const isPureNumber = (str) => {
  if (!str) return false; // 空串返回false
  return /^\d+$/.test(str);
};

// 测试
console.log(isPureNumber('12345')); // true
console.log(isPureNumber('123a5')); // false(含字母)
console.log(isPureNumber(''));      // false(空串)
console.log(isPureNumber('0'));     // true(单个0也符合)

用法总结

  1. 正则小白不用记所有语法,先掌握 /内容/g\w/\d+/{n}^/$() 这几个核心符号,就能搞定大部分场景;
  2. 正则的核心用法分 3 类:替换(replace)、校验(test)、提取(match),其中替换和校验是日常用得最多的;
  3. 写正则时,先拆解 “要匹配什么 / 排除什么”,再用基础符号组合,优先加 g(全局)、^/``$`(整串匹配)避免漏匹配 / 错匹配;
  4. 复杂 HTML 处理别用正则,优先用 DOM 或专业库,正则只适合简单片段。

五、容易踩的坑

1. 模板字符串里要算表达式,用 ${} 包起来

const a = 1, b = 2;
const wrong = `${a} + ${b} = a + b`;   // '1 + 2 = a + b'
const right = `${a} + ${b} = ${a + b}`; // '1 + 2 = 3'

2. query 里的中文、空格、特殊字符必须编码

const name = '张 三';
const bad = `/api?name=${name}`;  // 空格和中文会破坏 URL
const good = `/api?name=${encodeURIComponent(name)}`;
// 或统一用 URLSearchParams

3. split 不传参时按每个字符拆

'abc'.split();   // ['abc']
'abc'.split(''); // ['a','b','c']

要按「分隔符」拆就明确传参,例如 split(',')split('\n')


4. 空字符串 split 得到的是 ['']

''.split(',');   // ['']
''.split(',').filter(Boolean); // []

拼 query、拼列表前若可能为空,先判断或 filter(Boolean),避免出现 ?key= 或末尾多余逗号。


5. 正则「去标签」不能覆盖所有 HTML 情况

// 像 <div class="a"> 这种可以匹配
// 但 <script>...</script>、注释、属性里的 > 等,正则容易出错

仅用于「自己能控制的、结构简单的」富文本片段;其它用 DOM 或专业库。

六、实战推荐写法模板

接口 GET 参数拼接(带空值过滤):

const baseUrl = '/api/list';
const params = { keyword: '...', page: 1, pageSize: 10, status: '' };
const query = new URLSearchParams(
  Object.fromEntries(
    Object.entries(params).filter(([_, v]) => v != null && String(v).trim() !== '')
  )
).toString();
const url = query ? `${baseUrl}?${query}` : baseUrl;

从当前页 search 取参数:

const params = Object.fromEntries(new URLSearchParams(location.search));
const keyword = params.keyword ?? '';

逗号分隔字符串 ↔ 数组:

const toIds = (s) => (s ?? '').split(',').map((id) => id.trim()).filter(Boolean);
const toStr = (arr) => (arr ?? []).filter(Boolean).join(',');

简单占位符替换:

const fillTemplate = (template, data) =>
  template.replace(/\{(\w+)\}/g, (_, key) => data[key] ?? '');

富文本摘要(去标签 + 截断):

const toSummary = (html, maxLen = 20) => {
  const text = html.replace(/<[^>]+>/g, '').replace(/&nbsp;/g, ' ');
  return text.length > maxLen ? text.slice(0, maxLen) + '...' : text;
};

七、小结

场景 推荐写法
拼 URL、拼文案、多行字符串 模板字符串 `${base}?${query}`
拼/解析 query URLSearchParams + 模板字符串 或 split/reduce
有值才带参 filterURLSearchParams,再拼到 URL
逗号/换行拆成数组 split(',') / split('\n') + trim + filter(Boolean)
数组拼成字符串 join(',')
占位符替换 {key} replace(/\{(\w+)\}/g, (_, key) => data[key])
简单去 HTML 标签 replace(/<[^>]+>/g, '')(仅简单片段)
摘要截断 先去标签再 slice(0, len) + '...'
简单格式校验 /^1\d{10}$/.test(phone)

记住:拼用模板字符串 + URLSearchParams,拆用 split/URLSearchParams,替换/匹配用正则。日常写接口参数、搜索条件、简单富文本时,先想清楚是「拼、拆、还是替换/校验」,再选对应方式,代码会清晰很多,也少踩编码和空值的坑。

特别提醒:

  • query 里的中文和特殊字符一定要编码(URLSearchParamsencodeURIComponent)。
  • 空数组/空字符串在 split/join 时要考虑 filter(Boolean) 和「是否带问号」。
  • 正则只用于简单、可控的富文本;复杂 HTML 用 DOM 或专门库。

以上就是本次的学习分享,欢迎大家在评论区讨论指正,与大家共勉。

我是 Eugene,你的电子学友。

如果文章对你有帮助,别忘了点赞、收藏、加关注,你的认可是我持续输出的最大动力~

从输入URL到页面显示的完整技术流程

一、引言

在Web应用场景中,用户输入统一资源定位符(URL)到页面最终渲染显示,是一个涉及浏览器、网络协议、服务器交互的复杂技术链路。该链路涵盖URL解析、DNS域名解析、TCP/TLS连接建立、HTTP请求响应、浏览器渲染等多个核心环节,各环节紧密衔接、协同工作,直接决定了页面加载速度与交互体验。本文将从技术原理出发,系统拆解整个流程的核心机制,梳理各环节的关键技术要点,为相关技术研究、开发实践及面试备考提供严谨、客观的参考依据。

二、主体分析:从URL到页面显示的完整流程

(一)URL解析:资源定位的前置准备

URL作为Web资源的唯一标识,浏览器接收用户输入的字符串后,首先需完成URL的解析与补全,确保能够准确定位目标服务器及对应资源。该过程的核心是校验URL合法性,并拆解其核心组成部分。

浏览器会对输入字符串进行格式校验,判断其是否符合URL标准规范。若输入字符串不完整(如仅输入“www.example.com”),浏览器将自动补全协议、默认端口等必要字段,补全后为“www.example.com/”;其中,HTTPS协…

一个完整的URL结构可拆解为六个核心部分,以“www.example.com:443/path?query=…

  • 协议(scheme):即https,用于定义浏览器与服务器之间的通信规则,常用协议还包括HTTP、FTP等;

  • 域名(host):即www.example.com,作为服务器的别名,用于简化用户记忆,需通过DNS解析转换为网络可识别的IP地址;

  • 端口(port):即443,用于区分服务器上的不同服务,默认端口可省略;

  • 路径(path):即/path,用于指定服务器上具体资源的存储位置,如“/index.html”对应服务器根目录下的首页文件;

  • 查询参数(query):即?query=1,用于向服务器传递额外请求参数,多个参数以“&”分隔;

  • 锚点(hash):即#hash,用于定位页面内的具体位置,仅在浏览器本地生效,不会随HTTP请求发送至服务器。

(二)DNS查询:域名与IP的映射转换

网络通信的本质是IP地址之间的交互,服务器与客户端仅能通过IP地址识别彼此。由于IP地址具有复杂性、难记忆的特点,DNS(域名系统)应运而生,其核心功能是实现域名到IP地址的映射转换,相当于网络世界的“通讯录”。

DNS查询遵循“从近到远、从本地到远程”的顺序,优先查询本地缓存以提升查询效率,缓存未命中时再发起远程查询,完整流程如下:

  1. 浏览器DNS缓存:浏览器会缓存近期查询过的域名-IP映射关系,缓存有效期较短(通常为几分钟至几小时),查询时优先匹配,命中则直接获取IP地址;

  2. 操作系统DNS缓存:若浏览器缓存未命中,将查询操作系统自带的DNS缓存,如Windows系统的hosts缓存、Mac系统的DNS缓存;

  3. 本地hosts文件:操作系统缓存未命中时,读取本地hosts文件,该文件可手动配置域名与IP的映射关系,常用于开发测试场景(如配置“127.0.0.1 localhost”);

  4. 本地DNS服务器:以上缓存均未命中时,向本地DNS服务器(通常由网络运营商提供,如电信、联通DNS服务器)发送查询请求,运营商服务器会缓存常用域名的解析结果;

  5. 递归与迭代查询:若本地DNS服务器未缓存目标域名解析结果,将通过“递归+迭代”的方式逐层查询,依次向根域名服务器、顶级域名服务器(如.com、.cn服务器)、目标域名服务器发起请求,最终获取目标IP地址,并返回给浏览器同时进行缓存。

DNS查询的核心机制可分为递归查询与迭代查询:客户端与本地DNS服务器之间采用递归查询,即客户端仅需等待最终解析结果,由本地DNS服务器完成全程查询操作;DNS服务器之间采用迭代查询,即各服务器仅告知后续查询的目标服务器地址,不负责全程查询,直至获取最终IP地址。

(三)TCP/TLS握手:可靠安全连接的建立

获取目标服务器IP地址后,浏览器需与服务器建立通信连接,其中HTTP协议基于TCP协议实现可靠数据传输,HTTPS协议则在TCP协议之上增加TLS协议,实现数据加密与身份校验,保障通信安全。

1. TCP三次握手:可靠连接的建立

TCP(传输控制协议)的核心特性是可靠传输,三次握手是建立TCP连接的必要流程,其目的是确认双方的发送能力与接收能力均正常,避免历史延迟请求引发的错误连接,保障连接可靠性。三次握手流程如下:

  1. 客户端向服务器发送SYN报文,发起连接请求,告知服务器客户端准备建立连接;

  2. 服务器接收SYN报文后,返回SYN+ACK报文,确认接收客户端请求,同时向客户端发起连接请求;

  3. 客户端接收SYN+ACK报文后,返回ACK报文,确认接收服务器请求,完成三次握手。

三次握手的合理性可通过对比分析验证:若仅采用两次握手,服务器发送SYN+ACK报文后即确认连接建立,但无法确认客户端是否能接收自身报文,若客户端ACK报文丢失,服务器将持续等待,造成资源浪费;若采用四次握手,将在三次握手基础上增加额外确认步骤,不会提升连接可靠性,反而会增加通信延迟,降低传输效率。

2. TLS握手:安全通信的保障

HTTPS协议是HTTP协议与TLS(传输层安全协议)的结合,相比HTTP协议的明文传输,HTTPS通过TLS握手实现身份校验与数据加密,避免数据被窃取、篡改。TLS握手的核心操作如下:

  1. 加密算法协商:客户端与服务器协商一致,确定双方均支持的加密算法(如AES对称加密、RSA非对称加密),确保后续数据加密与解密可正常执行;

  2. 服务器证书校验:服务器向客户端发送由权威CA机构颁发的SSL证书,客户端校验证书的合法性(包括证书有效期、是否被篡改等),确认服务器身份的真实性,避免中间人劫持;

  3. 对称密钥生成:证书校验通过后,客户端与服务器协商生成对称密钥,后续所有HTTP请求与响应数据均通过该密钥加密/解密,兼顾安全性与传输效率;

  4. 握手完成确认:双方确认TLS握手完成,后续通信数据将采用协商好的对称密钥进行加密传输,保障通信安全。

与HTTP协议相比,HTTPS协议的核心差异的是增加了TLS握手环节,通过身份校验与数据加密,解决了HTTP协议明文传输的安全隐患。

(四)HTTP请求与响应:资源的传输交互

TCP(或TLS+TCP)连接建立完成后,浏览器向服务器发起HTTP请求,服务器接收请求并处理后,返回HTTP响应,完成Web资源的传输交互,这是整个链路中资源传递的核心环节。

1. HTTP请求报文

HTTP请求报文由请求行、请求头、空行、请求体四部分组成,简化示例如下:

GET /index.html HTTP/1.1  # 请求行:请求方法 + 资源路径 + HTTP版本
Host: www.example.com     # 请求头:传递额外请求信息
Cookie: username=test
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) Chrome/120.0.0.0
                          # 空行:分隔请求头与请求体
# 请求体:GET请求通常为空,POST请求用于传递表单等参数

常用HTTP请求方法包括:GET(用于获取Web资源,如打开页面)、POST(用于提交数据,如登录、表单提交)、PUT(用于修改资源)、DELETE(用于删除资源),不同请求方法对应不同的服务器处理逻辑。

2. HTTP响应报文

HTTP响应报文与请求报文对应,由响应行、响应头、空行、响应体四部分组成,简化示例如下:

HTTP/1.1 200 OK          # 响应行:HTTP版本 + 状态码 + 状态描述
Content-Type: text/html  # 响应头:传递资源相关信息
Content-Length: 1024
Cache-Control: max-age=3600

<html><head><title>示例页面</title></head><body>...</body></html>  # 响应体:核心Web资源

3. 常见HTTP状态码

HTTP状态码用于告知浏览器请求处理结果,分为5大类,核心常用状态码如下:

  • 200 OK:请求处理成功,服务器正常返回目标资源,是最常见的状态码;

  • 301 永久重定向:请求的资源已永久迁移至新地址,浏览器将自动跳转至新地址;

  • 302 临时重定向:请求的资源临时迁移至新地址,跳转行为仅在本次请求有效;

  • 304 Not Modified:目标资源未发生修改,浏览器可直接使用本地缓存,提升加载速度;

  • 404 Not Found:请求的资源不存在,通常由URL输入错误、资源被删除导致;

  • 500 Internal Server Error:服务器内部出现错误(如代码报错、服务器宕机),与客户端请求无关。

(五)浏览器解析:渲染前置的结构构建

浏览器接收服务器返回的HTTP响应后,若响应体为HTML资源,不会直接渲染显示,需先完成HTML、CSS、JS的解析,构建DOM树、CSSOM树及渲染树(Render Tree),为后续页面渲染提供基础结构,这是页面渲染的前置环节。

1. HTML解析与DOM树构建

浏览器对HTML的解析遵循自上而下、逐行解析的原则,将HTML文档中的标签、文本、属性等,转换为浏览器可识别的文档对象模型树(DOM Tree)。DOM Tree的根节点为标签,各子节点对应HTML中的各类元素,层级结构与HTML文档保持一致。

该解析过程的核心特点是:遇到未添加defer/async属性的<script>标签时,会阻塞HTML解析。原因在于JavaScript代码可能对DOM进行操作(如修改、删除DOM节点),浏览器需先执行完JavaScript代码,再继续解析后续HTML内容,避免解析结果与JS操作冲突。

2. CSS解析与CSSOM树构建

CSS解析与HTML解析可并行执行,不依赖HTML解析顺序,但会阻塞页面渲染。浏览器将页面中所有CSS样式(内联样式、内部样式、外部样式)解析后,构建CSS对象模型树(CSSOM Tree),该树明确了每个DOM节点对应的样式规则(如字体、颜色、尺寸等)。

若JavaScript代码中存在获取元素样式的操作(如getComputedStyle()),浏览器将先完成CSS解析与CSSOM树构建,再执行对应的JavaScript代码,确保JS获取的样式信息准确无误。

3. 渲染树(Render Tree)构建

DOM树与CSSOM树构建完成后,浏览器将两者合并,生成渲染树(Render Tree)。渲染树的核心特点是仅包含页面可见节点,不可见节点(如display: none属性的元素)不会被纳入渲染树,避免无效渲染;而visibility: hidden属性的元素,虽视觉上隐藏但仍占据页面布局空间,会被纳入渲染树。渲染树是后续页面布局、绘制的核心依据。

(六)页面渲染:视觉呈现的核心流程

渲染树构建完成后,浏览器通过布局(Layout)、绘制(Paint)、合成(Composite)三个依次执行的核心步骤,将Web资源渲染显示在屏幕上,形成用户最终看到的页面,该流程直接决定页面的视觉呈现效果与加载效率。

1. 布局(Layout):元素位置与尺寸的计算

布局又称回流或重排,其核心作用是根据渲染树,计算每个可见元素的位置与尺寸,包括元素的宽度、高度、left/top坐标等,明确每个元素在页面中的具体布局位置。

触发布局的常见场景包括:元素尺寸或位置修改(如修改width、height、margin属性)、页面窗口大小调整、DOM节点的添加或删除等,布局操作会触发后续绘制与合成步骤,对页面加载效率有一定影响。

2. 绘制(Paint):元素视觉样式的绘制

绘制又称重绘,其核心作用是根据布局计算的结果,在浏览器的绘制层上,为每个元素绘制视觉样式,包括颜色、边框、背景、文字、图片等,将元素的视觉属性呈现出来。

触发绘制的常见场景包括:元素视觉样式修改(如修改color、background-color、border-color属性),但元素尺寸与位置未发生变化,此时仅触发绘制与合成步骤,无需重新执行布局,效率高于布局操作。

3. 合成(Composite):分层渲染与屏幕显示

合成又称分层合成,其核心作用是将绘制完成的多个绘制层,通过GPU(图形处理器)进行分层合成,将所有绘制层整合为一个完整的页面,最终渲染显示在屏幕上。

GPU分层合成的优势在于效率高,不同绘制层相互独立,修改某一层的元素时,无需重新绘制整个页面,仅需重新合成该层即可,可显著提升页面交互的流畅度。例如,修改元素的transform属性(GPU加速属性)时,仅触发合成步骤,无需执行布局与绘制,效率最优。

(七)完整流程汇总

从输入URL到页面显示的完整技术流程可总结为:用户输入URL后,浏览器先完成URL解析与补全,明确通信协议、域名、端口等核心信息;通过DNS解析系统,将域名转换为对应的IP地址;与服务器建立TCP连接,HTTPS协议额外执行TLS握手确保通信安全;连接建立后,浏览器发送HTTP请求,服务器处理后返回HTTP响应;浏览器解析HTML构建DOM树、解析CSS构建CSSOM树,合并生成渲染树;最后通过布局、绘制、合成三个步骤,将页面渲染显示在屏幕上,完成整个流程。

(八)追问常见

1. DNS 是递归还是迭代?

DNS查询的核心机制分为递归查询与迭代查询,二者应用场景不同、职责明确:客户端与本地DNS服务器之间采用递归查询,即客户端无需参与中间查询过程,仅需等待本地DNS服务器返回最终的IP解析结果,全程由本地DNS服务器完成逐层查询操作;DNS服务器之间(包括本地DNS服务器与根域名服务器、顶级域名服务器、目标域名服务器之间)采用迭代查询,即各服务器仅向发起查询的服务器告知后续查询的目标服务器地址,不负责全程查询,直至某一服务器返回最终IP地址,查询流程终止。

2. HTTPS 比 HTTP 多了哪一步?

与HTTP协议相比,HTTPS协议的核心差异是增加了TLS(传输层安全协议)握手环节。HTTP协议基于TCP协议进行明文传输,数据易被窃取、篡改,无身份校验机制;而HTTPS协议在TCP三次握手建立连接后,会额外执行TLS握手流程,完成加密算法协商、服务器证书校验、对称密钥生成等操作,实现通信数据的加密传输与服务器身份的真实性校验,从而解决HTTP协议明文传输的安全隐患,保障网络通信的安全性。

3. TCP 三次握手为什么是三次?

TCP三次握手的核心目的是确认通信双方的发送能力与接收能力均正常,同时避免历史延迟请求引发的错误连接,保障TCP连接的可靠性,其次数设定具有明确的合理性,既不能减少为两次,也无需增加至四次。若仅采用两次握手,服务器发送SYN+ACK报文后即确认连接建立,但无法确认客户端是否能接收自身发送的报文,若客户端的ACK报文丢失,服务器会持续等待连接,造成服务器资源浪费;若采用四次握手,会在三次握手的基础上增加额外的确认步骤,该步骤无法提升连接的可靠性,反而会增加网络通信延迟,降低数据传输效率,因此三次握手是兼顾可靠性与效率的最优选择。

三、结论

从输入URL到页面显示的过程,是浏览器、网络协议与服务器协同工作的集中体现,涵盖URL解析、DNS查询、TCP/TLS连接、HTTP请求响应、浏览器解析与渲染六大核心环节,各环节环环相扣、缺一不可。其中,URL解析与DNS查询为资源定位提供基础,TCP/TLS连接保障通信的可靠与安全,HTTP请求响应实现资源传输,浏览器解析与渲染完成页面视觉呈现。

深入理解该技术流程,不仅能够帮助开发者优化页面加载速度、提升用户体验,解决开发中的各类网络与渲染相关问题,同时也是计算机网络、前端开发等领域面试的核心考点。

从输入 URL 到页面展示的完整链路解析

“从输入 URL 到页面展示,这中间发生了什么?”

这是一道计算机网络与浏览器原理的经典面试题。它看似基础,实则深不见底。对于初级开发者,可能只需要回答“DNS 解析、建立连接、下载文件、渲染页面”即可;但对于高级工程师而言,这道题考察的是对网络协议栈、浏览器多进程架构、渲染流水线以及性能优化的系统性理解。

本文将剥离表象,深入底层,以专业的视角还原这一过程的全貌。

一、 URL 解析与 DNS 查询

1. URL 结构拆解

URL(Uniform Resource Locator),统一资源定位符。浏览器首先会对用户输入的字符串进行解析。如果不符合 URL 规则,浏览器会将其视为搜索关键字传给默认搜索引擎;如果符合规则,则拆解为以下部分:

scheme://host.domain:port/path/filename?query#fragment

  • Scheme: 协议类型(HTTP/HTTPS/FTP 等)。
  • Host/Domain: 域名(如 juejin.cn)。
  • Port: 端口号(HTTP 默认为 80,HTTPS 默认为 443)。
  • Path: 资源路径。
  • Query: 查询参数。
  • Fragment: 锚点(注意:锚点不会被发送到服务器)。

2. DNS 解析流程

网络通讯是基于 TCP/IP 协议的,是通过 IP 地址而非域名进行定位。因此,浏览器的第一步是获取目标服务器的 IP 地址。

DNS 查询遵循级联缓存策略,查找顺序如下:

  1. 浏览器缓存: 浏览器会检查自身维护的 DNS 缓存。
  2. 系统缓存: 检查操作系统的 hosts 文件。
  3. 路由器缓存: 检查路由器的 DNS 记录。
  4. ISP DNS 缓存: 也就是本地 DNS 服务器(Local DNS),通常由网络服务提供商提供。

如果上述缓存均未命中,则发起递归查询迭代查询

  1. 递归查询: 客户端向本地 DNS 服务器发起请求,如果本地 DNS 不知道,它会作为代理去替客户端查询。
  2. 迭代查询: 本地 DNS 服务器依次向根域名服务器顶级域名服务器权威域名服务器发起请求,最终获取 IP 地址并返回给客户端。

进阶优化:

  • DNS Prefetch: 现代前端通过  提前解析域名,减少后续请求的延迟。
  • CDN 负载均衡: 在 DNS 解析阶段,智能 DNS 会根据用户的地理位置,返回距离用户最近的 CDN 节点 IP,而非源站 IP,从而实现内容分发加速。

二、 TCP 连接与 HTTP 请求

拿到 IP 地址后,浏览器与服务器建立连接。这是数据传输的基础。

1. TCP 三次握手

TCP(Transmission Control Protocol)提供可靠的传输服务。建立连接需要经过三次握手,确认双方的收发能力。

  • 第一次握手(SYN) : 客户端发送 SYN=1, Seq=x。客户端进入 SYN_SEND 状态。此时证明客户端有发送能力。
  • 第二次握手(SYN+ACK) : 服务端接收报文,回复 SYN=1, ACK=1, seq=y, ack=x+1。服务端进入 SYN_RCVD 状态。此时证明服务端有接收和发送能力。
  • 第三次握手(ACK) : 客户端接收报文,回复 ACK=1, seq=x+1, ack=y+1。双方进入 ESTABLISHED 状态。此时证明客户端有接收能力。

核心问题:为什么是三次而不是两次?
主要是为了防止已失效的连接请求报文段又传送到了服务端,产生错误。如果只有两次握手,服务端收到失效的 SYN 包后误以为建立了新连接,会一直等待客户端发送数据,造成资源浪费。

2. TLS/SSL 握手(HTTPS)

如果是 HTTPS 协议,在 TCP 建立后,还需要进行 TLS 四次握手以协商加密密钥(Session Key)。过程包括交换支持的加密套件、验证服务器证书、通过非对称加密交换随机数等,最终生成对称加密密钥用于后续通信。

3. 发送 HTTP 请求

连接建立完毕,浏览器构建 HTTP 请求报文并发送。

  • 请求行: 方法(GET/POST)、URL、协议版本。
  • 请求头: User-Agent、Accept、Cookie 等。
  • 请求体: POST 请求携带的数据。

服务器处理请求后,返回 HTTP 响应报文(状态行、响应头、响应体)。浏览器拿到响应体(通常是 HTML 文件),准备开始渲染。

三、 浏览器解析与渲染(核心重点)

这是前端工程师最需要关注的环节。现代浏览器采用多进程架构,主要包括Browser 进程(主控)、网络进程渲染进程

当网络进程下载完 HTML 数据后,会通过 IPC 通信将数据交给渲染进程(Renderer Process)。渲染主流程如下:

1. 解析 HTML 构建 DOM 树

浏览器无法直接理解 HTML 字符串,需要将其转化为对象模型(DOM)。
流程:Bytes(字节流) -> Characters(字符) -> Tokens(词法分析) -> Nodes(节点) -> DOM Tree

注意:遇到 

2. 解析 CSS 构建 CSSOM 树

浏览器下载 CSS 文件(.css)并解析为 CSSOM(CSS Object Model)。
关键点

  • CSS 下载不阻塞 DOM 树的解析。
  • CSS 下载阻塞 Render Tree 的构建(因此会阻塞页面渲染)。

3. 生成渲染树(Render Tree)

DOM 树与 CSSOM 树结合,生成 Render Tree。

  • 浏览器遍历 DOM 树的根节点,在 CSSOM 中找到对应的样式。
  • 忽略不可见节点:display: none 的节点不会出现在 Render Tree 中(但 visibility: hidden 的节点会存在,因为它占据空间)。
  • 去除元数据:head、script 等非视觉节点会被去除。

4. 布局(Layout / Reflow)

有了 Render Tree,浏览器已经知道有哪些节点以及样式,但还不知道它们的几何信息(位置、大小)。
布局阶段会从根节点递归计算每个元素在视口中的确切坐标和尺寸。这个过程在技术上被称为 Reflow(回流)

5. 绘制(Paint)

布局确定后,浏览器会生成绘制指令列表(如“在 x,y 处画一个红色矩形”)。这个过程并不直接显示在屏幕上,而是生成图层(Layer)的绘制记录。

6. 合成(Composite)与显示

这是现代浏览器渲染优化的核心。

  • 分层:浏览器会将页面分为不同的图层(Layer)。拥有 transform (3D)、will-change、position: fixed 等属性的元素会被提升为单独的合成层。
  • 光栅化(Raster) :合成线程将图层切分为图块(Tile),并发送给 GPU 进行光栅化(生成位图)。
  • 显示:一旦所有图块都被光栅化,浏览器会生成一个 DrawQuad 命令提交给 GPU 进程,最终将像素显示在屏幕上。

脚本阻塞与优化
为了避免 JS 阻塞 DOM 构建,可以使用 defer 和 async:

  • defer: 异步下载,文档解析完成后、DOMContentLoaded 事件前按照顺序执行。
  • async: 异步下载,下载完成后立即执行(可能打断 HTML 解析),执行顺序不固定。

四、 连接断开

当页面资源加载完毕,且不再需要通信时,通过 TCP 四次挥手 断开连接。

  1. 第一次挥手(FIN) : 主动方发送 FIN,进入 FIN_WAIT_1。
  2. 第二次挥手(ACK) : 被动方发送 ACK,进入 CLOSE_WAIT。主动方进入 FIN_WAIT_2。此时连接处于半关闭状态。
  3. 第三次挥手(FIN) : 被动方数据发送完毕,发送 FIN,进入 LAST_ACK。
  4. 第四次挥手(ACK) : 主动方发送 ACK,进入 TIME_WAIT。等待 2MSL(报文最大生存时间)后释放连接。

为什么需要 TIME_WAIT?  确保被动方收到了最后的 ACK。如果 ACK 丢失,被动方重传 FIN,主动方还能在 2MSL 内响应。

五、 面试高分指南(场景模拟)

场景:面试官问:“请详细描述从输入 URL 到页面展示发生了什么?”

回答策略范本

1. 总述(宏观骨架)
“这个过程主要分为两个阶段:网络通信阶段页面渲染阶段。网络阶段负责将 URL 转换为 IP 并获取资源,渲染阶段负责将 HTML 代码转化为像素点。”

2. 网络通信阶段(突出细节)

  • “首先是 DNS 解析。浏览器会依次查询浏览器缓存、系统 hosts、路由器缓存,最后发起递归或迭代查询拿到 IP。这里可以提到 CDN 是如何通过 DNS 实现就近访问的。”
  • “拿到 IP 后进行 TCP 三次握手 建立连接。如果是 HTTPS,还涉及 TLS 握手协商密钥。”
  • “连接建立后发送 HTTP 请求。需要注意 HTTP/1.1 的 Keep-Alive 可以复用 TCP 连接,而 HTTP/2 更是通过多路复用解决了队头阻塞问题。”

3. 页面渲染阶段(展示深度)

  • “浏览器解析 HTML 构建 DOM 树,解析 CSS 构建 CSSOM 树,两者合并生成 Render Tree。”
  • “接着进行 Layout(回流)  计算位置大小,然后进行 Paint(重绘)  生成绘制指令。”
  • “这里有一个关键点是 Composite(合成) 。现代浏览器会利用 GPU 加速,将 transform 或 opacity 的元素提升为独立图层。修改这些属性不会触发 Reflow 和 Repaint,只会触发 Composite,这是性能优化的核心。”

4. 脚本执行(补充)

  • “在解析过程中,遇到 JS 会阻塞 DOM 构建。为了优化首屏,我们通常使用 defer 属性让脚本异步加载并在 HTML 解析完成后执行。”

总结
“整个流程结束于 TCP 四次挥手断开连接。这就构成了一个完整的浏览闭环。”

深拷贝与浅拷贝的区别

在 JavaScript 的开发与面试中,深拷贝(Deep Copy)与浅拷贝(Shallow Copy)是无法绕开的高频考点。这不仅关乎数据的安全性,更直接体现了开发者对 JavaScript 内存管理模型的理解深度。本文将从底层原理出发,剖析两者的区别、实现方式及最佳实践。

一、 引言:内存中的栈与堆

要理解拷贝,首先必须理解 JavaScript 的数据存储方式。JavaScript 的数据类型分为两类:

  1. 基本数据类型(Number, String, Boolean, Null, Undefined, Symbol, BigInt):这些类型的值较小且固定,直接存储在栈内存(Stack)中。
  2. 引用数据类型(Object, Array, Function, Date 等):这些类型的值大小不固定,实体存储在堆内存(Heap)中,而在栈内存中存储的是一个指向堆内存实体的地址(指针)

当我们进行赋值操作(=)时:

  • 基本类型赋值的是值本身
  • 引用类型赋值的是内存地址

这就是深浅拷贝问题的根源:我们究竟是复制了指针,还是复制了实体?


二、 浅拷贝(Shallow Copy)详解

1. 定义

浅拷贝是创建一个新对象,这个对象有着原始对象属性值的一份精确拷贝。

  • 如果属性是基本类型,拷贝的就是基本类型的值。
  • 如果属性是引用类型,拷贝的就是内存地址
  • 核心结论:浅拷贝只复制对象的第一层,对于嵌套的对象,新旧对象共享同一块堆内存。

2. 常用实现方式

  • Object.assign()
  • 展开运算符 ...
  • Array.prototype.slice() / concat()

3. 代码演示与现象

JavaScript

const source = {
    name: 'Juejin',
    info: {
        age: 10,
        city: 'Beijing'
    }
};

// 使用展开运算符实现浅拷贝
const target = { ...source };

// 1. 修改第一层属性(基本类型)
target.name = 'Google';
console.log(source.name); // 输出: 'Juejin'
console.log(target.name); // 输出: 'Google'
// 结论:第一层互不影响

// 2. 修改嵌套层属性(引用类型)
target.info.age = 20;
console.log(source.info.age); // 输出: 20
console.log(target.info.age); // 输出: 20
// 结论:嵌套层共享引用,牵一发而动全身

三、 深拷贝(Deep Copy)详解

1. 定义

深拷贝是将一个对象从内存中完整的拷贝一份出来,从堆内存中开辟一个新的区域存放新对象,且修改新对象不会影响原对象。无论嵌套多少层,新旧对象在内存上都是完全独立的。

2. 常用实现方式

方案 A:JSON.parse(JSON.stringify())

这是最简单的深拷贝方法,适用于纯数据对象(Plain Object)。

局限性

  • 无法处理 undefined、Symbol 和函数(会丢失)。
  • 无法处理循环引用(会报错)。
  • 无法正确处理 Date(变字符串)、RegExp(变空对象)等特殊对象。

JavaScript

const source = {
    a: 1,
    b: { c: 2 }
};
const target = JSON.parse(JSON.stringify(source));

方案 B:递归实现(简易版)

通过递归遍历对象属性,如果是引用类型则再次调用拷贝函数。

JavaScript

function deepClone(obj) {
    // 处理 null 和基本类型
    if (obj === null || typeof obj !== 'object') {
        return obj;
    }

    // 初始化返回结果,兼容数组和对象
    let result = Array.isArray(obj) ? [] : {};

    for (let key in obj) {
        // 保证只拷贝自身可枚举属性
        if (obj.hasOwnProperty(key)) {
            // 递归拷贝
            result[key] = deepClone(obj[key]);
        }
    }
    return result;
}

方案 C:Web API - structuredClone

现代浏览器原生支持的深拷贝 API,支持循环引用,性能优于 JSON 序列化,但不支持函数和部分 DOM 节点。

JavaScript

const target = structuredClone(source);

3. 演示现象

JavaScript

const source = {
    info: {
        age: 10
    }
};

// 使用手写递归实现深拷贝
const target = deepClone(source);

target.info.age = 999;

console.log(source.info.age); // 输出: 10
console.log(target.info.age); // 输出: 999
// 结论:完全独立,互不干扰

四、 特点总结

特性 浅拷贝 (Shallow Copy) 深拷贝 (Deep Copy)
内存分配 仅第一层开辟新空间,嵌套层共享地址 所有层级均开辟新空间,完全独立
执行速度 慢(取决于层级深度和数据量)
实现难度 简单(原生语法支持) 复杂(需处理循环引用、特殊类型)
适用场景 状态更新、合并配置、一般的数据处理 复杂数据备份、防止副作用修改、Redux/Vuex 状态管理

五、 面试高分指南

当面试官问到:“请你说一下深拷贝和浅拷贝的区别,以及如何实现? ”时,建议按照以下逻辑结构回答,展示系统化的思维。

1. 从内存模型切入

“首先,这涉及到 JavaScript 的内存存储机制。基本数据类型存储在栈中,引用数据类型存储在堆中。
浅拷贝和深拷贝的主要区别在于复制的是引用地址还是堆内存中的实体数据。”

2. 阐述核心区别

浅拷贝只复制对象的第一层属性。如果属性是基本类型,拷贝的是值;如果是引用类型,拷贝的是内存地址。因此,修改新对象的嵌套属性会影响原对象。
深拷贝则是递归地复制所有层级,在堆内存中开辟新的空间。新旧对象在物理内存上是完全隔离的,修改任何一方都不会影响另一方。”

3. 列举实现方案

“在实际开发中:

  • 浅拷贝通常使用 Object.assign() 或 ES6 的展开运算符 ...。
  • 深拷贝最简单的方式是 JSON.parse(JSON.stringify()),但它有忽略 undefined、函数以及无法处理循环引用的缺陷。
  • 现代环境下,推荐使用 structuredClone API。
  • 在需要兼容性或处理复杂逻辑时,通常使用 Lodash 的 _.cloneDeep 或手写递归函数。”

4. 进阶亮点(加分项)

“如果需要手写一个完善的深拷贝,需要注意两个关键点:
第一,解决循环引用。比如对象 A 引用了 B,B 又引用了 A,直接递归会导致栈溢出。解决方案是使用 WeakMap 作为哈希表,存储已拷贝过的对象。每次拷贝前先检查 WeakMap,如果存在则直接返回,不再递归。
第二,处理特殊类型。除了普通对象和数组,还需要考虑 Date、RegExp、Map、Set 等类型,不能简单地通过 new obj.constructor() 处理,需要针对性地获取它们的值进行重建。”

普通函数与箭头函数的区别

在前端面试中,“箭头函数与普通函数的区别”是一道出现频率极高的基础题。然而,很多开发者仅停留在“写法更简单”或“this 指向不同”的浅层认知上。作为一名合格的前端工程师,我们需要从 JavaScript 引擎的执行机制层面,深入理解这两者的本质差异。

本文将从语法特性、运行原理、核心差异及面试实战四个维度,对这一知识点进行全方位的拆解。

第一部分:直观的代码对比(语法层)

首先,我们通过代码直观地感受两者在书写层面上的差异。箭头函数(Arrow Function)本质上是 ES6 引入的一种语法糖,旨在简化函数定义。

1. 基础写法对比

JavaScript

// 普通函数声明
function add(a, b) {
    return a + b;
}

// 普通函数表达式
const sub = function(a, b) {
    return a - b;
};

// 箭头函数
const mul = (a, b) => {
    return a * b;
};

2. 箭头函数的语法糖特性

箭头函数支持高度简化的写法,但同时也引入了一些特定的语法规则:

  • 省略参数括号:当且仅当只有一个参数时,可以省略括号。
  • 隐式返回:当函数体只有一行语句时,可以省略花括号 {} 和 return 关键字。

JavaScript

// 省略参数括号
const square = x => x * x;

// 完整写法对比
const squareFull = (x) => {
    return x * x;
};

3. 返回对象字面量的陷阱

这是初学者最容易踩的坑。当隐式返回一个对象字面量时,必须使用小括号 () 包裹,否则 JS 引擎会将对象的花括号 {} 解析为函数体的代码块。

JavaScript

// 错误写法:返回 undefined,引擎认为 {} 是代码块
const getUserError = id => { id: id, name: 'User' };

// 正确写法:使用 () 包裹
const getUser = id => ({ id: id, name: 'User' });

第二部分:特性分析(原理层)

在深入差异之前,我们需要界定两种函数的底层特性,这是理解它们行为差异的基石。

普通函数(Regular Function)

  • 动态作用域机制:this 的指向在函数被调用时决定,而非定义时。
  • 完整性:拥有 prototype 属性,可以作为构造函数。
  • 参数集合:函数体内自动生成 arguments 类数组对象。
  • 构造能力:具备 [[Construct]] 内部方法和 [[Call]] 内部方法。

箭头函数(Arrow Function)

  • 词法作用域机制:this 的指向在函数定义时决定,捕获外层上下文。
  • 轻量化:设计之初就是为了更轻量级的执行。没有 prototype 属性,没有 arguments 对象。
  • 非构造器:只有 [[Call]] 内部方法,没有 [[Construct]] 内部方法,因此不可实例化。

第三部分:核心差异深度解析

接下来,我们将从底层机制出发,分点剖析两者的核心差异。

1. this 指向机制(核心差异)

这是两者最根本的区别。

  • 普通函数:this 指向取决于调用位置

    • 默认绑定:独立调用指向 window(严格模式下为 undefined)。
    • 隐式绑定:作为对象方法调用,指向该对象。
    • 显式绑定:通过 call、apply、bind 修改指向。
  • 箭头函数:this 遵循词法作用域。它没有自己的 this,而是捕获定义时所在外层上下文的 this。一旦绑定,无法被修改

场景演示:setTimeout 中的回调

JavaScript

const obj = {
    name: 'Juejin',
    // 普通函数
    sayWithRegular: function() {
        setTimeout(function() {
            console.log('Regular:', this.name);
        }, 100);
    },
    // 箭头函数
    sayWithArrow: function() {
        setTimeout(() => {
            console.log('Arrow:', this.name);
        }, 100);
    }
};

obj.sayWithRegular(); // 输出: Regular: undefined (或 window.name)
obj.sayWithArrow();   // 输出: Arrow: Juejin

解析

  • sayWithRegular 中的回调函数是独立调用的,this 指向全局对象(浏览器中为 window),通常没有 name 属性。
  • sayWithArrow 中的箭头函数在定义时,捕获了外层 sayWithArrow 函数的 this(即 obj),因此能正确访问 name。即便 setTimeout 是在全局环境中执行回调,箭头函数的 this 依然保持不变。

显式绑定无效验证

JavaScript

const arrow = () => console.log(this);
const obj = { id: 1 };

// 尝试修改箭头函数的 this
arrow.call(obj); // 依然输出 window/global

2. 构造函数能力

由于箭头函数内部缺失 [[Construct]] 方法和 prototype 属性,它不能被用作构造函数。

JavaScript

const RegularFunc = function() {};
const ArrowFunc = () => {};

console.log(RegularFunc.prototype); // { constructor: ... }
console.log(ArrowFunc.prototype);   // undefined

new RegularFunc(); // 正常执行
new ArrowFunc();   // Uncaught TypeError: ArrowFunc is not a constructor

这一特性说明箭头函数旨在处理逻辑运算和回调,而非对象建模。

3. 参数处理(arguments vs Rest)

在普通函数中,我们习惯使用 arguments 对象来获取不定参数。但在箭头函数中,访问 arguments 会导致引用错误(ReferenceError),因为它根本不存在。

正确方案:ES6 推荐使用 剩余参数(Rest Parameters)

JavaScript

// 普通函数
function sumRegular() {
    return Array.from(arguments).reduce((a, b) => a + b);
}

// 箭头函数:使用 ...args
const sumArrow = (...args) => {
    // console.log(arguments); // 报错:arguments is not defined
    return args.reduce((a, b) => a + b);
};

console.log(sumArrow(1, 2, 3)); // 6

4. 方法定义中的陷阱

鉴于箭头函数的 this 绑定机制,不推荐在定义对象原型方法或对象字面量方法时使用箭头函数。

codeJavaScript

const person = {
    name: 'Developer',
    // 错误示范:this 指向 window,而非 person 对象
    sayHi: () => {
        console.log(this.name);
    },
    // 正确示范:this 动态绑定到调用者 person
    sayHello: function() {
        console.log(this.name);
    }
};

person.sayHi();    // undefined
person.sayHello(); // Developer

第四部分:面试场景复盘(实战)

面试官提问:“请你谈谈箭头函数和普通函数的区别。”

高分回答范本

(建议采用“总-分-总”策略,逻辑清晰,覆盖全面)

1. 核心总结
“箭头函数是 ES6 引入的特性,它不仅提供了更简洁的语法,更重要的是彻底改变了 this 的绑定机制。简单来说,普通函数是动态绑定,箭头函数是词法绑定。”

2. 核心差异展开

  • 关于 this 指向(最重要)
    普通函数的 this 取决于调用方式,谁调用指向谁,可以通过 call/apply/bind 改变。
    而箭头函数没有自己的 this,它会捕获定义时上下文的 this,且永久绑定,即使使用 call 或 apply 也无法改变指向。这很好地解决了回调函数中 this 丢失的问题。
  • 关于构造能力
    箭头函数不能作为构造函数使用,不能使用 new 关键字,因为它没有 [[Construct]] 内部方法,也没有 prototype 原型对象。
  • 关于参数处理
    箭头函数内部没有 arguments 对象,如果需要获取不定参数,必须使用 ES6 的剩余参数 ...args。

3. 补充亮点与使用建议
“在实际开发中,箭头函数非常适合用在回调函数、数组方法(如 map、reduce)或者需要锁定 this 的场景(如 React 组件方法)。但在定义对象方法、原型方法或动态上下文场景中,为了保证 this 指向调用者,依然应该使用普通函数。”

CommonJS 与 ES Modules的区别

在前端工程化的演进长河中,模块化规范的变迁是理解 JavaScript 运行机制的关键一环。对于资深开发者而言,CommonJS(简称 CJS)与 ES Modules(简称 ESM)不仅仅是语法的区别,更代表了 JavaScript 在服务端与浏览器端不同运行环境下的架构哲学。

本文将从底层原理出发,剖析这两大规范的核心差异,并结合 Node.js 的最新特性,探讨工程化场景下的互操作性方案。

一、模块化的前世今生

在 ES6 之前,JavaScript 语言层面并没有内置的模块体系。这导致早期的大型项目开发极易陷入全局作用域污染、依赖关系混乱(Dependency Hell)的泥潭。为了解决这一痛点,社区涌现出了多种解决方案。

CommonJS 应运而生,它主要面向服务器端(Node.js)。由于服务器端的文件存储在本地硬盘,读取速度极快,因此 CommonJS 采用了同步加载的设计。这一规范迅速确立了 Node.js 生态的统治地位。

然而,随着前端应用的日益复杂,浏览器端急需一种标准化的模块体系。ES6(ECMAScript 2015)正式推出了 ES Modules。作为官方标准,ESM 旨在统一浏览器和服务器的模块规范,凭借其静态编译和异步加载的特性,逐渐成为现代前端构建工具(如 Vite, Webpack, Rollup)的首选。

二、两大规范的运行机制与特点

1. CommonJS (CJS)

定位:服务器端模块规范,Node.js 的默认模块系统。

核心特点

  • 运行时加载:模块在代码执行阶段才被加载。
  • 同步加载:代码按照编写顺序同步执行,阻塞后续代码直至模块加载完成。
  • 值的拷贝:导出的是值的副本(对于基本数据类型)。

代码示例

JavaScript

// 导出:module.exports
const obj = { a: 1 };
module.exports = obj;

// 引入:require
const obj = require('./test.js');

2. ES Modules (ESM)

定位:ECMAScript 官方标准,旨在实现浏览器与服务端的通用。

核心特点

  • 编译时输出接口:在代码解析阶段(编译时)即可确定依赖关系。
  • 异步加载:支持异步加载机制,适应网络请求环境。
  • 值的引用:导出的是值的动态映射(Live Binding)。

代码示例

JavaScript

// 导出:export
export const obj = { name: 'ESM' };
export default { name: 'Default' };

// 引入:import
import { obj } from './test.js';
import defaultObj from './test.js';

三、深度解析——核心差异

如果要深入理解两者的区别,必须从输出机制、加载时机和加载方式三个维度进行剖析。

1. 输出值的机制:值的拷贝 vs 值的引用

这是 CJS 与 ESM 最本质的区别,也是面试中最高频的考察点。

  • CommonJS:值的拷贝
    CJS 模块输出的是一个对象,该对象在脚本运行完后生成。一旦输出,模块内部的变化就无法影响到这个值(除非导出的是引用类型对象且修改了其属性,这里特指基本数据类型或引用的替换)。
  • ES Modules:值的引用
    ESM 模块通过 export 导出的是一个静态接口。import 导入的变量仅仅是一个指向被导出模块内部变量的“指针”。如果模块内部修改了该变量,外部导入的地方也会感知到变化。

代码演示:

场景:我们定义一个 age 变量和一个自增函数 addAge。

CommonJS 实现:

JavaScript

// lib.js
let age = 18;
module.exports = {
  age,
  addAge: function () {
    age++;
  },
};

// main.js
const { age, addAge } = require('./lib.js');
console.log(age); // 18
addAge();
console.log(age); // 18 (注意:这里依然是 18,因为导出的是 age 变量在导出时刻的拷贝)

ES Modules 实现:

JavaScript

// lib.mjs
export let age = 18;
export function addAge() {
  age++;
}

// main.mjs
import { age, addAge } from './lib.mjs';
console.log(age); // 18
addAge();
console.log(age); // 19 (注意:这里变成了 19,因为 import 获取的是实时的绑定)

技术延伸
由于 ESM 是实时引用,它能更好地处理循环依赖问题。在 ESM 中,只要引用存在,代码就能执行(尽管可能在暂时性死区 TDZ 中);而在 CJS 中,循环依赖可能导致导出一个不完整的对象(空对象),因为模块可能尚未执行完毕。此外,ESM 导入的变量是只读的(Read-only),尝试在 main.mjs 中直接执行 age = 20 会抛出 TypeError。

2. 加载时机:运行时 vs 编译时

  • CommonJS (运行时)
    require 本质上是一个函数。你可以将它放在 if 语句中,或者根据变量动态生成路径。只有当代码执行到这一行时,Node.js 才会去加载模块。

    JavaScript

    if (condition) {
      const lib = require('./lib.js'); // 条件加载
    }
    
  • ES Modules (编译时)
    import 语句(静态导入)必须位于模块顶层,不能嵌套在代码块中。JavaScript 引擎在编译阶段(解析 AST 时)就能确定模块的依赖关系。
    工程化价值:这使得 Tree Shaking(摇树优化)  成为可能。构建工具可以在打包时静态分析出哪些 export 没有被使用,从而安全地删除这些死代码,减小包体积。

3. 加载方式:同步 vs 异步

  • CommonJS (同步)
    主要用于服务器端。文件都在本地磁盘,读取时间通常在毫秒级,同步加载不会造成明显的性能瓶颈。
  • ES Modules (异步)
    设计之初就考虑了浏览器环境。在浏览器中,模块需要通过网络请求加载,网络延迟不可控。如果采用同步加载,会阻塞主线程,导致页面“假死”无法交互。因此,ESM 规范规定模块解析阶段是异步的。

四、工程化实践与互操作性

在 Node.js 环境逐步过渡到 ESM 的过程中,两者共存的情况十分常见。

1. 文件后缀与配置

在 Node.js 中,为了区分模块类型:

  • CommonJS:通常使用 .cjs 后缀,或者在 package.json 中未设置 type 字段(默认为 CJS)。
  • ES Modules:强制使用 .mjs 后缀,或者在 package.json 中设置 "type": "module"。

2. 相互引用(Interoperability)

这是开发中最容易踩坑的地方。

场景 A:CommonJS 引用 ES Modules

由于 CJS 是同步的 require,而 ESM 是异步加载的,因此原生 CJS 无法直接 require ESM 文件

  • 常规方案:使用异步的动态导入 import() 配合 IIFE。

    JavaScript

    // index.cjs
    (async () => {
      const { default: foo } = await import('./foo.mjs');
    })();
    
  • 新特性(Node.js v22+ / Experimental)
    Node.js 在 2024 年推出了 --experimental-require-module 标志。开启后,支持同步 require 加载 ESM(前提是该 ESM 模块内部没有顶级 await)。

    Bash

    node --experimental-require-module index.cjs
    

场景 B:ES Modules 引用 CommonJS

ESM 的兼容性较好,可以导入 CJS 模块。

  • 机制:Node.js 会将 CJS 的 module.exports 整体作为一个默认导出(Default Export)处理。

  • 注意事项不支持具名导入(Named Imports)的直接解构。虽然部分构建工具(如 Webpack)支持混用,但在原生 Node.js 环境下,以下写法通常会报错或表现不符合预期:

    JavaScript

    // 错误示范 (原生 Node.js)
    import { someMethod } from './lib.cjs'; // 可能会失败,因为 CJS 只有 default 导出
    

    正确写法

    JavaScript

    import lib from './lib.cjs';
    const { someMethod } = lib;
    

五、面试场景复盘

面试官提问:“请聊聊 CommonJS 和 ESM 的区别。”

高分回答策略

1. 一句话定性(宏观视角)
“CommonJS 是 Node.js 社区提出的服务器端运行时模块规范,主要特点是同步加载值的拷贝;而 ES Modules 是 ECMAScript 的官方标准,实现了浏览器和服务端的统一,主要特点是编译时静态分析异步加载值的引用。”

2. 核心差异展开(技术深度)
“两者最本质的区别在于输出值的机制
CommonJS 输出的是值的拷贝。一旦模块输出,内部变量的变化不会影响导出值,类似于基本类型的赋值。
ES Modules 输出的是值的引用(Live Binding) 。导入的变量实际上是指向模块内部内存地址的指针,模块内部变化会实时反映到外部,这使得 ESM 能更好地处理循环依赖问题。”

3. 工程化价值(架构视角)
“在工程实践中,ESM 的静态编译特性非常关键。因为它允许构建工具在代码运行前分析依赖关系,从而实现 Tree Shaking,去除无用代码,优化包体积。这是 CommonJS 这种动态加载规范无法做到的。”

4. 兼容性补充(实战经验)
“在 Node.js 环境中,两者互操作需要注意。ESM 可以较容易地导入 CJS(作为默认导出),但 CJS 导入 ESM 通常需要异步的 import()。不过,Node.js 最近引入了 --experimental-require-module 标志,正尝试打破这一同步加载的壁垒。”

面试必问:别背“URL请求到渲染”了,你的对手压根不走这条路

摘要:

这道面试题背了50遍,我也烦过——三次握手四次挥手,跟我写代码有什么关系?直到发现,这套流程里的每一毫秒,决定着谁能抢到限量球鞋、演唱会门票。既然大家都爱钱,就用钱当尺子量一量这套技术。看完这篇,面试能过,抢鞋也会了。

写在开头:

说实话,刚学“DNS解析、TCP握手、TLS加密...”这套流程的时候,我也烦。什么三次握手四次挥手,跟我写业务代码有什么关系?直到我发现,这套流程里的每一毫秒,都在决定着谁能抢到那双限量球鞋、那张演唱会门票、那瓶茅台。既然大家都爱钱,咱们就用钱当尺子,量一量这套技术。


事情是这样的

最近想搞点副业。真的,单纯看着别人赚钱心里痒。天天写业务代码,工资虽然够花,但也就那样。打开得物看看鞋价,好家伙,一双鞋转手赚的钱顶我加几天班。

就上个月,我看到一双鞋——Nike Dunk Low "Sand Drift",苔藓绿配色,官网售价899。不是什么天价联名款,但配色挺干净,我寻思着抢到了自穿也行,抢不到就算了。

结果顺手搜了下闲鱼,好家伙,已经有人挂1099了。899 -> 1099,净赚200。

卖出去8双,就是1600。敲代码累死累活才赚几个钱,人家一早上赚1600。

虽然不算暴富,但这钱赚得也太轻松了吧?

当天晚上我睡不着,满脑子都是那1600。我决定研究研究——当卧底混进几个鞋贩子群,潜水一周,终于看明白了一件事:不是他们手速快,是他们抢鞋的方式,跟我完全不是一个维度的

普通用户的抢鞋链路

先看看正常用户是怎么抢的——准确说,是怎么抢不到的:

黄牛抢票普通用户.png

黄牛的抢鞋链路

再看看我最近偷学的专业操作:

黄牛抢票链路.png

黄牛的操作有多骚:

  1. HTTPDNS直连:不用问路,门牌号早就背熟了
  2. 连接池预热:我还在“你好在吗”,人家电话已经接通了
  3. 长轮询监听:不等页面刷新,等服务器喊“开饭了”
  4. API直连:服务器刚开门,订单就递进去了 结论:服务器开放的一瞬间,黄牛的订单已经躺在数据库里了。我这时候才刚点下F5。
技术拆解:浏览器其实有“作弊工具箱”

研究完黄牛的操作,我又发现一个更扎心的事实:Chrome浏览器其实准备了一套“作弊工具箱”,专门用来对付这种抢购场景。

你打开任何一个网站的控制台,都可能看到这样的代码:

  1. DNS优化:提前认路
<!-- 页面里写上这个 -->
<link rel="dns-prefetch" href="//img.jd.com">
<link rel="dns-prefetch" href="//static.jd.com">
<link rel="dns-prefetch" href="//trade.jd.com">

原理:提前解析域名,把IP缓存下来。等我真要请求时,路已经找好了,不用现问。

  1. 连接优化:提前寒暄
<link rel="preconnect" href="//trade.jd.com">

原理:提前完成TCP握手和TLS加密。等我请求时,电话已经接通了,直接说话就行。

  1. 资源优化:提前存粮
http
Cache-Control: max-age=31536000
原理:第一次下载完,存硬盘。第二次直接读本地,0ms。

方案2:预加载

html
<link rel="preload" href="buy-button.png" as="image">
<link rel="preload" href="checkout.js" as="script">

4. 终极优化:提前开门

<!-- 首页里藏着这一行 -->
<link rel="prerender" href="https://item.jd.com/100012043978.html">

原理:在后台偷偷把整个页面加载渲染完。我点开的那一刻,它已经等了我一世纪。

然后我去Nike官网的控制台搜了一下——你猜这些代码开了吗?

开了,但只开了一部分。图片预加载开了,CSS预加载开了,但是最关键的结算页面的预连接、预渲染,一个都没开。

这不是技术做不到,是品牌故意的。

你想啊,如果连购物车页面都提前渲染好、结算连接都预先建立好,黄牛的效率会再翻一倍。到时候别说我,连小黄牛都抢不过大黄牛。品牌留这道技术门槛,就是为了帮我过滤掉那些技术没那么好的初级黄牛。

全文小结

看到这里,你再回头看那道面试题:“从URL到页面,发生了什么?”

你已经不止能背出来了,你还能讲出来:普通人走的是观光路线,黄牛走的是员工通道。

下次面试官问你,你可以在结尾加一句:

“以上是浏览器的标准流程。如果您感兴趣,我还可以讲讲怎么优化这套流程——当然,仅限技术交流,我现在还没抢到过鞋。”

毕竟,这篇文章帮我弄懂了面试题,顺便学会了黄牛的技术。至于用在哪——等我先抢到一双再说吧。

写在最后

所以,别再怪自己手速慢了。你用自己的肉身,对抗的是一个千亿级产业的职业选手。

演出票务、限量球鞋、景点门票、茅台、显卡……这些加在一起,构成了一个千亿级的灰色市场。

你每次抢不到的球鞋、演唱会门票、茅台、显卡,都是这个数字的一部分。

领域 官方年度产值 (A) 黄牛渗透率 (B) 平均溢价率 (C) 黄牛市场估规模 (A×B×C)
演出票务 约 500 亿 20% - 30% 200% - 500% 约 300 - 500 亿
名酒/奢侈品 1,500 亿 (仅茅台) 40% 以上流向二级 60% - 100% 约 600 - 1,000 亿
医疗/政务/景区 不可估量 (按服务人次) 极高 (针对稀缺资源) 500% - 1,000% 约 200 - 300 亿
数码/潮流/鞋 约 1,000 亿 (热门新品) 15% 30% - 100% 约 100 - 200 亿
总计估算 -- -- -- 2,000 亿+ (千亿级灰色产值)

TCP 与 UDP 核心差异及面试高分指南

在计算机网络传输层(Transport Layer),TCP 与 UDP 是两大基石协议。理解二者的底层差异,不仅是网络编程的基础,更是后端架构选型的关键依据。本文剥离冗余表述,直击技术核心。

第一部分:协议本质

  • TCP (Transmission Control Protocol) :一种面向连接的、可靠的、基于字节流的传输层通信协议。
  • UDP (User Datagram Protocol) :一种无连接的、不可靠的、基于数据报的传输层通信协议。

第二部分:核心差异拆解

1. 连接机制

  • TCP面向连接。通信前必须通过三次握手建立连接,结束时需通过四次挥手释放连接。这种机制确保了通信双方的状态同步。
  • UDP无连接。发送数据前不需要建立连接,发送结束也无需关闭。发送端想发就发,接收端有数据就收。

2. 传输模式(核心底层差异)

  • TCP面向字节流 (Byte Stream)

    • TCP 将应用层数据看作一连串无结构的字节流。
    • 无边界:TCP 不保留应用层数据的边界。发送方连续发送两次数据,接收方可能一次收到(粘包),也可能分多次收到(拆包)。因此,应用层必须自行处理粘包/拆包问题(如定义消息长度或分隔符)。
  • UDP面向数据报 (Datagram)

    • UDP 对应用层交下来的报文,不合并、不拆分,保留这些报文的边界
    • 有边界:发送方发一次,接收方就收一次。只要数据包大小不超过 MTU(最大传输单元),UDP 就能保证应用层数据的完整性。

3. 可靠性保障

  • TCP强可靠性。通过以下机制确保数据无差错、不丢失、不重复、按序到达:

    • 序列号 (Sequence Number)  与 确认应答 (ACK)
    • 超时重传机制。
    • 流量控制 (滑动窗口) 与 拥塞控制 (慢启动、拥塞避免、快重传、快恢复)。
  • UDP不可靠性

    • 只负责尽最大努力交付 (Best Effort Delivery)。
    • 不保证数据包顺序,不保证不丢包。
    • 无拥塞控制,网络拥堵时也不会降低发送速率(这对实时应用是优势也是风险)。

4. 头部开销

  • TCP开销大

    • 头部最小长度为 20 字节(不含选项字段),最大可达 60 字节。包含源/目的端口、序列号、确认号、窗口大小、校验和等复杂信息。
  • UDP开销极小

    • 头部固定仅 8 字节。仅包含源端口、目的端口、长度、校验和。这使得 UDP 在网络带宽受限或对传输效率要求极高的场景下更具优势。

5. 传输效率与并发

  • TCP:仅支持点对点 (Unicast) 通信。每条 TCP 连接只能有两个端点。
  • UDP:支持一对一一对多多对一多对多交互通信。原生支持广播 (Broadcast) 和多播 (Multicast)。

第三部分:场景选择

TCP 典型场景

适用于对数据准确性要求高、不能容忍丢包、对速度相对不敏感的场景:

  • HTTP/HTTPS (网页浏览)
  • FTP (文件传输)
  • SMTP/POP3 (邮件传输)
  • SSH (远程登录)

UDP 典型场景

适用于对实时性要求高、能容忍少量丢包、网络开销要求低的场景:

  • DNS (域名解析,要求快速)
  • 直播/视频会议/VoIP (RTP/RTCP,实时性优先)
  • DHCP/SNMP (局域网服务)
  • QUIC/HTTP3 (基于 UDP 实现可靠传输的下一代 Web 协议)

第四部分:面试回答范式

当面试官问到“TCP 和 UDP 的区别”时,建议采用结构化具备演进思维的回答策略。

回答模板:

  1. 先下定义(定基调)
    “TCP 是面向连接的、可靠的字节流协议;而 UDP 是无连接的、不可靠的数据报协议。”

  2. 细述差异(展示底层功底)
    “具体区别主要体现在三个维度:

    • 连接与开销:TCP 需要三次握手,头部最小 20 字节;UDP 无需连接,头部仅 8 字节
    • 数据模式:TCP 是字节流,没有边界,应用层需要处理粘包问题;UDP 是报文,保留边界。
    • 可靠性机制:TCP 有序列号、ACK、拥塞控制来保证有序传输;UDP 则是尽最大努力交付,不保证顺序和完整性。”
  3. 升华主题(架构师视角 - 加分项)
    “值得注意的是,虽然 TCP 可靠,但在弱网环境下存在TCP 队头阻塞(Head-of-Line Blocking)问题(即一个包丢失导致后续所有包等待)。
    这也是为什么最新的 HTTP/3 (QUIC)  协议选择基于 UDP 来构建。QUIC 在应用层实现了可靠性和拥塞控制,既利用了 UDP 的低延迟和无队头阻塞优势,又保证了数据的可靠传输。这是当前传输层协议演进的一个重要趋势。”

第五部分:总结对比表

维度 TCP UDP
连接性 面向连接 (三次握手/四次挥手) 无连接
可靠性 高 (无差错、不丢失、不重复、有序) 低 (尽最大努力交付)
传输模式 字节流 (无边界,需处理粘包) 数据报 (有边界)
头部开销 20 ~ 60 字节 固定 8 字节
传输效率 较低 (需维护连接状态、拥塞控制) 很高 (无连接、无控制)
并发支持 仅点对点 支持广播、多播、单播
拥塞控制 有 (慢启动、拥塞避免等)

HTTP 协议演进史:从 1.0 到 2.0

HTTP 协议的演进本质是追求传输效率与资源利用率的平衡。本文剖析从 1.0 到 2.0 的技术迭代逻辑。

第一部分:HTTP 1.0 —— 基础与瓶颈

HTTP 1.0 确立了请求-响应模型,但其设计初衷仅为传输简单的超文本内容。

核心机制

  • 短连接(Short Connection) :默认采用“一求一连”模式。浏览器每次请求资源,都需要与服务器建立一个 TCP 连接,传输完成后立即断开。
  • 无状态(Stateless) :服务器不跟踪客户端状态,每次请求都是独立的。

致命缺陷

  1. TCP 连接成本极高
    每个请求都需要经历 三次握手 和 四次挥手。在加载包含数十个资源(图片、CSS、JS)的现代网页时,连接建立的耗时甚至超过数据传输本身。
  2. 严重的队头阻塞(Head-of-Line Blocking)
    由于无法复用连接,前一个请求未处理完成前,后续请求无法发送(虽然可以通过浏览器开启多个并行连接缓解,但数量有限)。
  3. 缓存控制简陋
    主要依赖 Expires 和 Last-Modified,缺乏精细的控制策略。

第二部分:HTTP 1.1 —— 性能优化标准

HTTP 1.1 旨在解决 1.0 的连接效率问题,是当前互联网使用最广泛的协议版本。

核心改进

  1. 持久连接(Persistent Connection)

    • 引入 Keep-Alive 机制,且默认开启。
    • 允许多个 HTTP 请求复用同一个 TCP 连接,显著减少了 TCP 握手开销和慢启动(Slow Start)的影响。
  2. 管道化(Pipelining)

    • 允许客户端在收到上一个响应前发送下一个请求。
    • 痛点现状:服务器必须按请求顺序返回响应。若第一个请求处理阻塞,后续响应都会被拖延。因此,主流浏览器默认禁用此功能。
  3. 虚拟主机(Virtual Host)

    • 引入 Host 头部字段。
    • 允许在同一台物理服务器(同一 IP)上托管多个域名,是现代云主机和负载均衡的基础。
  4. 功能增强

    • 断点续传:引入 Range 头,支持只请求资源的某一部分(如 206 Partial Content)。
    • 缓存增强:引入 Cache-Control、ETag 等机制,提供更复杂的缓存策略。

遗留问题

  • 应用层队头阻塞:虽然 TCP 连接复用了,但 HTTP 请求依然是串行的。一旦某个请求发生阻塞,整个管道停滞。
  • 头部冗余:Cookie 和 User-Agent 等头部信息在每次请求中重复传输,且未经压缩,浪费带宽。
  • 文本协议解析低效:基于文本的解析容易出错且效率低于二进制解析。

第三部分:HTTP 2.0 —— 架构级变革

HTTP 2.0 并非简单的功能修补,而是对传输层的重新设计,旨在突破 HTTP 1.x 的性能天花板。

核心技术

  1. 二进制分帧(Binary Framing)

    • 机制:抛弃 ASCII 文本,将所有传输信息分割为更小的消息和帧,并采用二进制编码。
    • 价值:计算机解析二进制数据的效率远高于文本,且容错率更高。
  2. 多路复用(Multiplexing)

    • 机制:基于二进制分帧,允许在同一个 TCP 连接中同时发送多个请求和响应。数据流(Stream)被打散为帧(Frame)乱序发送,接收端根据帧首部的流标识(Stream ID)进行重组。
    • 价值:彻底解决了 应用层的队头阻塞 问题,实现了真正的并发传输。
  3. 头部压缩(HPACK)

    • 机制:通信双方维护一张静态字典和动态字典。
    • 价值:传输时仅发送索引号或差异数据,极大减少了 Header 的传输体积(尤其是 Cookie 较大的场景)。
  4. 服务端推送(Server Push)

    • 服务器可在客户端请求 HTML 时,主动推送后续可能需要的 CSS 或 JS 资源,减少往返延迟(RTT)。

第四部分:总结对比

维度 HTTP 1.0 HTTP 1.1 HTTP 2.0
连接管理 短连接(每请求新建 TCP) 长连接(Keep-Alive 复用) 多路复用(单 TCP 连接并发)
数据格式 文本 文本 二进制(帧)
并发机制 管道化(常被禁用,存在阻塞) 多路复用(真正并发)
头部处理 原文传输 原文传输 HPACK 算法压缩
主机支持 单一主机 虚拟主机(Host 头) 虚拟主机
内容获取 完整获取 断点续传(Range) 断点续传

对象数组的排序与分组:sort / localeCompare / 自定义 compare

日常开发里,列表、表格、统计几乎都绕不开「对象数组」的排序和分组。本文不讲底层原理,只讲怎么选、为什么选、容易踩哪些坑。适合会写 JS 但概念有点混的同学,也适合想补齐基础的前端老手。

一、Array.sort 到底在干什么

1.1 三个关键点

要点 说明
原地排序 sort() 会直接修改原数组,不会返回新数组
默认行为 不传比较函数时,按字符串逐个字符比较
compare 返回值 负数:a 排前面;0:不变;正数:b 排前面

有没有同学会有这样的疑问:compare 返回值?这是啥? 解释:

  • 这里的 compare 指的是 Array.sort() 方法中传入的比较函数(也就是你后面写的 (a, b) => a - b 这种形式)。
  • 简单说:当你用sort()排序时,传入的这个函数就是 compare,它的作用是告诉 sort() 两个元素(ab)该怎么排,返回值直接决定排序结果,和表格里的说明完全对应。
  • 比如 nums.sort((a, b) => a - b) 中,(a, b) => a - b 就是 compare 比较函数。

1.2 第一个坑:数字数组直接用 sort

const nums = [10, 2, 1];
nums.sort(); // 这一步已经把原数组 nums 改了!以为会得到 [1, 2, 10]
console.log(nums); // 打印的是被修改后的原数组,不是初始值。实际得到 [1, 10, 2] —— 按字符串 "10"、"2"、"1" 比较了!
// ✅ 正确写法
nums.sort((a, b) => a - b);   // 升序 [1, 2, 10]
nums.sort((a, b) => b - a);   // 降序 [10, 2, 1]

:为什么按字符串比较会得到 [1, 10, 2]? sort() 默认的字符串比较规则是「逐字符按 Unicode 码点比较」,不是看数字大小,步骤拆解如下:

  1. 先把数组里的数字都转成字符串:10→"10"、2→"2"、1→"1";
  2. 从第一个字符开始比,字符的 Unicode 码点:"1"(码点 49)< "2"(码点 50);
  3. 具体比较过程:
    • 比较 "1" 和 "10":第一个字符都是 "1"(码点相同),但 "1" 没有第二个字符,所以 "1" < "10";
    • 比较 "10" 和 "2":第一个字符 "1" < "2",所以 "10" < "2"

1.3 第二个坑:原数组被改了

const original = [3, 1, 2];
const sorted = original.sort((a, b) => a - b);

console.log(sorted);   // [1, 2, 3]
console.log(original); // [1, 2, 3] —— 原数组也被改了!

// ✅ 需要保留原数组时,先浅拷贝再排序
const sorted2 = [...original].sort((a, b) => a - b);

二、对象数组按不同字段排序

2.1 按数字排序

const users = [
  { name: '张三', age: 25 },
  { name: '李四', age: 18 },
  { name: '王五', age: 30 }
];

// 按 age 升序
users.sort((a, b) => a.age - b.age);
// 结果:李四(18) → 张三(25) → 王五(30)

// 按 age 降序
users.sort((a, b) => b.age - a.age);

写法记忆:升序 a - b,降序 b - a

2.2 按字符串排序

// 按 name 字母/拼音顺序
users.sort((a, b) => a.name.localeCompare(b.name));

直接用 a.name > b.name ? 1 : -1 可以工作,但遇到中文、大小写、多语言时容易出问题,所以更推荐 localeCompare,后面会细讲。

2.3 按日期排序

日期有两种常见形式:字符串和时间戳。

const orders = [
  { id: 1, date: '2025-02-15' },
  { id: 2, date: '2025-01-20' },
  { id: 3, date: '2025-02-10' }
];

// 方式一:YYYY-MM-DD 格式的字符串可以直接用 localeCompare
orders.sort((a, b) => a.date.localeCompare(b.date));

// 方式二:转时间戳(适用各种日期格式)
orders.sort((a, b) => new Date(a.date) - new Date(b.date));

建议:后端返回的日期如果是 YYYY-MM-DD,用 localeCompare 即可;格式不统一时,统一用 new Date() 转时间戳再比较。

2.4 多字段排序

先按 A 排序,A 相同再按 B 排序,可以用 || 链式比较:

users.sort((a, b) => {
  if (a.age !== b.age) return a.age - b.age;  // 先按年龄
  return a.name.localeCompare(b.name);        // 年龄相同再按姓名
});

// 更简洁的写法
users.sort((a, b) => a.age - b.age || a.name.localeCompare(b.name));

原理a.age - b.age 为 0 时,0 || xxx 会取后面的 localeCompare 结果。

三、localeCompare:字符串排序的正确姿势

3.1 为什么不用 >、< 比较字符串?

const arr = ['张三', '李四', '王五', 'apple', 'Apple'];
arr.sort((a, b) => a > b ? 1 : -1);  // 按 Unicode 比较,中文结果不符合直觉
arr.sort((a, b) => a.localeCompare(b));  // 按语言规则,更符合人类习惯

localeCompare 可以:

  • 中文按拼音
  • 控制大小写敏感
  • 数字按数值比较(如 "10" 在 "2" 后面)

3.2 常用用法

// 指定语言(中文按拼音)
'张三'.localeCompare('李四', 'zh-CN');  // 负数,张在李后面

// 忽略大小写
'apple'.localeCompare('Apple', undefined, { sensitivity: 'base' });  // 0,视为相等

// 数字按数值比较
['10', '2', '1'].sort((a, b) => a.localeCompare(b, undefined, { numeric: true }));
// 结果:['1', '2', '10']

3.3 兼容性说明

现代浏览器和 Node 都支持 localeCompare。带 options 配置的 localeCompare 写法,在老环境(旧浏览器 / 旧 Node 版本)中可能表现不一致,生产环境建议先小范围验证。

// 忽略大小写(options:{ sensitivity: 'base' })
'apple'.localeCompare('Apple', undefined, { sensitivity: 'base' });
// 数字按数值比较(options:{ numeric: true })
['10','2'].sort((a,b) => a.localeCompare(b, undefined, { numeric: true }));

老环境问题:像旧版 IE、低版本 Node(比如 Node.js 10 以下),对这些options配置支持不完善(比如不识别numeric: true),导致排序结果出错,所以生产环境要先小范围验证。

3.4 补充localeCompareoptions写法 老环境兼容技巧

核心兼容思路:降级处理——先判断环境是否支持localeCompareoptions配置,支持则用带options的简洁写法,不支持则降级为基础写法,保证排序效果一致,且代码简单可直接套用(无需额外引入兼容库)。

场景1:忽略大小写排序(对应options: { sensitivity: 'base' })音标:/sensəˈtɪvəti/

老环境兼容写法(适配旧IE、低版本Node):

// 兼容函数:忽略大小写比较两个字符串
function compareIgnoreCase(a, b) {
  // 先统一转小写,再用基础localeCompare(老环境均支持无options写法)
  const lowerA = a.toLowerCase();
  const lowerB = b.toLowerCase();
  return lowerA.localeCompare(lowerB, 'zh-CN'); // 中文场景可加语言标识
}

// 用法(和带options写法效果一致)
const arr = ['apple', 'Apple', 'Banana', 'banana'];
arr.sort(compareIgnoreCase); // 结果:['apple', 'Apple', 'Banana', 'banana']

场景2:数字字符串按数值排序(对应options: { numeric: true }

老环境兼容写法(避免老环境不识别numeric 音标:/njuːˈmerɪk/ 配置导致排序错乱):

// 兼容函数:数字字符串按数值排序
function compareNumericStr(a, b) {
  // 降级思路:转成数字比较(贴合原文数字排序逻辑,老环境完全支持)
  const numA = Number(a);
  const numB = Number(b);
  return numA - numB; // 升序,降序则改为numB - numA
}

// 用法(和带options写法效果一致)
const arr = ['10', '2', '1', '25'];
arr.sort(compareNumericStr); // 结果:['1', '2', '10', '25']

关键注意点

  • 无需判断环境:上述兼容写法兼容所有环境(老环境正常运行,新环境也不影响效果),不用额外写环境判断代码,简化开发。

  • 生产环境验证:如果老环境占比极低,可直接用带options写法,上线前用老环境(如IE11、Node.js 8)简单测试1个排序案例即可。

四、分组统计:从排序到 groupBy 【分组】

排序和分组是两个不同操作:

  • 排序:改变顺序,不拆分数组
  • 分组:按某个字段把数组拆成多组

JS 没有内置 groupBy,可以用 reduce 实现:

const orders = [
  { id: 1, status: 'paid', amount: 100 },
  { id: 2, status: 'pending', amount: 50 },
  { id: 3, status: 'paid', amount: 200 }
];

const byStatus = orders.reduce((acc, item) => {
  const key = item.status;
  if (!acc[key]) acc[key] = [];
  acc[key].push(item);
  return acc;
}, {});

// 结果:
// {
//   paid: [{ id: 1, ... }, { id: 3, ... }],
//   pending: [{ id: 2, ... }]
// }

分组后再排序

分组后,如果每组内部还要排序:

Object.keys(byStatus).forEach(key => {
  byStatus[key].sort((a, b) => b.amount - a.amount);  // 每组按金额降序
});

分组 + 统计

需要同时统计每组数量或汇总值时:

const stats = orders.reduce((acc, item) => {
  const key = item.status;
  if (!acc[key]) {
    acc[key] = { list: [], total: 0, count: 0 };
  }
  acc[key].list.push(item);
  acc[key].total += item.amount;
  acc[key].count += 1;
  return acc;
}, {});

// 结果示例:{ paid: { list: [...], total: 300, count: 2 }, ... }

五、踩坑速查表

坑点 错误表现 正确写法
数字数组排序错乱 [10, 2, 1].sort()[1, 10, 2] arr.sort((a, b) => a - b)
原数组被修改 排序后原数组也变了 [...arr].sort(...)
中文排序不对 直接用 >< 比较 a.localeCompare(b, 'zh-CN')
多字段排序只写了一层 只按第一个字段排 a.age - b.age || a.name.localeCompare(b.name)
日期格式不统一 字符串比较出错 new Date(a.date) - new Date(b.date)

六、小结

  1. 数字排序:用 (a, b) => a - bb - a,不要用默认 sort()
  2. 字符串排序:优先用 localeCompare,尤其是中文和多语言场景。
  3. 日期排序YYYY-MM-DDlocaleCompare,其他格式用时间戳。
  4. 多字段排序:用 || 串联多个比较。
  5. 分组:用 reducegroupBy,再按需对每组排序或统计。
  6. 保留原数组:排序前先 [...arr] 浅拷贝。

这些写法足够覆盖大部分日常需求,记住上面的速查表,可以少踩很多坑。


以上就是本次的学习分享,欢迎大家在评论区讨论指正,与大家共勉。

我是 Eugene,你的电子学友。

如果文章对你有帮助,别忘了点赞、收藏、加关注,你的认可是我持续输出的最大动力~

面试官 : “ 请问你实际开发中用过 函数柯理化 吗? 能讲一下吗 ?”

一、先搞懂:柯里化到底是什么?

核心定义:柯里化是把接收多个参数的函数,转换成一系列只接收单个参数的函数,并持续返回新函数,直到所有参数都被传入后,才执行最终逻辑并返回结果。

用 “人话” 说:原本要一次性传完所有参数的函数,现在可以 “分批传”,传一个参数就返回一个新函数等着接下一个,直到传完为止。

对比:普通函数 vs 柯里化函数

// 普通函数:一次性传所有参数
function add(a, b, c) {
  return a + b + c;
}
add(1, 2, 3); // 6

// 柯里化函数:分批次传参数
function curriedAdd(a) {
  return function(b) {
    return function(c) {
      return a + b + c;
    };
  };
}
curriedAdd(1)(2)(3); // 6(传一个参数,返回新函数,直到传完3个)

二、手动实现一个通用柯里化函数

你不用为每个函数单独写柯里化逻辑,这里写一个通用的 curry 工具函数,能把任意多参数函数转换成柯里化函数:

// 通用柯里化函数
function curry(fn) {
  // 保存原函数的参数个数
  const argsLength = fn.length;
  
  // 递归接收参数
  function curried(...args) {
    // 1. 如果已传参数 >= 原函数需要的参数,执行原函数
    if (args.length >= argsLength) {
      return fn.apply(this, args);
    }
    // 2. 否则,返回新函数,继续接收参数
    return function(...newArgs) {
      return curried.apply(this, [...args, ...newArgs]);
    };
  }
  
  return curried;
}

// 测试:给加法函数做柯里化
const add = (a, b, c) => a + b + c;
const curriedAdd = curry(add);

// 支持多种传参方式(核心优势)
console.log(curriedAdd(1)(2)(3)); // 6(逐个传)
console.log(curriedAdd(1, 2)(3)); // 6(分批传)
console.log(curriedAdd(1)(2, 3)); // 6(混合传)
console.log(curriedAdd(1, 2, 3)); // 6(一次性传)

三、柯里化的核心价值(为什么要用?)

  1. 参数复用:提前固定部分参数,生成新函数,避免重复传参。示例:固定 “税率” 参数,复用计算逻辑

    // 原函数:计算税后价格(价格 + 税率)
    const calculateTax = (taxRate, price) => price * (1 + taxRate);
    // 柯里化后,固定税率为10%
    const calculateTax10 = curry(calculateTax)(0.1);
    // 后续只用传价格,不用重复传税率
    calculateTax10(100); // 110
    calculateTax10(200); // 220
    
  2. 延迟执行:先收集参数,不立即执行,等参数凑齐后再执行。示例:表单提交前收集多个字段,凑齐后再验证提交

    const submitForm = (name, phone, address) => {
      console.log(`提交:${name} ${phone} ${address}`);
    };
    const curriedSubmit = curry(submitForm);
    
    // 分步收集参数(比如用户分步填写表单)
    const step1 = curriedSubmit("张三"); // 收集姓名,未执行
    const step2 = step1("13800138000"); // 收集手机号,未执行
    step2("北京市"); // 收集地址,参数凑齐,执行 → 输出:提交:张三 13800138000 北京市
    
  3. 适配函数参数:把多参数函数转换成单参数函数,适配只接收单参数的场景(比如 React 的高阶组件、数组的 map/filter 等)。示例:适配数组 map 的单参数回调

    // 原函数:乘以指定倍数
    const multiply = (multiplier, num) => num * multiplier;
    const curriedMultiply = curry(multiply);
    
    // 固定倍数为2,生成单参数函数
    const double = curriedMultiply(2);
    // 适配 map 的单参数回调
    [1,2,3].map(double); // [2,4,6]
    

四、常见误区

❌ 误区:“柯里化就是把函数拆成只传一个参数的函数,必须链式调用 (a)(b)(c)”

✅ 纠正:柯里化的核心是 “参数分批传递 + 延迟执行”,支持任意分批方式(比如 (a,b)(c)、(a)(b,c)),不一定非要逐个传。

❌ 误区:“柯里化能提升性能”

✅ 纠正:柯里化本质是多了层函数嵌套,性能略有损耗,它的价值是提升代码复用性和可读性,而非性能。

总结

  1. 柯里化核心:把多参数函数转成 “单参数函数链”,支持参数分批传递,凑齐后执行;
  2. 实现关键:通过闭包保存已传参数,递归判断参数是否凑齐,凑齐则执行原函数;
  3. 核心用途:参数复用、延迟执行、适配单参数场景。

面试官 : “ 请说一下 JS 的常见的数组 和 字符串方法有哪些 ? ”

盘点 JS 数组和字符串的核心方法,我会按「常用场景 + 功能分类」整理,每个方法标注作用 + 示例 + 关键说明,既好记又能直接用,适合复习和开发时快速查阅。

一、数组(Array)方法

数组方法是 JS 高频考点,按「增删改查、遍历、转换、排序 / 过滤 / 聚合」分类,重点标⭐️

1. 增删改查(修改原数组)

方法 作用 示例 关键说明
⭐️ push() 末尾添加元素 [1,2].push(3) → [1,2,3] 返回新长度,修改原数组
⭐️ pop() 末尾删除元素 [1,2,3].pop() → 3 返回删除的元素,修改原数组
⭐️ unshift() 头部添加元素 [2,3].unshift(1) → [1,2,3] 返回新长度,修改原数组
⭐️ shift() 头部删除元素 [1,2,3].shift() → 1 返回删除的元素,修改原数组
⭐️ splice(start, delNum, ...add) 任意位置增删改 [1,2,3].splice(1,1,4) → [1,4,3] 返回删除的元素,修改原数组
fill(val, start, end) 填充数组 [1,2,3].fill(0, 1, 2) → [1,0,3] 修改原数组

2. 遍历(不修改原数组)

方法 作用 示例 关键说明
⭐️ forEach() 遍历数组,无返回值 [1,2].forEach(item => console.log(item)) 无法中断(break 无效)
⭐️ map() 遍历 + 返回新数组 [1,2].map(item => item*2) → [2,4] 不修改原数组,必用 return
⭐️ filter() 过滤符合条件的元素 [1,2,3].filter(item => item>1) → [2,3] 返回新数组,保留满足条件的元素
⭐️ find() 找第一个符合条件的元素 [1,2,3].find(item => item>1) → 2 找到即返回,无则 undefined
⭐️ findIndex() 找第一个符合条件的索引 [1,2,3].findIndex(item => item>1) → 1 无则返回 -1
every() 所有元素满足条件? [1,2,3].every(item => item>0) → true 全满足返回 true
some() 至少一个元素满足条件? [1,2,3].some(item => item>2) → true 有一个满足就返回 true
reduce() 聚合(求和 / 拼接等) [1,2,3].reduce((sum, item) => sum+item, 0) → 6 第二个参数是初始值,核心是 “累积”

3. 转换 / 拼接(不修改原数组)

方法 作用 示例 关键说明
⭐️ join(sep) 数组转字符串 [1,2].join('-') → "1-2" sep 是分隔符,默认逗号
⭐️ concat() 拼接数组 [1,2].concat([3,4]) → [1,2,3,4] 返回新数组,不修改原数组
⭐️ slice(start, end) 截取数组(左闭右开) [1,2,3].slice(0,2) → [1,2] 不修改原数组,end 可选(默认到末尾)
flat(depth) 扁平化数组 [1,[2,[3]]].flat(2) → [1,2,3] depth 是层级,默认 1,Infinity 拍平所有
flatMap() map + flat(1) [1,2].flatMap(item => [item, item*2]) → [1,2,2,4] 比先 map 再 flat 高效

4. 排序 / 查找(部分修改原数组)

方法 作用 示例 关键说明
⭐️ sort(compare) 排序 [3,1,2].sort((a,b) => a-b) → [1,2,3] 修改原数组,默认按字符串排序(需传比较函数)
⭐️ reverse() 反转数组 [1,2,3].reverse() → [3,2,1] 修改原数组
⭐️ includes(val) 判断是否包含元素 [1,2].includes(2) → true 区分类型(1 !== '1')
indexOf(val) 找元素首次出现的索引 [1,2,1].indexOf(1) → 0 无则返回 -1
lastIndexOf(val) 找元素最后出现的索引 [1,2,1].lastIndexOf(1) → 2 无则返回 -1

二、字符串(String)方法

字符串方法均不修改原字符串(字符串是不可变类型),按「查找 / 截取、替换 / 分割、转换、判断」分类。

1. 查找 / 截取

方法 作用 示例 关键说明
⭐️ charAt(index) 获取指定位置字符 "abc".charAt(1) → "b" 索引越界返回空字符串
⭐️ indexOf(str) 找子串首次出现的索引 "abcab".indexOf("ab") → 0 无则返回 -1
⭐️ lastIndexOf(str) 找子串最后出现的索引 "abcab".lastIndexOf("ab") → 3 无则返回 -1
⭐️ slice(start, end) 截取字符串(左闭右开) "abcde".slice(1,3) → "bc" start 负数表示从末尾数
substring(start, end) 截取字符串 "abcde".substring(1,3) → "bc" 类似 slice,但 start>end 会自动交换
substr(start, length) 按长度截取 "abcde".substr(1,2) → "bc" 已废弃,优先用 slice
⭐️ includes(str) 判断是否包含子串 "abc".includes("b") → true 区分大小写
startsWith(str) 判断是否以子串开头 "abc".startsWith("ab") → true 可传第二个参数(起始位置)
endsWith(str) 判断是否以子串结尾 "abc".endsWith("bc") → true 可传第二个参数(截取长度)

2. 替换 / 分割

方法 作用 示例 关键说明
⭐️ replace(str/regex, newStr) 替换子串 "abc".replace("b", "x") → "axc" 只替换第一个,全局替换用 /g 正则
⭐️ split(sep) 字符串转数组 "a-b-c".split("-") → ["a","b","c"] sep 为空字符串则拆成单个字符
replaceAll(str/regex, newStr) 全局替换 "abab".replaceAll("a", "x") → "xbxb" ES2021 新增,无需 /g 正则

3. 转换 / 格式化

方法 作用 示例 关键说明
⭐️ toLowerCase() 转小写 "ABC".toLowerCase() → "abc" 不修改原字符串
⭐️ toUpperCase() 转大写 "abc".toUpperCase() → "ABC" 不修改原字符串
⭐️ trim() 去除首尾空格 " abc ".trim() → "abc" 不处理中间空格
trimStart()/trimLeft() 去除开头空格 " abc".trimStart() → "abc" 别名,作用一致
trimEnd()/trimRight() 去除结尾空格 "abc ".trimEnd() → "abc" 别名,作用一致
repeat(n) 重复字符串 "ab".repeat(2) → "abab" n 为 0 返空,负数报错
padStart(len, str) 头部补全 "123".padStart(5, "0") → "00123" 常用于补零
padEnd(len, str) 尾部补全 "123".padEnd(5, "0") → "12300" 超出长度则截断

三、数组 & 字符串互通方法

场景 实现方式 示例
数组 → 字符串 arr.join(sep) [1,2].join("") → "12"
字符串 → 数组 str.split(sep) "abc".split("") → ["a","b","c"]
遍历字符串 转数组后用数组遍历方法 "abc".split("").forEach(char => console.log(char))

总结

  1. 数组核心:修改原数组的方法(push/pop/splice/sort)要注意副作用,遍历优先用 map/filter/reduce(返回新数组),列表查找用 find/findIndex 更高效;
  2. 字符串核心:所有方法不修改原字符串,截取用 slice、替换用 replace/replaceAll、分割用 split,判断包含用 includes;
  3. 高频互通:数组转字符串用 join,字符串转数组用 split,是开发中最常用的联动操作。

面试必考:如何优雅地将列表转换为树形结构?

面试必考:如何优雅地将列表转换为树形结构?

前言

在前端开发中,我们经常会遇到这样一个场景:后端返回的是一个扁平的列表数据,但前端需要渲染成树形结构。比如:

  • 省市区三级联动
  • 组织架构树
  • 权限菜单树
  • 商品分类树

今天我们就来深入探讨这个经典面试题,从递归到优化,一步步掌握列表转树的精髓。

第一章:理解数据结构

1.1 什么是扁平列表?

想象一下,你有一张Excel表格,每一行都是一个独立的数据,它们之间通过某个字段(比如parentId)来表明谁是谁的“爸爸”:

// 这是一个扁平的列表
const list = [
    {id: 1, name: 'A', parentId: 0},  // A是根节点(parentId为0表示没有父节点)
    {id: 2, name: 'B', parentId: 1},  // B的爸爸是A(parentId=1)
    {id: 3, name: 'C', parentId: 1},  // C的爸爸也是A
    {id: 4, name: 'D', parentId: 2}   // D的爸爸是B
]

这种数据的特点:

  • 每条数据都有一个唯一的 id(就像每个人的身份证号)
  • 通过 parentId 来表示父子关系(就像你知道你爸爸的身份证号)
  • parentId: 0 表示根节点(没有爸爸,或者爸爸是“虚拟”的根)

1.2 什么是树形结构?

树形结构就像你家的家族族谱:爷爷下面有爸爸和叔叔,爸爸下面有你和你兄弟姐妹:

// 我们希望转换成的树形结构
[
  {
    id: 1,
    name: 'A',
    parentId: 0,
    children: [  // children表示“孩子”们
      {
        id: 2,
        name: 'B',
        parentId: 1,
        children: [
          { id: 4, name: 'D', parentId: 2 }  // D是B的孩子
        ]
      },
      { id: 3, name: 'C', parentId: 1 }  // C是A的孩子,但没有自己的孩子
    ]
  }
]

1.3 为什么要转换?

后端为什么给扁平列表?因为存数据方便(只需要一张表)。 前端为什么要树结构?因为展示数据方便(树形菜单、级联选择器等)。

第二章:递归法(最直观的思路)

2.1 什么是递归?

递归就像俄罗斯套娃:一个大娃娃里面套着一个小娃娃,小娃娃里面还套着更小的娃娃...用程序的话说,就是函数调用自身

2.2 思路分析

想象你在整理家族族谱:

  1. 先找到所有没有爸爸的人(parentId: 0),他们是第一代人
  2. 然后为每个人找他的孩子:遍历整个列表,找到所有爸爸ID等于这个人ID的人
  3. 对每个孩子重复第2步(递归!)

2.3 基础版代码实现(逐行解释)

function listToTree(list, parentId = 0) {
    // result用来存放最终的结果
    // 比如第一次调用时,它用来存放所有根节点
    const result = []
    
    // 遍历列表中的每一项
    list.forEach(item => {
        // 检查当前项的父亲是不是我们要找的那个父亲
        // 比如parentId=0时,我们就在找所有根节点
        if (item.parentId === parentId) {
            
            // ★ 关键递归:找当前项的孩子
            // 把当前项的id作为新的parentId,去找它的孩子
            const children = listToTree(list, item.id)
            
            // 如果找到了孩子(children数组不为空)
            if (children.length) {
                // 给当前项添加一个children属性,把孩子们放进去
                item.children = children
            }
            
            // 把处理好的当前项放进结果数组
            result.push(item)
        }
    })
    
    // 返回这一层找到的所有人
    return result
}

2.4 代码执行过程演示

假设我们有这样的数据:

const list = [
    {id: 1, name: 'A', parentId: 0},  // 爷爷
    {id: 2, name: 'B', parentId: 1},  // 爸爸
    {id: 3, name: 'C', parentId: 1},  // 叔叔
    {id: 4, name: 'D', parentId: 2}   // 孙子
]

第一次调用listToTree(list, 0)

  • 找爸爸ID为0的人 → 找到A(id=1)
  • 调用listToTree(list, 1)找A的孩子

第二次调用listToTree(list, 1)

  • 找爸爸ID为1的人 → 找到B(id=2)和C(id=3)
  • 先处理B:调用listToTree(list, 2)找B的孩子
  • 再处理C:调用listToTree(list, 3)找C的孩子

第三次调用listToTree(list, 2)

  • 找爸爸ID为2的人 → 找到D(id=4)
  • 调用listToTree(list, 4)找D的孩子(没找到)
  • 返回[D],作为B的children

第四次调用listToTree(list, 3)

  • 找爸爸ID为3的人 → 没找到
  • 返回[],作为C的children(所以C没有children属性)

2.5 进阶版:使用ES6简化(逐行解释)

function listToTree(list, parentId = 0) {
    // 1. 先用filter过滤出当前层的所有节点
    // 比如找所有parentId等于0的根节点
    return list
        .filter(item => item.parentId === parentId)
        
        // 2. 然后用map对每个节点进行处理
        .map(item => ({
            // 这里用了三个点,后面会详细解释
            ...item,
            
            // 3. 递归找当前节点的孩子
            children: listToTree(list, item.id)
        }))
}

这段代码虽然简洁,但做了三件事:

  1. filter:从列表中筛选出符合条件的节点(比如所有根节点)
  2. map:对每个筛选出的节点进行处理
  3. 递归:为每个节点找它的孩子

2.6 递归法的优缺点

优点

  • 逻辑清晰,容易理解
  • 代码简洁优雅
  • 符合人的思维习惯

缺点

  • 时间复杂度 O(n²) - 每个节点都需要遍历整个列表
  • 列表越长,性能越差
  • 可能造成栈溢出(数据量极大时)

第三章:深入理解 ...item 的作用

3.1 如果不使用 ...item 会怎样?

很多初学者可能会这样写:

// 错误示例 ❌
map[item.id] = item
map[item.id].children = []  // 这样会修改原始数据!

3.2 为什么不能直接使用原对象?

让我们用一个生活例子来理解:

假设你有一张原始的家族成员名单

const originalList = [
    {id: 1, name: '爷爷'}
]

情况1:直接使用原对象(坏的做法)

const map = {}
map[1] = originalList[0]  // 把爷爷的原始记录放进map
map[1].children = ['孙子']  // 在原始记录上添加孙子信息

console.log(originalList[0])  
// 输出:{id: 1, name: '爷爷', children: ['孙子']}
// 哎呀!原始名单被修改了!

情况2:使用 ...item 复制(好的做法)

const map = {}
map[1] = { ...originalList[0] }  // 复制一份爷爷的记录
map[1].children = ['孙子']  // 在**副本**上添加孙子信息

console.log(originalList[0])  
// 输出:{id: 1, name: '爷爷'}
// 太好了!原始名单完好无损!

3.3 ...item 到底在做什么?

... 是JavaScript的扩展运算符,它的作用就像复印机:

const 原件 = { name: '张三', age: 18 }

// 用...复制一份
const 复印件 = { ...原件 }

// 现在原件和复印件是两份独立的数据
复印件.age = 19

console.log(原件.age)    // 18(没变)
console.log(复印件.age)  // 19(变了)

3.4 在列表转树中的应用

在我们的代码中:

map[item.id] = {
    ...item,        // 把item的所有属性复制过来
    children: []    // 再添加一个新的children属性
}

这相当于:

// 如果item是 {id: 1, name: 'A', parentId: 0}
// 那么新对象就是:
{
    id: 1,           // 从item复制来的
    name: 'A',       // 从item复制来的
    parentId: 0,     // 从item复制来的
    children: []     // 新添加的
}

3.5 什么时候必须用 ...item

必须用的场景:当你不想修改原始数据时

// 场景1:后端返回的数据,你不想污染它
const dataFromServer = [...]
const myCopy = { ...dataFromServer[0] }

// 场景2:多次使用同一份数据
const baseConfig = { theme: 'dark' }
const user1Config = { ...baseConfig, name: '张三' }
const user2Config = { ...baseConfig, name: '李四' }
// user1Config和user2Config互不影响

// 场景3:需要添加新属性,又不影响原对象
const original = { x: 1, y: 2 }
const enhanced = { ...original, z: 3 }
// original还是{x:1,y:2},enhanced是{x:1,y:2,z:3}

第四章:Map优化法(空间换时间)

4.1 为什么要优化?

递归法虽然好理解,但有个严重的问题:太慢了

想象一下:

  • 100个节点:递归法要做100×100=10000次操作
  • 1000个节点:要做1000×1000=1000000次操作
  • 10000个节点:...算了,太可怕了!

这就是我们常说的时间复杂度O(n²),数据量越大越慢。

4.2 优化思路

就像你去图书馆找书:

  • 递归法:每次找一本书都要把整个图书馆逛一遍
  • 优化法:先做一个索引表,想看什么书直接查索引

4.3 基础版代码实现(逐行解释)

function listToTree(list) {
    // 1. 第一步:创建"索引表"(map)
    // 这个map就像一个电话簿,通过id能直接找到对应的人
    const map = {}
    
    // 2. 第二步:存放最终结果(根节点们)
    const result = []
    
    // 3. 第一次遍历:把所有人都放进"电话簿"
    list.forEach(item => {
        // 对每个人,都做一份复印件(用...item复制)
        // 并且给复印件加一个空的"孩子名单"(children数组)
        map[item.id] = {
            ...item,        // 复印个人信息
            children: []    // 准备一个空的孩子名单
        }
    })
    
    // 4. 第二次遍历:建立父子关系
    list.forEach(item => {
        // 判断:这个人是不是根节点(没有爸爸)?
        if (item.parentId === 0) {
            // 是根节点:直接放进最终结果
            result.push(map[item.id])
        } else {
            // 不是根节点:找到他爸爸,把自己加入爸爸的孩子名单
            
            // map[item.parentId] 通过爸爸的ID找到爸爸
            // ?. 是可选链操作符,意思是:如果爸爸存在,就执行后面的操作
            // .children.push() 把自己加入爸爸的孩子名单
            map[item.parentId]?.children.push(map[item.id])
        }
    })
    
    // 5. 返回最终结果
    return result
}

4.4 图解Map优化法

假设有这样的数据:

原始列表:
[  {id:1, parentId:0, name:'A'},  // 根节点  {id:2, parentId:1, name:'B'},  // A的孩子  {id:3, parentId:1, name:'C'}   // A的孩子]

第一次遍历后(建立索引表):
map = {
  1: {id:1, name:'A', children:[]},
  2: {id:2, name:'B', children:[]},
  3: {id:3, name:'C', children:[]}
}

第二次遍历(建立关系):
- 处理item1: parentId=0 → result = [map[1]]
- 处理item2: parentId=1 → map[1].children.push(map[2])
- 处理item3: parentId=1 → map[1].children.push(map[3])

最终result:
[{
  id:1, name:'A',
  children: [
    {id:2, name:'B', children:[]},
    {id:3, name:'C', children:[]}
  ]
}]

4.5 使用ES6 Map版本(更专业的写法)

function listToTree(list) {
    // 使用ES6的Map数据结构代替普通对象
    // Map相比普通对象有更多优点:键可以是任何类型,有size属性等
    const nodeMap = new Map()
    const tree = []
    
    // 第一次遍历:初始化所有节点
    list.forEach(item => {
        nodeMap.set(item.id, {
            ...item,
            children: []
        })
    })
    
    // 第二次遍历:构建树结构
    list.forEach(item => {
        if (item.parentId === 0) {
            // 根节点直接加入树
            tree.push(nodeMap.get(item.id))
        } else {
            // 非根节点找爸爸
            const parentNode = nodeMap.get(item.parentId)
            if (parentNode) {
                // 把自己加入爸爸的孩子名单
                parentNode.children.push(nodeMap.get(item.id))
            }
        }
    })
    
    return tree
}

4.6 为什么返回result就是返回所有树的元素?

这是一个非常关键的知识点!很多初学者会疑惑:为什么最后返回result就能得到完整的树?

让我们用一个比喻来理解:

想象你是一个班主任,要整理全校学生的家族关系:

  1. 你有一张全校学生名单(list
  2. 你做了一个索引表(map),通过学号能快速找到每个学生
  3. 你有一个空的花名册(result),用来放每个家族的"族长"(根节点)

关键理解:当你把"族长"放进result时,这个"族长"已经通过索引表关联了所有的子孙后代!

// 实际内存中的关系
map[1] = { id:1, name:'A', children: [] }  // 族长A
map[2] = { id:2, name:'B', children: [] }  // A的儿子B
map[3] = { id:3, name:'C', children: [] }  // A的儿子C

// 建立关系后
map[1].children.push(map[2])  // 现在 map[1].children 里有 map[2] 的引用
map[1].children.push(map[3])  // 现在 map[1].children 里有 map[3] 的引用

// 把map[1]放入result
result.push(map[1])

// 此时的map[1]长这样:
{
    id: 1,
    name: 'A',
    children: [
        { id:2, name:'B', children:[] },  // 注意:这里是完整的B对象
        { id:3, name:'C', children:[] }   // 注意:这里是完整的C对象
    ]
}

重点来了:虽然我们只把A放进了result,但是A的children数组里直接存储了B和C对象的引用。也就是说:

  • result[0] 就是 A
  • result[0].children[0] 就是 B
  • result[0].children[1] 就是 C

所以通过result,我们就能访问到整棵树的所有节点!

如果有多个根节点:

// 假设还有另一个家族:D是族长,E是D的儿子
map[4] = { id:4, name:'D', children: [] }
map[5] = { id:5, name:'E', children: [] }
map[4].children.push(map[5])

// 把map[4]也放入result
result.push(map[4])

// 最终result:
[
    {  // 第一棵树
        id: 1, name:'A',
        children: [ { id:2, name:'B' }, { id:3, name:'C' } ]
    },
    {  // 第二棵树
        id: 4, name:'D',
        children: [ { id:5, name:'E' } ]
    }
]

所以返回result就是返回了所有的树,因为:

  1. 每个根节点都包含了它的所有子孙节点(通过引用)
  2. result数组收集了所有的根节点
  3. 通过这些根节点,我们可以访问到整个森林的所有节点

4.7 为什么说"空间换时间"?

  • 递归法:速度快吗?慢!占内存吗?少!(时间多,空间少)
  • Map优化法:速度快吗?快!占内存吗?多!(时间少,空间多)

就像搬家:

  • 递归法:每次需要什么都临时去买(耗时但省地方)
  • Map优化法:先把所有东西都买好放仓库(费地方但省时间)

第五章:两种方法的详细对比

对比维度 递归法 Map优化法 通俗解释
时间复杂度 O(n²) O(n) 100个数据:递归法要查10000次,Map法只要查200次
空间复杂度 O(1) O(n) 递归法基本不占额外内存,Map法需要建一个索引表
代码长度 短(3-5行) 稍长(10-15行) 递归法更简洁
可读性 ⭐⭐⭐⭐⭐ ⭐⭐⭐ 递归法更容易理解
适用场景 小数据量(<100条) 大数据量(>100条) 根据数据量选择

第六章:实际应用场景(详细版)

6.1 省市区三级联动

// 实际开发中,后端通常只返回扁平列表
const areas = [
    {id: 1, parentId: 0, name: '中国'},
    {id: 2, parentId: 1, name: '北京'},
    {id: 3, parentId: 1, name: '上海'},
    {id: 4, parentId: 2, name: '东城区'},
    {id: 5, parentId: 2, name: '西城区'},
    {id: 6, parentId: 3, name: '黄浦区'}
]

// 转换后,就可以方便地实现三级联动选择器
const areaTree = listToTree(areas)
// 用户选择"中国"后,自动显示"北京"、"上海"
// 选择"北京"后,自动显示"东城区"、"西城区"

6.2 组织架构树

// 公司人员列表
const employees = [
    {id: 1, parentId: 0, name: '张总', position: 'CEO'},
    {id: 2, parentId: 1, name: '李经理', position: '技术总监'},
    {id: 3, parentId: 1, name: '王经理', position: '市场总监'},
    {id: 4, parentId: 2, name: '赵前端', position: '前端工程师'},
    {id: 5, parentId: 2, name: '钱后端', position: '后端工程师'},
    {id: 6, parentId: 3, name: '孙策划', position: '市场专员'}
]

// 转换后可以渲染出组织架构图
const orgTree = listToTree(employees)

6.3 权限菜单树

// 后台管理系统的菜单
const menus = [
    {id: 1, parentId: 0, name: '系统管理', icon: '⚙️'},
    {id: 2, parentId: 1, name: '用户管理', icon: '👤'},
    {id: 3, parentId: 1, name: '角色管理', icon: '🔑'},
    {id: 4, parentId: 2, name: '新增用户', permission: 'user:add'},
    {id: 5, parentId: 2, name: '编辑用户', permission: 'user:edit'}
]

// 转换后可以方便地渲染侧边栏菜单
const menuTree = listToTree(menus)

第七章:常见问题解答(FAQ)

Q1: 如果数据中有多个根节点怎么办?

A: 没问题!result 数组会包含所有根节点,形成一个"森林"(多棵树)。每个根节点都带着自己的子树。

Q2: 如果数据中有循环引用(A的爸爸是B,B的爸爸是A)怎么办?

A: 这会导致无限递归!需要先做数据校验,或者设置最大递归深度。

Q3: 什么情况下用递归法,什么情况下用Map法?

A:

  • 数据量小(<100条):用递归法,简单易懂
  • 数据量大(>100条):用Map法,性能好
  • 面试时:先说递归法展示思路,再说Map法展示优化能力

Q4: 为什么 map[item.parentId]?.children 要加问号?

A: 问号是可选链操作符,意思是:如果 map[item.parentId] 存在,才执行后面的 .children.push。防止出现"找不到爸爸"的错误。

Q5: 为什么返回result就能得到完整的树?

A: 因为每个根节点的children数组里存储的是子节点的引用,而不是复制品。当你通过result访问根节点时,实际上可以通过引用链访问到所有后代节点。

第八章:面试技巧

当面试官问到这个问题时,可以这样回答:

  1. 第一层(基础):"我可以用递归实现,先找根节点,再递归找每个节点的子节点。"

  2. 第二层(优化):"但递归的时间复杂度是O(n²),数据量大时会很慢。我可以用Map优化到O(n)。"

  3. 第三层(细节):"在实现时要注意用...item复制对象,避免修改原始数据。还要处理边界情况,比如找不到父节点的情况。"

  4. 第四层(原理):"Map优化法的核心是空间换时间,通过索引表实现O(1)查找。返回result之所以能得到完整的树,是因为JavaScript的对象引用机制——根节点的children里存储的是子节点的引用。"

  5. 第五层(应用):"这个算法在实际开发中很常用,比如我在做省市区选择器、后台管理系统菜单时都用到了。"

第九章:总结与思考

通过这篇文章,我们学习了:

  1. 什么是列表转树:把扁平数据变成树形结构
  2. 递归法:直观但性能较差
  3. ...item的作用:复制对象,避免修改原始数据
  4. Map优化法:性能好但稍微复杂
  5. 返回结果的原理:通过引用机制,根节点包含所有子孙节点
  6. 实际应用场景:省市区联动、组织架构、权限菜单等

掌握了这个算法,你不仅能应对面试,在实际开发中也能游刃有余地处理各种树形结构数据。


如果这篇文章对你有帮助,欢迎点赞收藏,也欢迎在评论区提出你的问题!

React 性能优化:图片懒加载

引言

在现代 Web 应用开发中,首屏加载速度(FCP)和最大内容绘制(LCP)是衡量用户体验的核心指标。随着富媒体内容的普及,图片资源往往占据了页面带宽的大部分。如果一次性加载页面上的所有图片,不仅会阻塞关键渲染路径,导致页面长时间处于“白屏”或不可交互状态,还会浪费用户的流量带宽。

图片懒加载(Lazy Loading)作为一种经典的性能优化策略,其核心思想是“按需加载”:即只有当图片出现在浏览器可视区域(Viewport)或即将进入可视区域时,才触发网络请求进行加载。这一策略能显著减少首屏 HTTP 请求数量,降低服务器压力,并提升页面的交互响应速度。

本文将基于 React 生态,从底层原理出发,深入探讨图片懒加载的多种实现方案,并重点分析如何解决布局偏移(CLS)等用户体验问题。

核心原理剖析

图片懒加载的本质是一个“可见性检测”问题。我们需要实时判断目标图片元素是否与浏览器的可视区域发生了交叉。在技术实现上,主要依赖以下两种依据:

  1. 几何计算:通过监听滚动事件,实时计算元素的位置坐标。核心公式通常涉及 scrollTop(滚动距离)、clientHeight(视口高度)与元素 offsetTop(偏移高度)的比较,或者使用 getBoundingClientRect() 获取元素相对于视口的位置。
  2. API 监测:利用浏览器提供的 IntersectionObserver API。这是一个异步观察目标元素与祖先元素或顶级文档视窗交叉状态的方法,它将复杂的几何计算交由浏览器底层处理,性能表现更优。

方案一:原生 HTML 属性(最简方案)

HTML5 标准为  标签引入了 loading 属性,这是实现懒加载最简单、成本最低的方式。

Jsx

const NativeLazyLoad = ({ src, alt }) => {
  return (
    <img 
      src={src} 
      alt={alt} 
      loading="lazy" 
      width="300" 
      height="200"
    />
  );
};

分析:

  • 优点:零 JavaScript 代码,完全依赖浏览器原生行为,不会阻塞主线程。

  • 缺点

    • 兼容性:虽然现代浏览器支持度已较高,但在部分旧版 Safari 或 IE 中无法工作。
    • 不可控:开发者无法精确控制加载的阈值(Threshold),也无法在加载失败或加载中注入自定义逻辑(如骨架屏切换)。
    • 功能单一:仅适用于 img 和 iframe 标签,无法用于 background-image。

方案二:传统 Scroll 事件监听(兼容方案)

在 IntersectionObserver 普及之前,监听 scroll 事件是主流做法。其原理是在 React 组件挂载后绑定滚动监听器,在回调中计算图片位置。

React 实现示例:

Jsx

import React, { useState, useEffect, useRef } from 'react';
import placeholder from './assets/placeholder.png';

// 简单的节流函数,生产环境建议使用 lodash.throttle
const throttle = (func, limit) => {
  let inThrottle;
  return function() {
    const args = arguments;
    const context = this;
    if (!inThrottle) {
      func.apply(context, args);
      inThrottle = true;
      setTimeout(() => inThrottle = false, limit);
    }
  }
};

const ScrollLazyImage = ({ src, alt }) => {
  const [imageSrc, setImageSrc] = useState(placeholder);
  const imgRef = useRef(null);
  const [isLoaded, setIsLoaded] = useState(false);

  useEffect(() => {
    const checkVisibility = () => {
      if (isLoaded || !imgRef.current) return;

      const rect = imgRef.current.getBoundingClientRect();
      const windowHeight = window.innerHeight || document.documentElement.clientHeight;

      // 设置 100px 的缓冲区,提前加载
      if (rect.top <= windowHeight + 100) {
        setImageSrc(src);
        setIsLoaded(true);
      }
    };

    // 必须使用节流,否则滚动时会频繁触发重排和重绘,导致性能灾难
    const throttledCheck = throttle(checkVisibility, 200);

    window.addEventListener('scroll', throttledCheck);
    window.addEventListener('resize', throttledCheck);
    
    // 初始化检查,防止首屏图片不加载
    checkVisibility();

    return () => {
      window.removeEventListener('scroll', throttledCheck);
      window.removeEventListener('resize', throttledCheck);
    };
  }, [src, isLoaded]);

  return <img ref={imgRef} src={imageSrc} alt={alt} />;
};

关键点分析:

  1. 节流(Throttle) :scroll 事件触发频率极高,若不加节流,每次滚动都会执行 DOM 查询和几何计算,占用大量主线程资源,导致页面掉帧。
  2. 回流(Reflow)风险:频繁调用 getBoundingClientRect() 或 offsetTop 会强制浏览器进行同步布局计算(Synchronous Layout),这是性能杀手。

方案三:IntersectionObserver API(现代标准方案)

这是目前最推荐的方案。IntersectionObserver 运行在独立线程中,不会阻塞主线程,且浏览器对其进行了内部优化。

React 实现示例:

我们可以将其封装为一个通用的组件 LazyImage。

Jsx

import React, { useState, useEffect, useRef } from 'react';
import './LazyImage.css'; // 假设包含样式

const LazyImage = ({ src, alt, placeholderSrc, width, height }) => {
  const [imageSrc, setImageSrc] = useState(placeholderSrc || '');
  const [isVisible, setIsVisible] = useState(false);
  const imgRef = useRef(null);

  useEffect(() => {
    let observer;
    
    if (imgRef.current) {
      observer = new IntersectionObserver((entries) => {
        const entry = entries[0];
        // 当元素进入视口
        if (entry.isIntersecting) {
          setImageSrc(src);
          setIsVisible(true);
          // 关键:图片加载触发后,立即停止观察,释放资源
          observer.unobserve(imgRef.current);
          observer.disconnect();
        }
      }, {
        rootMargin: '100px', // 提前 100px 加载
        threshold: 0.01
      });

      observer.observe(imgRef.current);
    }

    // 组件卸载时的清理逻辑
    return () => {
      if (observer) {
        observer.disconnect();
      }
    };
  }, [src]);

  return (
    <img
      ref={imgRef}
      src={imageSrc}
      alt={alt}
      width={width}
      height={height}
      className={`lazy-image ${isVisible ? 'loaded' : ''}`}
    />
  );
};

export default LazyImage;

优势分析:

  • 高性能:异步检测,无回流风险。
  • 资源管理:通过 unobserve 和 disconnect 及时释放观察者,避免内存泄漏。
  • 灵活性:rootMargin 允许我们轻松设置预加载缓冲区。

进阶:用户体验与 CLS 优化

仅仅实现“懒加载”是不够的。在工程实践中,如果处理不当,懒加载会导致严重的累积布局偏移(CLS, Cumulative Layout Shift) 。即图片加载前高度为 0,加载后撑开高度,导致页面内容跳动。这不仅体验极差,也是 Google Core Web Vitals 的扣分项。

1. 预留空间(Aspect Ratio)

必须在图片加载前确立其占据的空间。现代 CSS 提供了 aspect-ratio 属性,配合宽度即可自动计算高度。

CSS

/* LazyImage.css */
.img-wrapper {
  width: 100%;
  /* 假设图片比例为 16:9,或者由后端返回具体宽高计算 */
  aspect-ratio: 16 / 9; 
  background-color: #f0f0f0; /* 骨架屏背景色 */
  overflow: hidden;
  position: relative;
}

.lazy-image {
  width: 100%;
  height: 100%;
  object-fit: cover;
  opacity: 0;
  transition: opacity 0.3s ease-in-out;
}

.lazy-image.loaded {
  opacity: 1;
}

2. 结合数据的完整 React 组件

结合后端返回的元数据(如宽高、主色调),我们可以构建一个体验极佳的懒加载组件。

Jsx

const AdvancedLazyImage = ({ data }) => {
  // data 结构示例: { url: '...', width: 800, height: 600, basicColor: '#a44a00' }
  const imgRef = useRef(null);
  const [isLoaded, setIsLoaded] = useState(false);

  useEffect(() => {
    const observer = new IntersectionObserver(([entry]) => {
      if (entry.isIntersecting) {
        const img = entry.target;
        // 使用 dataset 获取真实地址,或者直接操作 state
        img.src = img.dataset.src;
        
        img.onload = () => setIsLoaded(true);
        observer.unobserve(img);
      }
    });

    if (imgRef.current) observer.observe(imgRef.current);

    return () => observer.disconnect();
  }, []);

  return (
    <div 
      className="img-container"
      style={{
        // 核心:使用 aspect-ratio 防止 CLS
        aspectRatio: `${data.width} / ${data.height}`,
        // 核心:使用图片主色调作为占位背景,提供渐进式体验
        backgroundColor: data.basicColor 
      }}
    >
      <img
        ref={imgRef}
        data-src={data.url} // 暂存真实地址
        alt="Lazy load content"
        style={{
          opacity: isLoaded ? 1 : 0,
          transition: 'opacity 0.5s ease'
        }}
      />
    </div>
  );
};

方案对比与场景选择

方案 实现难度 性能 兼容性 适用场景
原生属性 (loading="lazy") 中 (现代浏览器) 简单的 CMS 内容页、对交互要求不高的场景。
Scroll 监听 低 (需节流) 高 (全兼容) 必须兼容 IE 等老旧浏览器,或有特殊的滚动容器逻辑。
IntersectionObserver 极高 高 (需 Polyfill) 现代 Web 应用、无限滚动列表、对性能和体验有高要求的场景。

结语

图片懒加载是前端性能优化的基石之一。从早期的 Scroll 事件监听,到如今标准化的 IntersectionObserver API,再到原生 HTML 属性的支持,技术在不断演进。

在 React 项目中落地懒加载时,我们不能仅满足于“功能实现”。作为架构师,更应关注性能损耗(如避免主线程阻塞)、资源管理(及时销毁 Observer)以及用户体验(防止 CLS、优雅的过渡动画)。通过合理利用 aspect-ratio 和占位策略,我们可以让懒加载不仅“快”,而且“稳”且“美”。

React 闭包陷阱深度解析:从词法作用域到快照渲染

在 React 函数式组件的开发过程中,开发者常会遭遇一种“幽灵般”的状态异常:页面 UI 已经正确响应并更新了最新的状态值,但在 setInterval 定时器、useEffect 异步回调或原生事件监听器中,打印出的变量却始终停滞在初始值。

这种现象通常被误认为是 React 的 Bug,但其本质是 JavaScript 语言核心机制——词法作用域(Lexical Scoping)与 React 函数式组件渲染特性发生冲突的产物。在社区中,这被称为“闭包陷阱”(Stale Closure)或“过期的闭包”。

本文将摒弃表象,从内存模型与执行上下文的角度,剖析这一问题的成因及标准解决方案。

核心原理:陷阱是如何形成的

要理解闭包陷阱,必须首先理解两个核心的前置概念:JavaScript 的词法作用域与 React 的快照渲染。

1. JavaScript 的词法作用域 (Lexical Scoping)

JavaScript 中的函数在定义时,其作用域链就已经确定了。闭包是指函数可以访问其定义时所在作用域中的变量。关键在于:闭包捕获的是函数创建那一刻的变量引用。如果该变量在后续没有发生引用地址的变更(如 const 声明的原始类型),闭包内访问的永远是创建时的那个值。

2. React 的快照渲染 (Rendering Snapshots)

React 函数组件的每一次渲染(Render),本质上都是一次独立的函数调用。

  • Render 1:React 调用 Component 函数,创建了一组全新的局部变量(包括 props 和 state)。
  • Render 2:React 再次调用 Component 函数,创建了另一组全新的局部变量。

虽然两次渲染中的变量名相同(例如都叫 count),但在内存中它们是完全不同、互不干扰的独立副本。每次渲染都像是一张“快照”,固定了当时的数据状态。

3. 致命结合:持久化闭包与过期快照

当我们将 useEffect 的依赖数组设置为空 [] 时,意味着该 Effect 只在组件挂载(Mount)时执行一次。

  1. Mount (Render 1) :count 初始化为 0。useEffect 执行,创建一个定时器回调函数。该回调函数通过闭包捕获了 Render 1 作用域中的 count (0)。
  2. Update (Render 2) :状态更新,count 变为 1。React 再次调用组件函数,产生了一个新的 count 变量 (1)。
  3. Conflict:由于依赖数组为空,useEffect 没有重新运行。内存中运行的依然是 Render 1 时创建的那个回调函数。该函数依然持有 Render 1 作用域的引用,因此它看到的永远是 count: 0。

代码实战与剖析

以下是一个经典的闭包陷阱反面教材。请注意代码注释中的内存快照分析。

JavaScript

import { useState, useEffect } from 'react';

function Counter() {
  const [count, setCount] = useState(0);

  useEffect(() => {
    // 闭包陷阱发生地
    const timer = setInterval(() => {
      // 这里的箭头函数在 Render 1 时被定义
      // 根据词法作用域,它捕获了 Render 1 上下文中的 count 常量
      // Render 1 的 count 值为 0
      console.log('Current Count:', count); 
    }, 1000);

    return () => clearInterval(timer);
  }, []); // 依赖数组为空,导致 effect 不会随组件更新而重建

  return (
    <div>
      <p>UI Count: {count}</p>
      {/* 点击按钮触发重渲染 (Render 2, 3...) */}
      <button onClick={() => setCount(count + 1)}>Add</button>
    </div>
  );
}

内存行为分析:

  • Render 1: count (内存地址 A) = 0。setInterval 创建闭包,引用地址 A。
  • User Click: 触发更新。
  • Render 2: count (内存地址 B) = 1。组件函数重新执行,创建了新变量。
  • Result: 此时 UI 渲染使用的是地址 B 的数据,但后台运行的定时器依然死死抓住地址 A 不放。

解决方案:逃离陷阱的三个层级

针对不同场景,我们有三种标准的架构方案来解决此问题。

方案一:规范依赖 (The Standard Way)

遵循 React Hooks 的设计规范,诚实地将所有外部依赖填入依赖数组。

JavaScript

useEffect(() => {
  const timer = setInterval(() => {
    console.log('Current Count:', count);
  }, 1000);

  return () => clearInterval(timer);
}, [count]); //  将 count 加入依赖
  • 原理:每当 count 变化,React 会先执行清除函数(clearInterval),然后重新运行 Effect。这将创建一个新的定时器回调,新回调捕获的是当前最新渲染作用域中的 count。
  • 代价:定时器会被频繁销毁和重建。如果计时精度要求极高,这种重置可能会导致时间偏差。

方案二:函数式更新 (The Functional Way)

如果逻辑仅仅是基于旧状态更新新状态,而不需要在副作用中读取状态值,可以使用 setState 的函数式更新。

JavaScript

useEffect(() => {
  const timer = setInterval(() => {
    //  这里的 c 是 React 内部传入的最新 state,不依赖闭包中的 count
    setCount(prevCount => prevCount + 1);
  }, 1000);

  return () => clearInterval(timer);
}, []); // 依赖依然为空,但逻辑正确
  • 原理:React 允许将回调函数传递给 setter。执行时,React 内部会将最新的 State 注入该回调。这种方式绕过了当前闭包作用域的限制,直接操作 React 的状态队列。

方案三:Ref 引用 (The Ref Way)

如果必须在 useEffect 中读取最新状态,且不希望重启定时器,useRef 是最佳逃生舱。

JavaScript

const [count, setCount] = useState(0);
const countRef = useRef(count);

// 同步 Ref:每次渲染都更新 ref.current
useEffect(() => {
  countRef.current = count;
}, [count]);

useEffect(() => {
  const timer = setInterval(() => {
    //  访问 ref.current。
    // ref 对象在组件生命周期内引用地址不变,但其 current 属性是可变的。
    // 闭包捕获的是 ref 对象的引用,因此总能读到最新的 current 值。
    console.log('Current Count:', countRef.current);
  }, 1000);

  return () => clearInterval(timer);
}, []); // 依赖为空,且定时器不会重启
  • 原理:useRef 创建了一个可变的容器。闭包虽然被锁死在首次渲染,但它锁死的是这个“容器”的引用。容器内部的内容(current)是随渲染实时更新的,从而实现了“穿透”闭包读取最新数据。

总结

React 闭包陷阱的本质,是持久化的闭包引用了过期的快照变量

这并非框架设计的缺陷,而是函数式编程模型与 JavaScript 语言特性的必然交汇点。作为架构师,在处理此类问题时应遵循以下建议:

  1. 诚实对待依赖数组:绝大多数闭包问题源于试图欺骗 React,省略依赖项。ESLint 的 react-hooks/exhaustive-deps 规则应当被严格遵守。
  2. 理解引用的本质:清楚区分什么是不可变的快照(State/Props),什么是可变的容器(Ref)。在跨渲染周期的副作用中共享数据,Ref 是唯一的桥梁。

父传子全解析:从基础到实战,新手也能零踩坑

在 Vue3 组件化开发中,父传子是最基础、最常用的组件通信方式,也是新手入门组件通信的第一步。无论是传递简单的字符串、数字,还是复杂的对象、数组,甚至是方法,父传子都有清晰、规范的实现方式。

不同于 Vue2 选项式 API 中 props 的写法,Vue3 组合式 API(

一、核心原理:单向数据流 + Props 传值

Vue3 父传子的核心逻辑只有两个关键词:Props单向数据流

  • Props:父组件通过在子组件标签上绑定属性(类似 HTML 标签属性),将数据传递给子组件;子组件通过定义 props,接收父组件传递过来的数据,相当于子组件的「输入参数」。
  • 单向数据流:数据只能从父组件流向子组件,子组件不能直接修改父组件传递过来的 props 数据(否则会报错)。如果子组件需要修改 props 数据,必须通过子传父的方式,通知父组件修改原始数据。

记住一句话:Props 是只读的,修改需找父组件。这是 Vue 组件通信的核心规范,也是避免数据混乱的关键。

父传子的核心流程(3步走):

  1. 父组件:在使用子组件的标签上,通过 :属性名="要传递的数据" 绑定数据;
  2. 子组件:通过 defineProps 定义要接收的 props(声明属性名和类型,可选但推荐);
  3. 子组件:在模板或脚本中,直接使用 props 中的数据(无需额外导入,直接通过 props.属性名 或 直接写属性名使用)。

二、基础用法:最简洁的父传子实现(必学)

我们用一个「父组件传递基本数据,子组件展示」的简单案例,讲解最基础的父传子写法,代码可直接复制到项目中运行,零门槛上手。

1. 父组件(Parent.vue):绑定数据并传递

<template>
  <div class="parent">
    <h3>我是父组件</h3>
    <p>父组件的基本数据:{{ parentName }}、{{ parentAge }}</p>
    <p>父组件的数组:{{ parentList.join('、') }}</p>
    <p>父组件的对象:{{ parentObj.name }} - {{ parentObj.gender }}</p>

    <!-- 1. 核心:在子组件标签上,通过 :属性名 绑定要传递的数据 -->
    <Child 
      :name="parentName"  // 传递字符串
      :age="parentAge"    // 传递数字
      :list="parentList"  // 传递数组
      :user-info="parentObj"  // 传递对象推荐用短横线命名)
    />
  </div>
</template>

<script setup>
// 引入子组件(Vue3 <script setup> 中,引入后可直接在模板中使用)
import Child from './Child.vue'
import { ref, reactive } from 'vue'

// 父组件要传递的数据(涵盖基本类型、数组、对象)
const parentName = ref('张三') // 字符串
const parentAge = ref(25)     // 数字
const parentList = ref(['苹果', '香蕉', '橙子']) // 数组
const parentObj = reactive({  // 对象
  name: '李四',
  gender: '男',
  age: 30
})
</script>

2. 子组件(Child.vue):定义Props并使用

<template>
  <div class="child">
    <h4>我是子组件(接收父组件传递的数据)</h4>
    <p>接收的字符串:{{ name }}</p>
    <p>接收的数字:{{ age }} 岁</p>
    <p>接收的数组:{{ list.join('、') }}</p>
    <p>接收的对象:{{ userInfo.name }}({{ userInfo.gender }})</p>
  </div>
</template>

<script setup>
// 2. 核心:通过 defineProps 定义要接收的 props
// 写法1:数组形式(简单场景,只声明属性名,不限制类型)
// const props = defineProps(['name', 'age', 'list', 'userInfo'])

// 写法2:对象形式(推荐,可限制类型、设置默认值、必填校验)
const props = defineProps({
  // 字符串类型
  name: {
    type: String,
    default: '默认用户名' // 默认值(父组件未传递时使用)
  },
  // 数字类型
  age: {
    type: Number,
    default: 18
  },
  // 数组类型(注意:数组/对象的默认值必须用函数返回,避免复用污染)
  list: {
    type: Array,
    default: () => [] // 数组默认值:返回空数组
  },
  // 对象类型(同理,默认值用函数返回)
  userInfo: {
    type: Object,
    default: () => ({}) // 对象默认值:返回空对象
  }
})

// 3. 在脚本中使用 props 数据(通过 props.属性名)
console.log('脚本中使用props:', props.name, props.age)
</script>

3. 基础细节说明(新手必看)

  • defineProps 是 Vue3 内置宏,无需导入,可直接在
  • 父组件传递数据时,属性名推荐用 kebab-case(短横线命名),比如 :user-info,子组件接收时用 camelCase(小驼峰命名),比如 userInfo,Vue 会自动做转换;
  • 数组/对象类型的 props,默认值必须用 函数返回(比如 default: () => []),否则多个子组件会复用同一个默认值,导致数据污染;
  • 子组件模板中可直接使用 props 的属性名(比如{{ name }}),脚本中必须通过 props.属性名 使用(比如 props.name)。

三、进阶用法:优化父传子的体验(实战常用)

基础用法能满足简单场景,但在实际开发中,我们还会遇到「必填校验」「类型多可选」「props 数据转换」等需求,这部分进阶技巧能让你的代码更规范、更健壮,避免后续维护踩坑。

1. Props 校验:必填项 + 多类型 + 自定义校验

通过 defineProps 的对象形式,我们可以对 props 进行全方位校验,避免父组件传递错误类型、遗漏必填数据,提升代码可靠性。

<script setup>
const props = defineProps({
  // 1. 必填项校验(required: true)
  username: {
    type: String,
    required: true, // 父组件必须传递该属性,否则控制台报警告
    default: '' // 注意:required: true 时,default 无效,可省略
  },

  // 2. 多类型校验(type 为数组)
  id: {
    type: [Number, String], // 允许父组件传递数字或字符串类型
    default: 0
  },

  // 3. 自定义校验(validator 函数)
  score: {
    type: Number,
    default: 0,
    // 自定义校验规则:分数必须在 0-100 之间
    validator: (value) => {
      return value >= 0 && value <= 100
    }
  }
})
</script>

说明:校验失败时,Vue 会在控制台打印警告(不影响代码运行),但能帮助我们快速定位问题,尤其适合团队协作场景。

2. Props 数据转换:computed 处理 props 数据

子组件不能直接修改 props 数据,但可以通过 computed 对 props 数据进行转换、格式化,满足子组件的展示需求,不影响原始 props 数据。

<template>
  <div class="child">
    <p>父组件传递的分数:{{ score }}</p>
    <p>转换后的等级:{{ scoreLevel }}</p>
    <p>父组件传递的姓名(大写):{{ upperName }}</p>
  </div>
</template>

<script setup>
import { computed } from 'vue'

const props = defineProps({
  score: {
    type: Number,
    default: 0
  },
  name: {
    type: String,
    default: ''
  }
})

// 对 props 分数进行转换:0-60 不及格,60-80 及格,80-100 优秀
const scoreLevel = computed(() => {
  const { score } = props
  if (score >= 80) return '优秀'
  if (score >= 60) return '及格'
  return '不及格'
})

// 对 props 姓名进行格式化:转为大写
const upperName = computed(() => {
  return props.name.toUpperCase()
})
</script>

3. 传递方法:父组件给子组件传递回调函数

父传子不仅能传递数据,还能传递方法(回调函数)。核心用途:子组件通过调用父组件传递的方法,通知父组件修改数据(解决子组件不能直接修改 props 的问题)。

<!-- 父组件(Parent.vue) -->
<template>
  <div class="parent">
    <p>父组件计数器:{{ count }}</p>
    <!-- 传递方法::方法名="父组件方法" -->
    <Child 
      :count="count"
      :addCount="handleAddCount"  // 传递父组件的方法
    />
  </div>
</template>

<script setup>
import Child from './Child.vue'
import { ref } from 'vue'

const count = ref(0)

// 父组件的方法(将被传递给子组件)
const handleAddCount = () => {
  count.value++
}
</script>
<!-- 子组件(Child.vue) -->
<template>
  <div class="child">
    <p>子组件接收的计数器:{{ count }}</p>
    <!-- 调用父组件传递的方法 -->
    <button @click="addCount">点击让父组件计数器+1</button>
  </div>
</template>

<script setup>
const props = defineProps({
  count: {
    type: Number,
    default: 0
  },
  // 声明接收父组件传递的方法(type 为 Function)
  addCount: {
    type: Function,
    required: true
  }
})

// 也可以在脚本中调用父组件的方法
const callParentMethod = () => {
  props.addCount()
}
</script>

注意:传递方法时,父组件只需写 :addCount="handleAddCount"(不带括号),子组件调用时再带括号 addCount();如果父组件写 :addCount="handleAddCount()",会导致方法立即执行,而非传递方法本身。

4. 批量传递 props:v-bind 绑定对象

如果父组件需要给子组件传递多个 props,逐个绑定会比较繁琐,这时可以用 v-bind 批量绑定一个对象,子组件只需对应接收即可。

<!-- 父组件(Parent.vue) -->
<template>
  <div class="parent">
    <!-- 批量传递:v-bind="对象",等价于逐个绑定对象的属性 -->
    <Child v-bind="userObj" />
  </div>
</template>

<script setup>
import Child from './Child.vue'
import { reactive } from 'vue'

// 要批量传递的对象
const userObj = reactive({
  name: '张三',
  age: 25,
  gender: '男',
  address: '北京'
})
</script>
<!-- 子组件(Child.vue) -->
<script setup>
// 逐个接收父组件批量传递的 props,和普通 props 接收一致
const props = defineProps({
  name: String,
  age: Number,
  gender: String,
  address: String
})
</script>

四、实战场景:父传子的高频应用(贴合实际开发)

结合实际开发中的高频场景,补充 3 个常用案例,覆盖大部分父传子需求,直接套用即可。

场景1:父组件控制子组件弹窗显示/隐藏

<!-- 父组件(Parent.vue) -->
<template>
  <div class="parent">
    <button @click="visible = true">打开子组件弹窗</button>
    <!-- 传递弹窗显示状态 + 关闭弹窗的方法 -->
    <ChildModal 
      :visible="visible"
      :closeModal="handleCloseModal"
    />
  </div>
</template>

<script setup>
import ChildModal from './ChildModal.vue'
import { ref } from 'vue'

const visible = ref(false)

// 关闭弹窗的方法
const handleCloseModal = () => {
  visible.value = false
}
</script>
<!-- 子组件(ChildModal.vue) -->
<template>
  <div class="modal" v-if="visible">
    <div class="modal-content">
      <h4>子组件弹窗</h4>
      <button @click="closeModal">关闭弹窗</button>
    </div>
  </div>
</template>

<script setup>
const props = defineProps({
  visible: {
    type: Boolean,
    default: false
  },
  closeModal: {
    type: Function,
    required: true
  }
})
</script>

场景2:父组件给子组件传递接口数据

实际开发中,父组件通常会请求接口,将接口返回的数据传递给子组件展示,这是最常见的场景之一。

<!-- 父组件(Parent.vue) -->
<template>
  <div class="parent">
    <!-- 加载中状态 -->
    <div v-if="loading">加载中...</div>
    <!-- 接口数据请求成功后,传递给子组件 -->
    <ChildList :list="goodsList" v-else />
  </div>
</template>

<script setup>
import ChildList from './ChildList.vue'
import { ref, onMounted } from 'vue'

const goodsList = ref([])
const loading = ref(false)

// 父组件请求接口
onMounted(async () => {
  loading.value = true
  try {
    const res = await fetch('https://api.example.com/goods')
    const data = await res.json()
    goodsList.value = data.list // 接口返回的列表数据
  } catch (err) {
    console.error('接口请求失败:', err)
  } finally {
    loading.value = false
  }
})
</script>

场景3:子组件复用,父组件传递不同配置

子组件复用是组件化开发的核心优势,通过父传子传递不同的配置,让同一个子组件实现不同的展示效果。

<!-- 父组件(Parent.vue) -->
<template>
  <div class="parent">
    <!-- 同一个子组件,传递不同配置,展示不同效果 -->
    <Button 
      :text="按钮1"
      :type="primary"
      :disabled="false"
    />
    <Button 
      :text="按钮2"
      :type="default"
      :disabled="true"
    />
  </div>
</template>

<script setup>
import Button from './Button.vue'
</script>
<!-- 子组件(Button.vue) -->
<template>
  <button 
    class="custom-btn"
    :class="type === 'primary' ? 'btn-primary' : 'btn-default'"
    :disabled="disabled"
  >
    {{ text }}
  </button>
</template>

<script setup>
const props = defineProps({
  text: {
    type: String,
    required: true
  },
  type: {
    type: String,
    default: 'default',
    validator: (val) => {
      return ['primary', 'default', 'danger'].includes(val)
    }
  },
  disabled: {
    type: Boolean,
    default: false
  }
})
</script>

五、常见坑点避坑指南(新手必看)

很多新手在写父传子时,会遇到「props 接收不到数据」「修改 props 报错」「方法传递后无法调用」等问题,以下是最常见的 5 个坑点,帮你快速避坑。

坑点1:父组件传递数据时,忘记加冒号(:)

错误写法:<Child name="parentName"></Child>(没有冒号,传递的是字符串 "parentName",而非父组件的 parentName 变量);

正确写法:<Child :name="parentName"></Child>(加冒号,传递的是父组件的变量)。

坑点2:子组件直接修改 props 数据

错误写法:props.name = '李四'(直接修改 props,会报错);

正确写法:通过父传子的方法,通知父组件修改原始数据(参考「传递方法」章节),或通过 computed 转换数据(不修改原始 props)。

坑点3:数组/对象 props 的默认值未用函数返回

错误写法:list: { type: Array, default: [] }(直接写数组,会导致多个子组件复用同一个数组,数据污染);

正确写法:list: { type: Array, default: () => [] }(用函数返回数组,每个子组件都会得到一个新的空数组)。

坑点4:传递方法时,父组件带了括号

错误写法:<Child :addCount="handleAddCount()"></Child>(方法立即执行,传递的是方法的返回值,而非方法本身);

正确写法:<Child :addCount="handleAddCount"></Child>(不带括号,传递方法本身)。

坑点5:props 命名大小写不一致

错误写法:父组件 :userInfo="parentObj",子组件接收 userinfo(小写 i);

正确写法:父组件用 kebab-case(:user-info),子组件用 camelCase(userInfo),或保持大小写一致(不推荐)。

六、总结:父传子核心要点回顾

Vue3 父传子的核心就是「Props 传值 + 单向数据流」,记住以下 4 个核心要点,就能应对所有父传子场景:

  1. 基础流程:父组件 :属性名="数据" 绑定 → 子组件 defineProps 接收 → 子组件使用数据;
  2. 核心规范:Props 是只读的,子组件不能直接修改,修改需通过父传子的方法通知父组件;
  3. 进阶技巧:props 校验提升可靠性,computed 转换数据,v-bind 批量传值,传递方法实现双向交互;
  4. 避坑关键:加冒号传递变量、不直接修改 props、数组/对象默认值用函数返回、传递方法不带括号。

父传子是 Vue3 组件通信中最基础、最常用的方式,掌握它之后,再学习子传父、跨层级通信(provide/inject)、全局通信(Pinia)会更轻松。

防抖(Debounce)与节流(Throttle)解析

引言:高性能开发的必修课

在现代前端开发中,用户体验与性能优化是衡量一个应用质量的关键指标。然而,浏览器的许多原生事件,如 window.resize、document.scroll、input 验证以及 mousemove 等,其触发频率极高。

如果我们在这些事件的回调函数中执行复杂的 DOM 操作(导致重排与重绘)或发起网络请求,浏览器的渲染线程将被频繁阻塞,导致页面掉帧、卡顿;同时,后端服务器也可能面临每秒数千次的无效请求轰炸,造成不必要的压力。

防抖(Debounce)与节流(Throttle)正是为了解决这一核心矛盾而生。它们通过控制函数执行的频率,在保证功能可用的前提下,将浏览器与服务器的负载降至最低。本文将从底层原理出发,纠正常见的实现误区(如 this 指向丢失),并提供生产环境可用的封装代码。

核心概念解析:生动与本质

为了更好地区分这两个概念,我们可以引入两个生活中的生动比喻。

1. 防抖(Debounce):最后一次说了算

比喻:电梯关门机制
想象你走进电梯,按下关门键。此时如果又有人跑过来,电梯门会停止关闭并重新打开。只有当一段时间内(比如 5 秒)没有人再进入电梯,门才会真正关上并运行。

核心逻辑
无论事件触发多少次,只要在规定时间间隔内再次触发,计时器就会重置。只有当用户停止动作一段时间后,函数才会执行一次。

典型场景

  • 搜索框联想:用户停止输入后才发送 Ajax 请求。
  • 窗口大小调整:用户停止拖拽窗口后才计算布局。

2. 节流(Throttle):按规定频率执行

比喻:FPS 游戏中的射速
在射击游戏中,无论你点击鼠标的速度有多快(哪怕一秒点击 100 次),一把设定了射速为 0.5 秒一发的武器,在规定时间内只能射出一发子弹。

核心逻辑
在规定的时间单位内,函数最多只能执行一次。它稀释了函数的执行频率,保证函数按照固定的节奏运行。

典型场景

  • 滚动加载:监听页面滚动到底部,每隔 200ms 检查一次位置。
  • 高频点击:防止用户疯狂点击提交按钮。

核心原理与代码实现

在实现这两个函数时,很多初学者容易忽略 JavaScript 的作用域参数传递问题,导致封装后的函数无法正确获取 DOM 元素的 this(上下文)或丢失 Event 对象。以下代码将演示标准且健壮的写法。

1. 防抖(Debounce)实现

防抖通常分为“非立即执行版”和“立即执行版”。最常用的是非立即执行版。

标准通用版代码

JavaScript

/**
 * 防抖函数
 * @param {Function} func - 需要执行的函数
 * @param {Number} wait - 延迟执行时间(毫秒)
 */
function debounce(func, wait) {
    let timeout;

    // 使用 ...args 接收所有参数(如 event 对象)
    return function(...args) {
        // 【关键点】捕获当前的 this 上下文
        // 如果这里不捕获,setTimeout 中的函数执行时,this 会指向 Window 或 Timeout 对象
        const context = this;

        // 如果定时器存在,说明在前一次触发的等待时间内,清除它重新计时
        if (timeout) clearTimeout(timeout);

        timeout = setTimeout(() => {
            // 使用 apply 将原始的上下文和参数传递给 func
            func.apply(context, args);
        }, wait);
    };
}

代码解析:

  1. 闭包:timeout 变量保存在闭包中,不会被销毁。
  2. this 绑定:我们在返回的匿名函数内部保存 const context = this。当该函数绑定到 DOM 事件(如 input.addEventListener)时,this 指向触发事件的 DOM 元素。
  3. apply 调用:func.apply(context, args) 确保原函数执行时,既能拿到正确的 this,也能拿到 event 等参数。

2. 节流(Throttle)实现

节流的实现主要有两种流派:时间戳版(首节流,立即执行)和定时器版(尾节流,延迟执行)。实际生产中,为了兼顾体验,通常使用合并版

基础版:时间戳(立即执行)

JavaScript

function throttleTimestamp(func, wait) {
    let previous = 0;
    return function(...args) {
        const now = Date.now();
        const context = this;
        
        if (now - previous > wait) {
            func.apply(context, args);
            previous = now;
        }
    }
}

进阶版:定时器 + 时间戳(头尾兼顾)

为了保证第一次触发能立即执行(响应快),且最后一次触发在冷却结束后也能执行(不丢失最后的操作),我们需要结合两者。

JavaScript

/**
 * 节流函数(精确控制版)
 * @param {Function} func - 目标函数
 * @param {Number} wait - 间隔时间
 */
function throttle(func, wait) {
    let timeout;
    let previous = 0;

    return function(...args) {
        const context = this;
        const now = Date.now();
        
        // 计算剩余时间
        // 如果没有 previous(第一次),remaining 会小于等于 0
        const remaining = wait - (now - previous);

        // 如果没有剩余时间,或者修改了系统时间导致 remaining > wait
        if (remaining <= 0 || remaining > wait) {
            if (timeout) {
                clearTimeout(timeout);
                timeout = null;
            }
            previous = now;
            func.apply(context, args);
        } else if (!timeout) {
            // 如果处于冷却期,且没有定时器,设置一个定时器在剩余时间后执行
            // 这里的目的是保证最后一次触发也能被执行(尾调用)
            timeout = setTimeout(() => {
                previous = Date.now();
                timeout = null;
                func.apply(context, args);
            }, remaining);
        }
    };
}

深度对比与场景决策

为了在实际开发中做出正确选择,我们需要从执行策略和应用场景两个维度进行对比。

维度 防抖 (Debounce) 节流 (Throttle)
核心策略 延时处理:等待动作停止后才执行。 稀释频率:按固定时间间隔执行。
执行次数 连续触发 N 次,通常只执行 1 次(最后一次)。 连续触发 N 次,均匀执行 N / (总时间/间隔) 次。
即时性 较差,因为需要等待延迟时间结束。 较好,第一次触发通常立即执行,中间也会规律执行。
适用场景 1. 搜索框输入(input)
2. 手机号/邮箱格式验证
3. 窗口大小调整(resize)后的布局计算
1. 滚动加载更多(scroll)
2. 抢购按钮的防重复点击
3. 视频播放记录时间打点

决策口诀

  • 如果你关心的是结果(比如用户最终输了什么),用防抖
  • 如果你关心的是过程(比如页面滚动到了哪里),用节流

进阶扩展

1. requestAnimationFrame 的应用

在处理与动画或屏幕渲染相关的节流场景时(如高频的 scroll 或 touchmove 导致的 DOM 操作),使用 setTimeout 的节流可能仍不够平滑,因为屏幕的刷新率通常是 60Hz(约 16.6ms 一帧)。

window.requestAnimationFrame() 是浏览器专门为动画提供的 API,它会在浏览器下一次重绘之前执行回调。利用它代替 throttle 可以实现更丝滑的视觉效果,且能自动暂停在后台标签页中的执行,节省 CPU 开销。

JavaScript

let ticking = false;
window.addEventListener('scroll', function(e) {
  if (!ticking) {
    window.requestAnimationFrame(function() {
      // 执行渲染逻辑
      ticking = false;
    });
    ticking = true;
  }
});

2. 工业级库 vs 手写实现

虽然手写防抖节流是面试和理解原理的必修课,但在复杂的生产环境中,建议使用成熟的工具库,如 Lodash (_.debounce, _.throttle)。

Lodash 的实现考虑了更多边界情况,例如:

  • leading 和 trailing 选项的精细控制(是否在开始时执行,是否在结束时执行)。
  • maxWait 选项(防抖过程中,如果等待太久是否强制执行一次,即防抖转节流)。
  • 取消功能(cancel 方法),允许在组件卸载(Unmount)时清除未执行的定时器,防止内存泄漏。

结语

防抖和节流是前端性能优化的基石。理解它们的区别不仅仅在于背诵定义,更在于理解浏览器事件循环机制以及闭包的应用。正确地使用它们,能够显著降低服务器压力,提升用户交互的流畅度,是每一位高级前端工程师必须掌握的技能。

❌