前端面试

一、前言

1.1 写在前面

做一个总结，总结自己的知识体系。

话不多说，上车🚌

这篇最早写于 2021 年。这次修订保留了原来的结构和答题思路，主要做了三件事：修正写错或已经过时的结论（IE 时代的兼容写法、被废弃的 API、HTTP 缓存和 Node 事件循环的旧行为等）；在相关小节里补充现在的推荐做法；把原来只有标题的面试题补上了答案要点。代码片段里的输出结果都用 Node 24 / 现代浏览器重新跑过。

1.2 指南

mindmap
  root((面试指南))
    简历
      自我介绍
      工作描述
        任职时长、岗位
        工作内容
        业绩：用数据表明
    投递方式
      内推
      分批投递
        Boss
        拉勾
    公司是否靠谱
      天眼查
      人脉
    面试题
      笔试
      项目
    问答
      技术
        自我介绍
        项目经验
        职业规划
      团队管理
      软技能
    薪酬
      money 💰
        预要
        实际
      薪资构成
        基本工资
        绩效
        期权
    选择 Offer
      社保：缴纳基数
      公积金：缴纳基数
      试用期：不低于转正工资的 80%
      考核/晋升
        晋升空间
        发展平台
        薪资/调薪
          次数
          标准
      年终奖：写进合同

1.3 面试考察

考察基础知识与知识广度

面试技巧

mindmap
  root((面试技巧))
    沟通技巧
      沟通原则：客观描述事实，不做主观臆断
      三说：知道的知识自信说，模糊的知识假设说，陌生的知识诚实说
      三不说：不说谎话，不说抱怨的话，不说轻浮的话
    面试节奏
      引导对方：由知识点 A 引出知识点 B、C，预埋问题坑位，引导对方提问
      渲染情绪：感知对方情绪，判断策略，引发对方共情
      反问阶段：了解对方团队、技术栈、痛点问题、组织定位……

各轮面试考察什么

mindmap
  root((面试考察))
    技术一面：基础和知识广度，专业 80% + 软素质 20%
      计算机基础：算法、数据结构
      前端基础：JS/CSS、前端框架、Node、浏览器原理、网络、安全、跨端能力
      编码能力：逻辑是否清晰、边界是否考虑到、思维是否活跃
      技术视野：行业技术现状、新技术的了解和实践
    技术二面：工程、设计、规划能力，专业 60% + 软素质 40%
      工程能力：效率、质量、性能、定义标准、产出规范
      设计能力：抽象能力、拆解能力、健壮性、扩展性
      规划能力：做事的思路是什么
      沟通和推动能力：是否有一套自己的项目推动方法和成功 case
      产品意识：目标是什么？存在哪些问题？如何解决？价值体现在哪里？
      其他软实力：聪明程度、学习能力、责任心、价值观
    技术三面
      技术格局与视野
      人生规划
      软技能考察

描述项目：STAR 法则

STAR 即情境 Situation、任务 Task、行动 Action、结果 Result，展开来可以按下面 8 个点准备：

mindmap
  root((描述项目))
    背景：项目背景，是在什么情况下发生的
    角色：我当时承担了什么角色
    职责：负责工作的哪一方面，协调、开发……
    难题：遇到了什么难题，怎么解决的，为什么这么解决
    结果：项目结果如何，有数据支撑更有说服力
    沉淀：做完这个项目沉淀了什么，给别人带来什么
    复盘：如果重新让你做这件事，你会怎么做，有什么更好的方案
    评价：项目中的表现，周围的小伙伴怎么评价，上级怎么评价

1.4 思考

1.4.1 年底与年初哪个属于跳槽的最佳时期？

入职前...

拿到offer时，你最好就开始思考预测未来3-5年，你的工作与生活，该怎么走

1.5 参考

1.5.1 学习

• 背景：学的很累
• 原则：先少后多、先精后广
• 方法：平衡学习、工作、生活时间与利用社区的力量

1.5.2 成长

• 定义：技术、做事
• 方法：自驱动、敢于挑战、承担责任
• 自测：技术架构、独立做事、彼此成就

1.5.3 晋升

• 目标：加薪、晋升
• 方法：少说、多做、任劳任怨、有效的沟通、拒绝平庸、全面发展
• 心态：先付出在回报、个人服从集体、学会定位和补位、足够耐心

1.6 总结

面试题更多时候是一个引子，更多是想通过面试题去思考题目背后带来的对某一模块的深入学习和探讨。

二、CSS

2.1 CSS 盒模型

2.1.1 基本概念

2.1.1.1 标准模型

从上图可以看到标准 W3C 盒子模型的范围包括 margin、border、padding、content，并且 content 部分不包含其他部分。

2.1.1.2 IE 模型

从上图可以看到 IE 盒子模型的范围也包括 margin、border、padding、content，和标准 W3C 盒子模型不同的是：IE 盒子模型的 width / height 包含了 border 和 padding。

2.1.2 CSS 如何设置这两种模型

/* 标准模型 */
box-sizing: content-box;
/* IE 盒模型 */
box-sizing: border-box;

/* 浏览器默认值：box-sizing: content-box */

现在几乎所有项目都会在 reset 里全局设 *, *::before, *::after { box-sizing: border-box; }（Tailwind 的 Preflight 也是这么做的），因为「写多宽就是多宽」更符合直觉。面试时说清两种模型的区别、以及为什么大家默认用 border-box 就够了。

2.1.3 JS 如何设置获取盒子模型对应的宽和高

dom.style.width / height // 只能取到内联样式

dom.currentStyle.width / height // 仅旧版 IE，已无意义

window.getComputedStyle(dom).width / height // 计算后的样式

dom.getBoundingClientRect().width / height // 实际渲染尺寸（含 transform 缩放）

offsetWidth（含 border）、clientWidth（不含 border 和滚动条）也常被问到；需要监听尺寸变化时用 ResizeObserver，不要轮询。

2.1.4 实例题(根据盒模型解释边距重叠)

如上图:有两个元素其中子元素高度为 100px,子元素与父元素的上边距为 10px,求父元素的实际高度？ 答案: 说 100px 对，说 110 也对，为什么捏？这个要看父元素有没有创建 BFC

<style>
  html,
  * {
    padding: 0;
    margin: 0;
  }
  #sec {
    background: #f00;
  }
  .child {
    height: 100px;
    margin-top: 10px;
    background: yellow;
  }
</style>
<body>
  <section id="sec">
    <article class="child"></article>
  </section>
</body>

运行效果：

上图证明 100px 是对的 元素加个 overflow:hidden

你会发现这时高度为 110px, 这时大家可能会疑问,为什么给父级元素设置一个 overflow:hidden 以后，它的高度就成 110 呢，这块的基本原理是啥呢，咋就这样呢？说这个之前，先引用一个知识点： 上面代码是父子元素边距重叠，那么还有两种情况边距重叠就是，一种是兄弟元素，就是两个 div 挨着，每个都上边距或者下边距，那么重叠的原则就是取最大值。 来回答上面问题：给父级加了 overflow:hidden,其实就是给父级元素创建一个 BFC(块级格式化上下文)。

2.2 BFC

2.2.1 基本概念

Block Formatting Context, 块级格式化上下文，一个独立的块级渲染区域，该区域拥有一套渲染规格来约束块级盒子的布局，且与区域外部无关。

2.2.2 BFC 的原理

• 同一个 BFC 内相邻块级盒子的垂直外边距会发生重叠
• BFC 的区域不会与浮动元素的 float 重叠
• 独立的容器，内外元素互不影响
• 计算 BFC 高度，浮动元素也参与计算

2.2.3 如何创建 BFC

• 根元素 <html>
• float 不为 none 的时候
• position 为 absolute 或 fixed 的时候
• display 为 inline-block、table-cell、table-caption 等表格相关值的时候
• display 为 flow-root 的时候（专门用来创建 BFC，没有副作用）
• overflow 不为 visible 和 clip 的时候（auto、hidden、scroll）
• flex / grid 容器的直接子项（它们创建的是 flex/grid 格式化上下文，表现类似）
• contain: layout | content | paint 的时候

以前清浮动、防 margin 重叠习惯写 overflow: hidden，副作用是会裁掉溢出内容（比如阴影、下拉菜单）。现在直接用 display: flow-root，所有现代浏览器都支持。另外布局基本都交给 flex / grid 之后，float 只剩「文字环绕图片」这个本职用途，BFC 在实际开发里出现得少了，但依然是面试常考点。

2.2.4 BFC 使用场景

• BFC 垂直方向边距重叠

<section id="margin">
  <style>
    #margin {
      background: pink;
      overflow: hidden;
    }
    #margin > p {
      margin: 5px auto 25px;
      background: red;
    }
  </style>
  <p>1</p>
  <div style="overflow:hidden">
    <p>2</p>
  </div>
  <p>3</p>
</section>

• BFC 不与 float 重叠

<section id="layout">
  <style media="screen">
    #layout {
      background: red;
    }
    #layout .left {
      float: left;
      width: 100px;
      height: 100px;
      background: pink;
    }
    #layout .right {
      height: 110px;
      background: #ccc;
      overflow: auto;
    }
  </style>
  <div class="left"></div>
  <div class="right"></div>
</section>

• BFC 子元素即使是 float 也会参与计算

<section id="float">
  <style media="screen">
    #float {
      background: red;
      overflow: auto;
      /*float: left;*/
    }
    #float .float {
      float: left;
      font-size: 30px;
    }
  </style>
  <div class="float">我是浮动元素</div>
</section>

2.3 link 标签和 import 标签的区别

• link 属于 html 标签，除了加载 CSS 还能做 preload、preconnect、icon 等；@import 是 CSS 提供的语法，只能导入样式。
• link 引用的 CSS 在解析 HTML 时就会被发现并并行下载；@import 要等外层 CSS 下载、解析后才会被发现，形成串行请求，拖慢首屏。
• link 可以通过 JS 操作 DOM 动态插入或修改，@import 不行。
• 两者引入的样式没有「权重高低」之分，冲突时按层叠规则（来源、优先级、出现顺序）决定。

现在 @import 主要出现在源码里，由构建工具（Vite、PostCSS、Lightning CSS 等）在打包时内联掉，不会真的发到浏览器。另外 @import url(...) layer(base); 可以直接把导入的样式放进某个 cascade layer。

2.4 选择器，优先级

id 选择器，class 选择器，标签选择器，属性选择器，伪元素选择器，伪类选择器等

优先级（specificity）按 (id 个数, class/属性/伪类 个数, 标签/伪元素 个数) 三元组逐位比较，不是简单相加：

• 同一元素引用了多个样式时，优先级相同则排在后面的样式生效；
• 样式选择器的类型不同时，优先级顺序为：内联样式 > id 选择器 > class 选择器 > 标签选择器；通配符 * 和组合符（>、+、~、空格）不增加优先级；
• 后代元素会继承祖先元素的部分样式（如 color、font），继承来的样式没有优先级，任何直接作用在元素上的规则（哪怕是 *）都会覆盖它；
• 带有 !important 标记的样式属性会盖过普通声明；
• <style> 和 <link> 引入的样式本身没有高低之分，按出现顺序决定；
• 样式表来源的顺序为：作者样式 > 用户样式 > 浏览器默认样式（!important 时反过来）。

现代 CSS 新增了几个管理优先级的工具，面试常会追问：

• @layer：cascade layers，先比较层的顺序，再比较选择器优先级。后声明的层优先，未分层的样式优先于所有层。Tailwind v4 就是靠 @layer theme, base, components, utilities 管理覆盖关系。
• :where()：优先级永远为 0，适合写容易被覆盖的默认样式。
• :is() / :not() / :has()：优先级取参数里最高的那个。:has() 就是期待多年的「父选择器」，2023 年底起主流浏览器都已支持。
• @scope：限定样式作用的 DOM 范围，同等优先级下离作用域根更近的规则胜出。

2.5 现代 CSS 新能力

这几年 CSS 新增的能力，很多以前要靠 JS 或第三方库实现：

2.5.1 容器查询 @container

媒体查询看的是视口宽度，容器查询看的是父容器的宽度，同一个组件放在侧边栏和主内容区会自动适配，这才是真正的「组件级响应式」：

.card-list {
  container-type: inline-size;
}

@container (min-width: 600px) {
  .card {
    display: grid;
    grid-template-columns: 200px 1fr;
  }
}

2.5.2 原生弹层：popover 与 dialog

<button popovertarget="menu">打开菜单</button>
<div id="menu" popover>点击外部或按 Esc 自动关闭</div>

<dialog id="confirm">
  <form method="dialog"><button>确定</button></form>
</dialog>
<!-- confirm.showModal() 打开模态框：自带遮罩、焦点锁定、Esc 关闭 -->

两者都渲染在顶层（top layer），不受父元素 overflow: hidden 和 z-index 的影响，以前写弹窗要处理的层级、焦点、点击外部关闭等问题，浏览器都处理好了。

2.5.3 锚点定位 Anchor Positioning

让一个元素相对另一个元素定位（tooltip、下拉菜单），空间不够时还能自动翻转，以前要靠 Popper / Floating UI 计算：

.trigger {
  anchor-name: --trigger;
}
.tooltip {
  position: absolute;
  position-anchor: --trigger;
  position-area: top; /* 放在锚点上方 */
  position-try-fallbacks: flip-block; /* 上方放不下就翻到下方 */
}

Chromium 和 Safari 26 已经支持，生产环境要注意兼容性，可以用 Floating UI 兜底。

2.5.4 View Transitions

页面状态切换时，浏览器自动给前后两个画面做过渡动画：

// 同一页面内：把 DOM 更新包在 startViewTransition 里
document.startViewTransition(() => updateTheDOM())

/* 跨文档（多页应用）的页面跳转也能有过渡，两个页面都要声明 */
@view-transition {
  navigation: auto;
}
/* 给元素起同一个名字，前后两个页面里的它会平滑变形过去 */
.hero {
  view-transition-name: hero;
}

2.5.5 滚动驱动动画

动画进度跟着滚动位置走，阅读进度条、视差、元素进场效果都不用再监听 scroll 事件，而且动画跑在合成线程上，不占主线程：

.progress {
  animation: grow linear;
  animation-timeline: scroll(); /* 跟随最近的滚动容器 */
}
@keyframes grow {
  from { transform: scaleX(0); }
  to { transform: scaleX(1); }
}

2.5.6 颜色和其他

• color-mix(in oklch, var(--brand) 80%, white)：按比例混合颜色，主题色的浅色、深色变体不再需要预处理器。
• 相对颜色语法：oklch(from var(--brand) calc(l + 0.1) c h)，基于已有颜色调整亮度、饱和度。
• oklch()：感知均匀的色彩空间，调亮度时色相不会跑偏，也能表示广色域颜色。
• 原生嵌套：.card { & .title { ... } }，大部分场景不再需要 Sass。
• :has()、@layer、@scope 见上文的 选择器，优先级。

2.5.7 布局方式怎么选

• 一维排列（导航栏、按钮组、表单行）用 flex；
• 二维结构（页面骨架、卡片网格）用 grid，子元素要和父网格对齐时用 subgrid；
• 组件要根据所在容器适配时用 @container，根据视口适配时才用媒体查询；
• float 只用来做文字环绕图片，absolute 只用于弹层、角标这类脱离文档流的元素。

三、页面布局

3.1 三栏布局

题目：左右两栏固定 300px，中间自适应。生产环境的默认答案是 grid 或 flex：

/* grid：二维布局，一行声明三列 */
.layout {
  display: grid;
  grid-template-columns: 300px 1fr 300px;
}

/* flex：一维布局，中间 flex: 1 占满剩余空间 */
.layout {
  display: flex;
}
.layout .left,
.layout .right {
  width: 300px;
}
.layout .center {
  flex: 1;
  min-width: 0; /* 防止长内容撑破布局 */
}

面试时常会追问「还有哪些方法、各有什么问题」，五种方案对比如下：

<section class="layout grid">
  <style>
    .layout.grid .left-center-right {
      width: 100%;
      display: grid;
      grid-template-rows: 100px;
      grid-template-columns: 300px auto 300px;
    }
    .layout.grid .left-center-right > div {
    }
    .layout.grid .left {
      width: 300px;
      background: red;
    }
    .layout.grid .center {
      background: yellow;
    }
    .layout.grid .right {
      background: blue;
    }
  </style>
  <h1>三栏布局</h1>
  <article class="left-center-right">
    <div class="left"></div>
    <div class="center">
      <h2>网格布局解决方案</h2>
      1.这是三栏布局的浮动解决方案； 2.这是三栏布局的浮动解决方案；
      3.这是三栏布局的浮动解决方案； 4.这是三栏布局的浮动解决方案；
      5.这是三栏布局的浮动解决方案； 6.这是三栏布局的浮动解决方案；
    </div>
    <div class="right"></div>
  </article>
</section>

<section class="layout flexbox">
  <style>
    .layout.flexbox {
      margin-top: 110px;
    }
    .layout.flexbox .left-center-right {
      display: flex;
    }
    .layout.flexbox .left {
      width: 300px;
      background: red;
    }
    .layout.flexbox .center {
      flex: 1;
      background: yellow;
    }
    .layout.flexbox .right {
      width: 300px;
      background: blue;
    }
  </style>
  <h1>三栏布局</h1>
  <article class="left-center-right">
    <div class="left"></div>
    <div class="center">
      <h2>flexbox解决方案</h2>
      1.这是三栏布局的浮动解决方案； 2.这是三栏布局的浮动解决方案；
      3.这是三栏布局的浮动解决方案； 4.这是三栏布局的浮动解决方案；
      5.这是三栏布局的浮动解决方案； 6.这是三栏布局的浮动解决方案；
    </div>
    <div class="right"></div>
  </article>
</section>

<section class="layout float">
  <style media="screen">
    .layout.float .left {
      float: left;
      width: 300px;
      background: red;
    }
    .layout.float .center {
      background: yellow;
    }
    .layout.float .right {
      float: right;
      width: 300px;
      background: blue;
    }
  </style>
  <h1>三栏布局</h1>
  <article class="left-right-center">
    <div class="left"></div>
    <div class="right"></div>
    <div class="center">
      <h2>浮动解决方案</h2>
      1.这是三栏布局的浮动解决方案； 2.这是三栏布局的浮动解决方案；
      3.这是三栏布局的浮动解决方案； 4.这是三栏布局的浮动解决方案；
      5.这是三栏布局的浮动解决方案； 6.这是三栏布局的浮动解决方案；
    </div>
  </article>
</section>

<section class="layout absolute">
  <style>
    .layout.absolute .left-center-right > div {
      position: absolute;
    }
    .layout.absolute .left {
      left: 0;
      width: 300px;
      background: red;
    }
    .layout.absolute .center {
      left: 300px;
      right: 300px;
      background: yellow;
    }
    .layout.absolute .right {
      right: 0;
      width: 300px;
      background: blue;
    }
  </style>
  <h1>三栏布局</h1>
  <article class="left-center-right">
    <div class="left"></div>
    <div class="center">
      <h2>绝对定位解决方案</h2>
      1.这是三栏布局的浮动解决方案； 2.这是三栏布局的浮动解决方案；
      3.这是三栏布局的浮动解决方案； 4.这是三栏布局的浮动解决方案；
      5.这是三栏布局的浮动解决方案； 6.这是三栏布局的浮动解决方案；
    </div>
    <div class="right"></div>
  </article>
</section>

<section class="layout table">
  <style>
    .layout.table .left-center-right {
      width: 100%;
      height: 100px;
      display: table;
    }
    .layout.table .left-center-right > div {
      display: table-cell;
    }
    .layout.table .left {
      width: 300px;
      background: red;
    }
    .layout.table .center {
      background: yellow;
    }
    .layout.table .right {
      width: 300px;
      background: blue;
    }
  </style>
  <h1>三栏布局</h1>
  <article class="left-center-right">
    <div class="left"></div>
    <div class="center">
      <h2>表格布局解决方案</h2>
      1.这是三栏布局的浮动解决方案； 2.这是三栏布局的浮动解决方案；
      3.这是三栏布局的浮动解决方案； 4.这是三栏布局的浮动解决方案；
      5.这是三栏布局的浮动解决方案； 6.这是三栏布局的浮动解决方案；
    </div>
    <div class="right"></div>
  </article>
</section>

3.2 未知宽高元素水平垂直居中

默认用 grid 或 flex，都不需要知道子元素的宽高：

/* grid：最简洁 */
.father {
  display: grid;
  place-items: center;
}

/* flex */
.father {
  display: flex;
  align-items: center;
  justify-content: center;
}

子元素需要脱离文档流（比如弹层）时，用 absolute + transform：

.father {
  position: relative;
}
.son {
  position: absolute;
  top: 50%;
  left: 50%;
  transform: translate(-50%, -50%);
}

另外 2024 年起 align-content: center 在普通块级容器（非 flex / grid）上也生效了，一行就能让块内容垂直居中。

面试时再按「是否脱离文档流、是否依赖子元素尺寸」补充几种老方案：absolute + margin: auto（子元素必须有宽高，严格来说不算未知宽高）、display: table-cell + vertical-align: middle、行内块 + 伪元素撑高 + vertical-align: middle。它们现在只在维护老代码时会遇到，写法见 HTML / CSS 笔记 · 垂直居中。

四、渲染机制

4.1 DOCTYPE

4.1.1 DOCTYPE 及 作用

DOCTYPE 是 document type(文档类型的）的简写 作用：

告诉浏览器需要通过哪一种规范（文档类型定义，DTD）解析文档（比如HTML或XHTML规范） DTD 告诉浏览器，我是什么文档类型。浏览器根据这个来判断用什么浏览引擎来解析它渲染它 DOCTYPE 就是直接告诉浏览器什么是 DTD。告诉浏览器包含哪个 DTD，也就是哪个文档类型

4.1.2 常见的 DOCTYPE 声明

<!-- HTML 5 -->
<!doctype html>

<!-- HTML 4.01 Strict -->
<!-- 这个 DTD 包含所有 HTML 元素和属性，但不包括展示性的和弃用的元素(比如 font) -->
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">

<!-- HTML 4.01 Transitional -->
<!-- 这个 DTD 包含所有 HTML 元素和属性，包括展示性的和弃用的元素(比如 font) -->
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">

面试注意：

• 一个 strict，一个 loose。不用记怎么写。
• 知道 4.01 有两个模式，一个严格模式，一个传统模式。
• 知道 HTML5 怎么写。能说出严格和宽松的区别。
• 如果严格模式，使用了弃用的元素，页面是有问题的。宽松模式没有问题。

HTML5 已经不基于 SGML，也就没有 DTD 了，<!doctype html> 的唯一作用是让浏览器进入标准模式。缺少或写错 doctype 会进入怪异模式（quirks mode），比如盒模型按 IE 的 border-box 算、表格字体不继承等。可以在控制台用 document.compatMode 查看：CSS1Compat 是标准模式，BackCompat 是怪异模式。HTML 4.01 那两种写法现在只在维护老页面时会遇到。

4.2 浏览器渲染过程

抛出一个老生常谈的面试问题：从输入 URL 到页面加载完成，发生了什么？ 首先我们需要通过 DNS域名解析，将 URL 解析为对应的 IP 地址，然后与这个 IP 地址确定的那台服务器建立起 TCP 网络连接，随后我们向服务端抛出我们的 HTTP 请求，服务端处理完我们的请求之后，把目标数据放在 HTTP 响应里返回给客户端，拿到响应数据的浏览器就可以开始走一个渲染的流程。渲染完毕，页面便呈现给了用户，并时刻等待响应用户的操作。

面试大白话解释：

输入 url，会有一个 dns 解析，然后发到服务器，服务器再响应，响应过来，到了客户端，浏览器这边就开始渲染过程

过程片段分为：

• DNS解析
• TCP连接
• HTTP请求
• service处理，HTTP响应返回
• 浏览器拿到数据，解析响应内容，展示数据内容

flowchart LR
  H[HTML] --> HP[解析 HTML] --> DOM[/生成 DOM 树/]
  C[CSS] --> CP[解析 CSS] --> CSSOM[/生成 CSSOM 树/]
  DOM --> A[合并]
  CSSOM --> A
  A --> RT[/生成渲染树/] --> L[布局] --> P[绘制] --> D([显示])

渲染过程很复杂，但是不会说的那么细。几句话说清就好了。

浏览器拿到 HTML 和 css 之后要干什么？

HTML 经过 HTML parser 转化成 DOM tree，css 按着 css 规则和 css 解释器，转成 CSSOM Tree，两棵树之间一整合，就是 attachment，形成一个 render tree，告诉浏览器渲染的树的结构就出来了。render tree 不包含 html 具体内容，也不知道具体位置是什么。比如有一个 div，layout 之前，不知道画在具体什么位置。这时候通过 layout 就可以精确计算到要显示的这些 dom 真正的宽高，位置颜色，最后开始 paint，画图，把内容呈现出来。最后 display，在浏览器上能看到页面效果。

CSSOM 树和 DOM 树连接在一起形成一个 render tree，渲染树用来计算可见元素的布局并且作为将像素渲染到屏幕上的过程的输入。

DOM 树和 CSSOM 树连接在一起形成 render tree .

render tree 只包含了用于渲染页面的节点布局计算了每一个对象的准确的位置以及大小绘画是最后一步，绘画要求利用 render tree 来将像素显示到屏幕上第一步是结合 DOM 树和 CSSOM 树形成“render tree”，渲染树用来描述所有可见的 DOM 内容，并且将 CSSOM 样式信息附加到节点上。

为了形成渲染树，浏览器大致做的事情有:从 DOM 树根节点开始，遍历每一个可见的节点一些节点是完全不可见的（比如 script 标签，meta 标签等），这些节点会被忽略，因为他们不会影响渲染的输出一些节点是通过 CSS 样式隐藏了，这些节点同样被忽略——例如上例中的 span 节点在 render tree 中被忽略，因为 span 样式是 display:none;对每一个可见的节点，找到合适的匹配的 CSSOM 规则，并且应用样式显示可见节点（节点包括内容和被计算的样式）

让我们快速的浏览下浏览器所做的事情：

处理 HTML 标签建立 DOM 树

处理 CSS 标签建立 CSSOM 树

连接 CSSOM 树和 DOM 树形成一个 render 树

在 render 树上运行布局来计算每个节点的形状

在屏幕上画每一个节点

虽然我们的页面很简单，但是它进行了大量的工作！

现代浏览器（以 Chromium 的 RenderingNG 为例）的渲染流水线比上面多了几步，面试时能说出来是加分项：

1. Parse：HTML → DOM，CSS → CSSOM。预加载扫描器（preload scanner）会提前发现 <img>、<script>、<link> 并发起请求。
2. Style：计算每个节点的最终样式。
3. Layout：计算几何信息，生成布局树（layout tree，也就是上面说的 render tree）。
4. Paint：生成绘制指令列表，不是直接画像素。
5. Composite：按图层（layer）分块光栅化，交给合成线程 / GPU 合成上屏。

关键结论：改 transform、opacity 只走 Composite，不触发 Layout 和 Paint，所以动画优先用这两个属性。另外现在问「从输入 URL 到页面展示」，还可以补充 HTTP 缓存、HTTP/2 和 HTTP/3、TLS 握手、多进程架构（浏览器进程、网络进程、渲染进程）这些点。

4.3 重绘与重排

4.3.1 重绘（repaint 或 redraw）

定义：当盒子的位置、大小以及其他属性，例如颜色、字体大小等都确定下来之后，浏览器便把这些原色都按照各自的特性绘制一遍，将内容呈现在页面上。重绘是指一个元素外观的改变所触发的浏览器行为，浏览器会根据元素的新属性重新绘制，使元素呈现新的外观。 这个过程称之为重绘。

触发重绘的条件：

1. DOM 改动
2. CSS 改动

4.3.2 重排（重构/回流/reflow）

定义：当渲染树中的一部分(或全部)因为元素的规模尺寸，布局，隐藏等改变而需要重新构建, 这就称为回流(reflow)。每个页面至少需要一次回流，就是在页面第一次加载的时候。

触发 Reflow：

1. 当你增加、删除、修改 DOM 节点时，会导致 Reflow 或 Repaint
2. 当你移动 DOM 的位置，或是搞个动画的时候
3. 当你修改 CSS 样式的时候
4. 当你 Resize 窗口的时候（移动端没有这个问题），或者滚动的时候
5. 当你修改网页的默认字体时

注意： table 及其内部元素可能需要多次计算才能确定好其在渲染树中节点的属性值，比同等元素要多花两倍时间，这就是我们尽量避免使用 table 布局页面的原因之一。

4.3.3 重绘和重排的关系

在回流的时候，浏览器会使渲染树中受到影响的部分失效，并重新构造这部分渲染树，完成回流后，浏览器会重新绘制受影响的部分到屏幕中，该过程称为重绘。所以，重排必定会引发重绘，但重绘不一定会引发重排。

4.3.4 如何尽量减小重绘？

重绘无法避免，但是最大程度减小。比如把用户输入计算条件，把输入隐藏掉，计算结果显示出来。两个交互，用户输入，然后输入隐藏，结果展示。这个过程，呈现内容不一样了。怎么做，少画一些东西。就是要把最后的结果，放在一个节点，就算有很多结果，也不要一个一个添加，而是放在一个片段（DocumentFragment）里面，然后一次添加片段。也就是重绘一次。不然你加一个节点，重新重绘一次。 简单来说，能批量操作就批量操作。

浏览器本身会把同一帧里的多次 DOM 修改合并处理，真正的性能杀手是强制同步布局：先改样式，紧接着读 offsetHeight、getBoundingClientRect() 这类布局属性，浏览器只能立刻重新计算布局；在循环里读写交替就是「布局抖动（layout thrashing）」。应对办法：

• 读写分离，先集中读，再集中写；动画写在 requestAnimationFrame 里。
• 动画用 transform / opacity，必要时加 will-change（别滥用，每个图层都占内存）。
• 长列表用虚拟滚动，屏幕外的区块加 content-visibility: auto 跳过渲染。
• 用 contain 限制布局影响范围。

在 React / Vue 里这件事大多由框架的批量更新完成，手动操作 DOM 时才需要特别注意。

4.4 Links

渲染树构建、布局及绘制：https://web.dev/articles/critical-rendering-path/render-tree-construction

RenderingNG 架构：https://developer.chrome.com/docs/chromium/renderingng-architecture

五、页面性能

提升页面性能的方法有哪些？

1. 资源压缩合并，减少 HTTP 请求 或者 避免同一时间的过多次数请求
2. 非核心代码异步加载 -> 异步加载的方式 -> 异步加载的区别
3. 利用浏览器缓存 -> 缓存的分类 -> 缓存的原理
4. 利用 CDN
5. 预解析 DNS

5.1 资源压缩与合并

主要包括这些方面：压缩代码HTML/CSS/JS，压缩图片与其他资源，Tree-Shaking消除无用代码，以上Webpack构建项目可以搞定（Webpack 相关细节见 Webpack 学习总结）

资源压缩可以从文件中去掉多余的字符，比如回车、空格。你在编辑器中写代码的时候，会使用缩进和注释，这些方法无疑会让你的代码简洁而且易读，但它们也会在文档中添加多余的字节

5.1.1 html 压缩

html 代码压缩就是压缩这些在文本文件中有意义，但是在 HTML 中不显示的字符，包括空格，制表符，换行符等，还有一些其他意义的字符，如 HTML 注释也可以被压缩。

使用在线网站进行压缩(开发过程中一般不用)

nodejs 提供了 html-minifier 工具

后端模板引擎渲染压缩

5.1.2 css 压缩

css 代码压缩简单来说就是无效代码删除和 css 语义合并

使用在线网站进行压缩(开发过程中一般不用)

使用 html-minifier 工具

使用 clean-css 对 css 压缩

5.1.3 js 的压缩和混乱

js 的压缩和混乱主要包括以下这几部分：

• 无效字符的删除
• 剔除注释
• 代码语义的缩减和优化
• 代码保护(代码逻辑变得混乱，降低代码的可读性，这点很重要)

使用在线网站进行压缩(开发过程中一般不用)

使用 html-minifier 工具

使用 uglifyjs2 对 js 进行压缩

上面的工具名已经过时：uglify-js 不支持新语法，早被 terser 取代，现在构建工具更常用 esbuild / SWC / oxc 自带的 minifier；CSS 压缩用 cssnano 或 Lightning CSS；html-minifier 停止维护后社区用 html-minifier-terser。这些通常都内置在 Vite、Rspack、Next.js 里，不需要单独配置。传输层再叠加 gzip / Brotli（现在还有 zstd）压缩。

5.2 避免同时间段请求过多

• CSS 实现雪碧图：使用background-position共享一张图（HTTP/2 多路复用之后合并请求的收益变小，图标现在多用 SVG sprite 或 icon 组件）
• 图片懒加载：监听滚动后offsetTop, 用 data-src 替换 src（真实路径）。现在直接用原生 <img loading="lazy">，或用 IntersectionObserver 代替监听 scroll
• 列表懒加载（分批加载）：监听滚动后offsetTop， 发送请求加载下一页的数据（同样推荐用 IntersectionObserver 观察底部的哨兵元素）
• 路由懒加载
• 代码分包分块加载（webpack）
• 预加载技术
• 小程序分包、预下载
• 等

5.3 异步加载

5.3.1 动态脚本创建

在还没定义 defer 和 async 前，异步加载的方式是动态创建 script，通过 window.onload 确保页面加载完毕再将 script 标签插入到 DOM 中。具体代码如下（readyState 分支只为兼容旧 IE，现在可以删掉；动态插入的脚本默认就是 async 的）

function loadJS(url, callback) {
  let script = document.createElement('script')
  script.type = 'text/javascript'
  // IE
  if (script.readyState) {
    script.onreadystatechange = function () {
      if (script.readyState == 'loaded' || script.readyState == 'complete') {
        script.onreadystatechange = null
        if (typeof callback === 'function') {
          callback()
        }
      }
    }
  } else {
    script.onload = function () {
      if (typeof callback === 'function') {
        callback()
      }
    }
  }
  script.src = url
  document.getElementsByTagName('head')[0].appendChild(script)
}
window.onload = function () {
  loadJS('js/index.js', () => {})
}

5.3.2 defer

• 兼容所有浏览器
• defer 属性规定是否对脚本执行进行延迟，直到页面加载为止
• 如果是多个脚本，该方法可以确保所有设置了 defer 属性的脚本按顺序执行
• 如果脚本不会改变文档的内容，可将 defer 属性加入到 script 标签中，以便加快处理文档的速度

<script defer type="text/javascript" src="js/index.js"></script>

5.3.3 async

• async 属性是 HTML5 新增属性，现代浏览器都支持
• async 属性规定一旦脚本可用，则会异步执行
• async 属性仅适用于外部脚本（对 type="module" 的内联脚本也有效）
• 如果是多个脚本，该方法不能保证脚本按顺序执行

<script async type="text/javascript" src="js/index.js"></script>

5.3.4 注意

• defer 是在 HTML 解析完之后、DOMContentLoaded 之前执行，如果是多个，按照在文档中出现的顺序依次执行
• async 是在加载完之后立即执行（会打断 HTML 解析），如果是多个，执行顺序和加载顺序无关，谁先下载完谁先执行

实测补充：网上常说 defer 不会阻碍页面渲染，但在 iOS Safari 上测试时仍出现过白屏，效果和普通 script 标签一样。

现代项目里还要注意：

• <script type="module"> 默认就是 defer 行为，再加 async 则变成下载完立即执行。现在用 Vite 等工具构建的项目，入口基本都是 module 脚本。
• 需要调整加载优先级时用 fetchpriority="high|low"，比如把首屏 LCP 图片设为 high。
• 统计、客服这类第三方脚本适合 async，或者等到 requestIdleCallback / 用户交互后再动态加载。

5.4 浏览器缓存

浏览器缓存机制有四个方面，常见的说法是按照获取资源时请求的优先级依次排列如下：

1. Memory Cache
2. Service Worker Cache
3. HTTP Cache
4. Push Cache

Push Cache 来自 HTTP/2 Server Push，Chrome 106（2022 年）起已移除 Server Push，其他浏览器也基本不再支持，替代方案是 103 Early Hints + preload。另外严格来说 Service Worker 会先于 HTTP 缓存拦截请求，Memory Cache 是渲染进程内的短期缓存（同一页面内重复使用的资源），各浏览器实现细节不完全一致，面试时说清「SW 能完全接管请求，HTTP 缓存分强缓存和协商缓存」就够了。

HTTP 缓存是我们日常开发中最为熟悉的一种缓存机制。它又分为强缓存和协商缓存。 优先级较高的是强缓存，在命中强缓存失败的情况下，才会走协商缓存。

5.4.1 强缓存

不会向服务器发送请求，直接从缓存中读取资源，HTTP 状态码为 200（DevTools 里显示 from memory cache / from disk cache）

强缓存是利用 http 头中的 Expires 和 Cache-Control 两个字段来控制的。强缓存中，当请求再次发出时，浏览器会根据其中的 expires 和 cache-control 判断目标资源是否“命中”强缓存，若命中则直接从缓存中获取资源，不会再与服务端发生通信。

一个命中强缓存的响应头示例：

cache-control: max-age=600
content-type: image/gif
date: Sat, 29 Aug 2020 08:33:05 GMT
expires: Sat, 29 Aug 2020 08:43:05 GMT
last-modified: Mon, 20 Nov 2017 12:09:19 GMT
status: 200

5.4.1.1 expires

expires: Sat, 29 Aug 2020 08:43:05 GMT

当服务端返回响应时，在 Response Header 中将过期时间写入 expires 字段中。 如上面的响应头所示：expires 存储的过期时间为 Sat, 29 Aug 2020 08:43:05 GMT，当浏览器再次加载对应资源文件时，如果在这个过期时间内，则命中强缓存。反之重新获取。

expires 问题描述：

它最大的问题在于对本地时间的依赖。 如果服务端和客户端的时间不一致，或用户手动调整了客户端时间，那么 expires 将无法达到我们的预期效果。

5.4.1.2 Cache-Control

Cache-Control 可在请求报文与响应报文中设置

max-age

cache-control: max-age=600

如上面的响应头所示：cache-control 通过 max-age 来控制资源的有效期，value 值为时间长度，秒为单位，用数值表示。则代表在这个请求正确返回时间（浏览器也会记录下来）的 600 秒内再次加载资源，就会命中强缓存。完美地规避了时间戳带来的潜在问题。

s-maxage

细节注意： s-maxage 仅在代理服务器中生效，客户端中我们只考虑 max-age

cache-control: max-age=600, s-maxage=3600

s-maxage 就是用于表示 cache 服务器上（比如 cache CDN）的缓存的有效时间的，只对共享缓存有效 s-maxage 优先级高于 max-age，当两者同时出现时，共享缓存优先考虑 s-maxage 如果 s-maxage 未过期，则向代理服务器请求其缓存内容

public：所有内容都将被缓存（客户端和代理服务器都可缓存） private：所有内容只有客户端可以缓存

Cache-Control 没有默认值。响应里既没有 Cache-Control 也没有 Expires，但带了 Last-Modified 时，浏览器会做启发式缓存，通常按 (Date - Last-Modified) × 10% 估算有效期，这也是「明明没配缓存却读到旧文件」的常见原因。

简单概括： 两者同时存在的话，Cache-Control 优先级高于 Expires expires 与 cache-control 两者区别就在于 expires 是 HTTP/1.0 的产物，cache-control 是 HTTP/1.1 的产物。 在某些不支持 HTTP/1.1 的环境下，expires 就会发挥用处。所以 expires 其实是过时的产物，现阶段它的存在是一种向下兼容。 因此，cache-control 可以视作是 expires 的完全替代方案。

思考：

强缓存判断是否缓存的依据来自于是否超出某个时间或者某个时间段，而不关心服务器端文件是否已经更新，这可能会导致加载文件不是服务器端最新的内容，那我们如何获知服务器端内容较客户端是否已经发生了更新呢？此时我们需要协商缓存策略。

5.4.2 协商缓存

协商缓存依赖于服务端与浏览器之间的通信

协商缓存就是强制缓存失效后，浏览器携带缓存标识向服务器发起请求，服务器会根据这个请求的 request header 的一些参数来判断是否命中协商缓存，如果命中，**直接返回 304 状态码，内容为空，**并带上新的 response header 通知浏览器从缓存中读取资源；另外协商缓存需要与 cache-control 共同使用。

5.4.2.1 Last-Modified 和 If-Modified-Since

• 当第一次请求资源时，服务器将资源传递给客户端时，会将资源最后更改的时间以 Last-Modified 的形式加在实体首部上一起返回给客户端；
• 随后接下每次请求时，都会带上 If-Modified-Since 字段的时间戳字段，值为上一次 response 返回给它的 Last-Modified 值；
• 服务器接收到这个时间戳后，会比对该时间戳和资源在服务器上的最后修改时间是否一致，从而判断资源是否发生了变化。如果发生了变化，就会返回一个完整的响应内容，并在 Response Headers 中添加新的 Last-Modified 值；否则，返回如上图的 304 响应，Response Headers 不会再添加 Last-Modified 字段。

Last-Modified: Sat, 29 Aug 2020 08:43:05 GMT
If-Modified-Since: Sat, 29 Aug 2020 08:43:05 GMT

sequenceDiagram
  participant B as 浏览器
  participant S as 服务器
  B->>S: GET /doge.png
  S-->>B: 200 OK，带上 Last-Modified
  B->>S: GET /doge.png，带上 If-Modified-Since
  S-->>B: 304 Not Modified，响应体为空

但 Last-Modified 存在一些缺点：

• 某些服务端不能获取精确的修改时间
• 文件修改时间改了，但文件内容却没有变

既然根据文件修改时间来决定是否缓存尚有不足，能否可以直接根据文件内容是否修改来决定缓存策略？如下介绍

5.4.2.2 ETag 和 If-None-Match

Etag 是上一次加载资源时，服务器返回的 response header，是对该资源的一种唯一标识，只要资源有变化，Etag 就会重新生成。浏览器在下一次加载资源向服务器发送请求时，会将上一次返回的 Etag 值放到 request header 里的 If-None-Match 里，服务器只需要比较客户端传来的 If-None-Match 跟自己服务器上该资源的 ETag 是否一致，就能很好地判断资源相对客户端而言是否被修改过了。如果服务器发现 ETag 匹配不上，那么直接以常规 GET 200 回包形式将新的资源（当然也包括了新的 ETag）发给客户端；如果 ETag 是一致的，则直接返回 304 知会客户端直接使用本地缓存即可。

sequenceDiagram
  participant C as 客户端
  participant S as 服务器
  C->>S: 请求页面 A
  S-->>C: 页面 A + ETag
  C->>S: 再次请求页面 A，带上 If-None-Match
  S->>S: 比较 ETag
  S-->>C: 304 + 空响应体

两者之间对比：

• 首先在精确度上，Etag 要优于 Last-Modified。Last-Modified 的时间单位是秒，如果某个文件在 1 秒内改变了多次，那么他们的 Last-Modified 其实并没有体现出来修改，但是 Etag 每次都会改变确保了精度；如果是负载均衡的服务器，各个服务器生成的 Last-Modified 也有可能不一致。
• 第二在性能上，Etag 要逊于 Last-Modified，毕竟 Last-Modified 只需要记录时间，而 Etag 需要服务器通过算法来计算出一个 hash 值。
• 第三在优先级上，服务器校验优先考虑 Etag

缓存的机制： 强制缓存优先于协商缓存进行，若强制缓存(Expires 和 Cache-Control)生效则直接使用缓存，若不生效则进行协商缓存(Last-Modified / If-Modified-Since 和 Etag / If-None-Match)，协商缓存由服务器决定是否使用缓存，若协商缓存失效，那么代表该请求的缓存失效，重新获取请求结果，再存入浏览器缓存中；生效则返回 304，继续使用缓存。主要过程如下：

flowchart TD
  A[浏览器请求资源] --> B{有缓存吗}
  B -->|否| C[向服务器请求] --> D[返回资源和缓存标识，存入缓存] --> Z[页面加载完成]
  B -->|是| E{过期了吗，看 Cache-Control 和 Expires}
  E -->|没过期，命中强缓存| F[直接读取缓存] --> Z
  E -->|过期了| G[带上 If-None-Match 和 If-Modified-Since 向服务器请求]
  G --> H{资源有更新吗}
  H -->|没有| I[304，继续使用缓存] --> F
  H -->|有| J[200，返回新资源和新标识，存入缓存] --> Z

优先级：Cache-Control 高于 Expires，ETag / If-None-Match 高于 Last-Modified / If-Modified-Since。

用户行为对浏览器缓存的影响：

1. 地址栏访问，链接跳转是正常用户行为，将会触发浏览器缓存机制；
2. F5 刷新，浏览器会设置 max-age=0，跳过强缓存判断，会进行协商缓存判断；
3. ctrl+F5 刷新，跳过强缓存和协商缓存，直接从服务器拉取资源。

5.4.3 其他缓存与浏览器存储

除了 HTTP 缓存，前端还能用到这些：

• Service Worker + Cache Storage：可编程的缓存，能实现离线访问（PWA）
• 浏览器存储（ Cookie, LocalStorage, SessionStorage, IndexedDB ）

5.5 CDN 优化

• 静态资源全部上 CDN，文件名带内容 hash，配合长期强缓存（max-age=31536000, immutable）
• 静态资源用独立域名，避免携带主站 Cookie
• 开启 HTTP/2、HTTP/3 和 Brotli 压缩
• 图片走 CDN 的实时处理：按设备裁剪尺寸、自动转 AVIF / WebP
• 用 <link rel="preconnect"> / dns-prefetch 提前和 CDN 域名建连
• 关注缓存命中率，发版时按需刷新或预热；HTML 不要长缓存
• 边缘计算（Cloudflare Workers、Vercel Edge 等）把 SSR、鉴权、A/B 测试放到离用户最近的节点
• 第三方公共 CDN 上的脚本加 SRI 校验；注意浏览器缓存早已按站点分区，「多个网站共用 CDN 上的 jQuery 可以命中缓存」这个老理由已经不成立

5.6 性能分析：Performance API

市面上的性能监控工具，主要依靠的都是 Performance API。

5.6.1 Navigation Timing：加载各阶段耗时

上图是页面加载过程中的关键时间点。旧的 performance.timing 已经废弃，现在用 Navigation Timing Level 2：字段名基本沿用，只是改成了相对页面开始时间（startTime 为 0）的高精度时间。

const [nav] = performance.getEntriesByType('navigation')
console.table({
  重定向: nav.redirectEnd - nav.redirectStart,
  DNS: nav.domainLookupEnd - nav.domainLookupStart,
  TCP: nav.connectEnd - nav.connectStart,
  TLS: nav.secureConnectionStart ? nav.connectEnd - nav.secureConnectionStart : 0,
  首字节TTFB: nav.responseStart - nav.startTime,
  内容下载: nav.responseEnd - nav.responseStart,
  DOM解析: nav.domInteractive - nav.responseEnd,
  DOMContentLoaded: nav.domContentLoadedEventEnd - nav.startTime,
  load: nav.loadEventEnd - nav.startTime,
})

getEntriesByType('resource') 可以拿到每个静态资源的同样一组时间，用来找出慢资源；performance.mark() / performance.measure() 用来给业务逻辑自己打点。

5.6.2 PerformanceObserver 与 web-vitals

responseStart 只能算首字节时间，真正的「白屏时间」应该看 FP / FCP。getEntriesByType 是一次性读取，拿不到之后才产生的条目，现在统一用 PerformanceObserver 订阅：

new PerformanceObserver((list) => {
  for (const entry of list.getEntries()) {
    console.log(entry.entryType, entry.name, entry.startTime)
  }
}).observe({ type: 'largest-contentful-paint', buffered: true })
// 其他常用 type：paint（FP/FCP）、layout-shift、event、longtask、long-animation-frame、resource

LCP / INP / CLS 的计算规则有不少细节，实际项目直接用 Google 的 web-vitals 库：onLCP(report)、onINP(report)、onCLS(report)，每个回调还能拿到归因信息（attribution），比如 LCP 元素是哪个、慢在哪个阶段。

5.6.3 INP 与长任务

INP 统计页面整个生命周期内的交互，取接近最差的那一次（交互次数很多时会忽略少数极端值）。一次交互的耗时分三段：输入延迟（主线程正忙，事件排队等待）+ 处理时间（事件回调执行）+ 呈现延迟（样式计算、布局、绘制到下一帧）。

INP 差，绝大多数是因为主线程上有长任务（超过 50ms）。排查用 Long Animation Frames API（LoAF），它比旧的 Long Tasks API 多了归因信息，能看到是哪个脚本、哪个函数占用了这一帧。

优化手段：

• 拆分长任务，定期让出主线程，让浏览器有机会处理用户输入：

function yieldToMain() {
  // scheduler.yield 让出后会优先回到当前任务，不会被其他任务插队太久
  if (globalThis.scheduler?.yield) return scheduler.yield()
  return new Promise((resolve) => setTimeout(resolve, 0))
}

async function processAll(items) {
  let deadline = performance.now() + 50
  for (const item of items) {
    handle(item)
    if (performance.now() > deadline) {
      await yieldToMain()
      deadline = performance.now() + 50
    }
  }
}

• 事件回调里先做能让界面立刻响应的更新（比如按钮状态），重活放到下一帧或 requestIdleCallback；
• React 里用 useTransition 把非紧急更新标为可中断；
• 纯计算移到 Web Worker；
• 减少 DOM 规模，长列表用虚拟滚动，屏幕外内容用 content-visibility: auto。

5.6.4 SPA 的指标测量：软导航

Core Web Vitals 以「页面加载」为单位统计。SPA 里的路由切换（软导航）不会产生新的 LCP，这期间的 INP 和 CLS 也都算在首次加载的 URL 上，所以单看 Web Vitals 反映不了路由切换后的体验。Chrome 正在推进 Soft Navigations API 来解决这个问题；在它普及之前，RUM 需要自己在路由切换时用 performance.mark 打点，按路由统计渲染耗时。

5.6.5 图片与字体

• 图片：LCP 图片不要懒加载，加 fetchpriority="high"；用 srcset / sizes 按屏幕下发合适尺寸；用 <picture> 优先下发 AVIF，WebP 和 JPEG 兜底；一定要写 width / height 或 aspect-ratio，提前占位避免 CLS。
• 字体：关键字体用 <link rel="preload" as="font" type="font/woff2" crossorigin> 提前加载，并做子集化（中文字体尤其要做）；font-display: swap 先显示后备字体，optional 则在网络慢时直接放弃 Web 字体；用 size-adjust、ascent-override 把后备字体的尺寸调得和 Web 字体一致，减少字体切换时的布局偏移；可变字体一个文件包含多种字重，能减少请求数。

5.7 其他

SSR 服务器渲染：解决 SPA 框架带来的 JS 动态渲染页面带来的延迟和白屏问题。现在的选择更多：SSG 静态生成、ISR 增量再生成、流式 SSR（React 18+ 的 renderToPipeableStream）、React Server Components 减少下发到客户端的 JS，以及 Astro 这类 Islands 架构。

参考：

• Performance API MDN docs
• Performance API W3 docs
• 彻底理解浏览器的缓存机制
• 前端性能优化原理与实践
• 设计一个无懈可击的浏览器缓存方案：关于思路，细节，ServiceWorker，以及HTTP/2

六、DOM 事件

1. 基本概念：DOM 事件的级别
2. DOM 事件模型
3. DOM 事件流
4. 描述 DOM 事件捕获的具体流
5. Event 对象的常见应用
6. 自定义事件
7. 移动端触摸事件

6.1 事件级别

// DOM0
element.onclick = function () {}

// DOM2：第三个参数 false 冒泡（默认），true 捕获
element.addEventListener('click', function () {}, false)

// DOM3：写法同 DOM2，新增了更多事件类型（键盘、鼠标滚轮、焦点、文本输入等）
element.addEventListener('keyup', function () {}, false)

addEventListener 的第三个参数现在更常传对象：

const controller = new AbortController()
element.addEventListener('scroll', onScroll, {
  capture: false,
  once: false, // true：触发一次后自动移除
  passive: true, // 承诺不调用 preventDefault，滚动 / 触摸监听加上能避免卡顿
  signal: controller.signal, // controller.abort() 一次性移除所有绑定的监听
})

在组件卸载时用 AbortController 批量解绑，是现在避免监听器泄漏的推荐写法。

6.2 事件流

flowchart TD
  W[window] -->|捕获| D[document] --> H[html] --> B[body] --> T((目标元素))
  T -.->|冒泡| B
  B -.-> H
  H -.-> D
  D -.-> W

事件流分三个阶段：捕获阶段从 window 一路向下传到目标元素（实线），然后是目标阶段，最后冒泡阶段从目标元素一路向上传回 window（虚线）。

6.3 描述 DOM 事件捕获的具体流程

window.addEventListener(
  'click',
  function (e) {
    console.log('window capture')
  },
  true
)

document.addEventListener(
  'click',
  function (e) {
    console.log('document capture')
  },
  true
)

document.documentElement.addEventListener(
  'click',
  function (e) {
    console.log('html capture')
  },
  true
)
document.body.addEventListener(
  'click',
  function (e) {
    console.log('body capture')
  },
  true
)

ev.addEventListener(
  'click',
  function (e) {
    console.log('ev capture')
  },
  true
)

6.4 Event 对象的常见应用

event.preventDefault() // 阻止默认事件(a标签)
event.stopPropagation() // 阻止冒泡
event.stopImmediatePropagation() // 同一元素绑定了多个监听，A 中调用后 B 不再执行，同时也阻止冒泡
event.currentTarget //返回绑定事件的元素
event.target //返回触发事件的元素

6.5 自定义事件（code）

var eve = new Event('custom')
ev.addEventListener('custom', function () {
  console.log('custom')
})
// 事件在哪个元素上派发，就要在哪个元素（或它的祖先，需 bubbles: true）上监听
ev.dispatchEvent(eve)

// 需要携带数据时用 CustomEvent
const detailEvent = new CustomEvent('custom-detail', {
  detail: { id: 1 },
  bubbles: true,
})
ev.addEventListener('custom-detail', (e) => console.log(e.detail)) // { id: 1 }
ev.dispatchEvent(detailEvent)

6.6 移动端触摸事件

1. touchstart：当手指触碰到屏幕的时候触发
2. touchmove：当手指在屏幕上滑动的时候触发
3. touchend：当手指离开屏幕的时候时候触发
4. touchcancel 事件：当系统停止跟踪触摸的时候触发(少用)

touches：表示当前跟踪的触摸操作的 touch 对象的数组。

targetTouches：特定于事件目标的 Touch 对象的数组。

changedTouches：表示自上次触摸以来发生了什么改变的 Touch 对象的数组。

每个 touch 对象包含的属性:

1. clientX：触摸目标在视口中的 x 坐标。
2. clientY：触摸目标在视口中的 y 坐标。
3. identifier：标识触摸的唯一 ID。
4. pageX：触摸目标在页面中的 x 坐标。
5. pageY：触摸目标在页面中的 y 坐标。
6. screenX：触摸目标在屏幕中的 x 坐标。
7. screenY：触摸目标在屏幕中的 y 坐标。
8. target：触目的 DOM 节点目标。

新代码更推荐用 Pointer Events（pointerdown / pointermove / pointerup / pointercancel），一套 API 同时处理鼠标、触摸和触控笔，通过 event.pointerType 区分来源。配合 CSS touch-action 控制浏览器默认手势。以前为了消除移动端 300ms 点击延迟引入的 FastClick，在设置了 <meta name="viewport" content="width=device-width"> 的页面上早已不需要。

6.7 冒泡

当点击一个元素触发事件时，事件会先从最外层（window）一层一层进入到触发的元素，然后再从触发元素一层一层返回到最外层，从最外层一层一层进入的阶段叫事件捕获阶段，到达目标元素叫目标阶段，从最里层一层一层往外的阶段叫事件冒泡阶段。注意 focus、blur、mouseenter、mouseleave 等事件不冒泡（可以用会冒泡的 focusin / focusout 代替）。

6.8 事件委托

事件委托就是利用事件冒泡，只指定一个事件处理程序，就可以管理某一类型的所有事件

好处：给重复的节点添加相同操作，减少 dom 交互，提高性能

实现思路：给父组件添加事件，通过事件冒泡，排查元素是否为指定元素，并进行系列操作

list.addEventListener('click', (e) => {
  // closest 能处理点在 li 内部子元素上的情况
  const item = e.target.closest('li')
  if (!item || !list.contains(item)) return
  console.log(item.dataset.id)
})

React 17+ 把事件委托挂在应用根容器上（之前是 document），这也是一种事件委托。

七、JS 运行机制

console.log(1)
setTimeout(function () {
  console.log(2)
}, 0)
console.log(3)
// 1 3 2

console.log('A')
while (1) {}
console.log('B')
// A
// while同步，永远不会执行到B（相当于一个死循环）、

console.log('A')
setTimeout(function () {
  console.log('B')
}, 0)
while (1) {}
// A
// 因为setTimeout是一个异步队列，在同步任务完成之前，任何的异步队列是不会被响应的

for (var i = 0; i < 4; i++) {
  setTimeout(function () {
    console.log(i)
  }, 1000)
}
// 4 4 4 4
// settimeout是异步执行，1000ms后往任务队列里面添加一个任务，只有主线上的全部执行完，才会执行任务队列里的任务，当主线执行完成后，i是4，所以此时再去执行任务队列里的任务时，i全部是4了。
// 对于打印4次是：每一次for循环的时候，settimeout都执行一次，但是里面的函数没有被执行，而是被放到了任务队列里面，等待执行，for循环了4次，就放了4次，当主线程执行完成后，才进入任务队列里面执行

for (let i = 0; i < 4; i++) {
  setTimeout(function () {
    console.log(i)
  }, 1000)
}
// 0 1 2 3
// let 是块级作用域，每次循环都会创建一个新的 i 绑定，回调闭包捕获的是各自那一轮的 i

7.1 JS 的单线程的概念

7.1.1 概念

JavaScript的单线程，与它的用途有关。作为浏览器脚本语言，JavaScript的主要用途是与用户互动，以及操作DOM。这决定了它只能是单线程，否则会带来很复杂的同步问题。比如，假定JavaScript同时有两个线程，一个线程在某个DOM节点上添加内容，另一个线程删除了这个节点，这时浏览器应该以哪个线程为准？所以，为了避免复杂性，从一诞生，JavaScript就是单线程，这已经成了这门语言的核心特征，将来也不会改变。

一定时间内只能执行一项任务，不能执行多项任务，为了要执行的代码，就有一个 javascript 任务队列。基于这一概念，JS 执行任务时分为两种模式：同步和异步。

“同步模式”是指后一个任务必须等待前一个任务完成后再执行，前一个任务加载时会阻塞后面程序的进行；“异步模式”不一定按顺序执行任务，所以不会阻塞程序的运行。

7.1.2 注意

Web Worker标准的提出，为了利用多核CPU的计算能力，允许JavaScript脚本创建多个线程，但是子线程完全受主线程控制，且不得操作DOM。所以没有改变JavaScript单线程的本质。

7.1.3 大白话总结

同一时间只能做一件事情

7.2 任务队列

JS 任务队列中，有两类任务队列：宏任务队列（macro tasks）和微任务队列（micro tasks）。宏任务队列可以有多个，微任务队列只有一个。那么什么任务，会分到哪个队列呢？

• 宏任务：script脚本执行（全局任务）, setTimeout, setInterval, setImmediate定时事件（Node）, I/O操作, MessageChannel, 用户交互事件等。
• 微任务：node中process.nextTick, Promise回调（包括 await 之后的代码）, queueMicrotask, Dom变化监听MutationObserver.

（原来列的 Object.observe 提案早已撤回，UI rendering 也不算宏任务，而是事件循环中单独的渲染时机，见下文 7.3.1。）

flowchart TD
  A([任务进入执行栈]) --> B{同步还是异步}
  B -->|同步| C[进入主线程执行]
  B -->|异步| D[在 Event Table 注册回调]
  D -->|定时到期、请求返回等条件满足| E[回调进入 Event Queue]
  C --> F[主线程任务执行完毕，执行栈为空]
  F --> G[从 Event Queue 读取回调，放入主线程执行]
  E --> G
  G -->|循环往复| F

JS 运行整体流程

解释一下上图：

• 同步和异步任务分别进入不同的执行"场所"，同步的进入主线程，异步的进入 Event Table 并注册函数。
• 当指定的事情完成时，Event Table 会将这个函数移入 Event Queue。
• 主线程内的任务执行完毕为空，会去 Event Queue 读取对应的函数，进入主线程执行。
• 上述过程会不断重复，也就是常说的 Event Loop (事件循环)。

那主线程执行栈何时为空呢？js引擎存在 monitoring process 进程，会持续不断的检查主线程执行栈是否为空，一旦为空，就会去 Event Queue 那里检查是否有等待被调用的函数。

（Event Table、monitoring process 是很多中文文章里用来帮助理解的说法，并不是规范或引擎里的术语。规范里只有 task queue、microtask queue 和 event loop。）

7.3 Event Loop

浏览器的 Event Loop 遵循的是 HTML5 标准，NodeJs 的 Event Loop 遵循的是 libuv

7.3.1 浏览器

1. 取一个宏任务来执行。执行完毕后，下一步
2. 取一个微任务来执行，执行完毕后，再取一个微任务来执行。直到微任务队列为空（执行过程中新产生的微任务也会在这一轮清空），执行下一步
3. 更新 UI 渲染：如果到了渲染时机，依次执行 requestAnimationFrame 回调 → 样式计算 → 布局 → 绘制
4. 如果这一帧还有空闲，执行 requestIdleCallback 回调

Event Loop 会无限循环执行上面几步，这就是 Event Loop 的主要控制逻辑。其中，第 3 步（更新 UI 渲染）会根据浏览器的逻辑，决定要不要马上执行更新。一般跟随屏幕刷新率，60Hz 屏幕下约 16.7ms 一次，页面在后台时还会大幅降频。

从执行步骤来看，我们发现微任务，受到了特殊待遇！我们代码开始执行都是从 script（全局任务）开始，所以，一旦我们的全局任务（属于宏任务）执行完，就马上执行完整个微任务队列。

7.3.1.1 代码举例

Promise.resolve().then(() => {
  console.log(1)
})

// 宏任务
setTimeout(() => {
  console.log(2)
}, 0)

var s = new Date()
while (new Date() - s < 50); // 阻塞50ms

Promise.resolve().then(() => {
  console.log(3)
})

new Promise(function (resolve, reject) {
  console.log(4)
  resolve()
}).then(function () {
  console.log(5)
})

process.nextTick(function () {
  console.log(6)
})

console.log(7)

注意：process.nextTick 是 Node 的 API，这段代码要在 Node 里以 CommonJS 方式运行（比如存成 .cjs），浏览器里会直接报 process is not defined。

7.3.1.2 代码解释

第一轮：主线程开始执行，遇到 Promise.then() 的回调函数丢到微任务队列中，再继续执行，遇到setTimeout ，将 setTimeout 的回调函数丢到宏任务队列中，（加 50ms 的阻塞，是为了确保执行到后面时定时器已经到期，避免有人认为 setTimeout 是因为延迟没到才最后执行的。浏览器里嵌套超过 5 层的定时器最小延迟会被钳制到 4ms，Node 里 setTimeout(fn, 0) 实际是 1ms），再继续执行，遇到 Promise.then() 的回调函数丢到微任务队列中，再继续执行，在往下执行 new Promise 立即执行，输出4，then 的回调函数丢到微任务队列中，再继续执行，遇到process.nextTick，同样将回调函数扔到为任务队列，再继续执行，输出7； 当所有同步任务执行完成后看有没有可以执行的微任务，发现有 then 函数和 nextTick 两个微任务，先执行哪个呢？process.nextTick 指定的异步任务总是发生在所有异步任务之前，因此先执行process.nextTick 输出6然后执行第一个 then 函数输出1，同理输出3和输出5，第一轮执行结束； 第二轮：从宏任务队列开始，发现 setTimeout 回调，输出2执行完毕。

因此结果是: 4 7 6 1 3 5 2

7.3.1.3 面试回答

• 首先 js 是单线程运行的，在代码执行时，通过任务进入执行栈并判断任务类型来保证代码的有序执行。
• 在执行同步代码的时候，如果遇到了异步事件，挂起该任务，继续执行执行栈中的其他任务
• 当同步事件执行完毕后，将异步事件对应的回调加入到与当前执行栈中不同的另一个任务队列中等待执行。
• 任务队列可以分为宏任务队列和微任务队列，如果当前执行栈中的事件执行完毕后，判断微任务队列中是否有任务可以执行，如果有就将微任务队首的事件压入栈中执行。
• 当微任务队列中的任务都执行完成后，浏览器视情况进行渲染，再去判断宏任务队列中的任务。

7.3.2 NodeJs

1. 初始化 Event Loop
2. 执行您的主代码。这里同样，遇到异步处理，就会分配给对应的队列。直到主代码执行完毕。
3. 执行主代码中出现的所有微任务：先执行完所有 nextTick()，然后在执行其它所有微任务。
4. 开始 Event Loop

NodeJs 的 Event Loop 分 6 个阶段执行：

     ┌───────────────────────────┐
  ┌─>│           timers          │
  │  └─────────────┬─────────────┘
  │  ┌─────────────┴─────────────┐
  │  │     pending callbacks     │
  │  └─────────────┬─────────────┘
  │  ┌─────────────┴─────────────┐
  │  │       idle, prepare       │
  │  └─────────────┬─────────────┘      ┌───────────────┐
  │  ┌─────────────┴─────────────┐      │   incoming:   │
  │  │           poll            │<─────┤  connections, │
  │  └─────────────┬─────────────┘      │   data, etc.  │
  │  ┌─────────────┴─────────────┐      └───────────────┘
  │  │           check           │
  │  └─────────────┬─────────────┘
  │  ┌─────────────┴─────────────┐
  └──┤      close callbacks      │
     └───────────────────────────┘

以上的 6 个阶段，具体处理的任务如下：

• timers: 这个阶段执行 setTimeout() 和 setInterval() 设定的回调
• pending callbacks(I/O callbacks)：会执行除了timer,close,setImmediate之外的事件回调
• idle, prepare: 仅系统内部使用
• poll: 轮询，不断检查有没有新的 I/O callback 事件，在适当的条件下会阻塞在这个阶段，主要分为如下两个步骤：
  • 先查看 poll queue 中是否有事件，有任务就按先进先出的顺序依次执行回调
  • 当 queue 为空时，会检查是否有 setImmediate() 的 callback，如果有就进入 check 阶段执行这些 callback。但同时也会检查是否有到期的 timer，如果有，就把这些到期的 timer 的 callback按照调用顺序放到 timer queue 中，之后循环会进入 timer 阶段执行 queue 中的 callback。
• check: 执行 setImmediate() 设定的回调
• close callbacks: 执行比如 socket.on('close', ...) 的回调

Node 11 之前，是每个阶段执行完毕后，才执行所有微任务（先 nextTick，后其它），然后再进入下一个阶段。Node 11 起改成了和浏览器一致：每执行完一个 setTimeout / setImmediate 回调，就立即清空微任务队列。

setTimeout(() => {
  console.log('t1')
  Promise.resolve().then(() => console.log('p1'))
})
setTimeout(() => {
  console.log('t2')
  Promise.resolve().then(() => console.log('p2'))
})
// Node 11+ / 浏览器：t1 p1 t2 p2
// Node 10 及以前：t1 t2 p1 p2

理解 process.nextTick() 您可能已经注意到 process.nextTick() 在关系图中没有显示，即使它是异步 API 的一部分。这是因为 process.nextTick() 在技术上不是事件循环的一部分。相反，无论事件循环的当前阶段如何，都将在当前操作完成后处理 nextTickQueue。这里的一个操作被视作为一个从 C++ 底层处理开始过渡，并且处理需要执行的 JavaScript 代码。

回顾上面关系图，任何时候在给定的阶段中调用 process.nextTick()，所有传递到 process.nextTick() 的回调将在事件循环继续之前得到解决。这可能会造成一些糟糕的情况, 因为它允许您通过进行递归 process.nextTick() 来“饿死”您的 I/O 调用，阻止事件循环到达 轮询 阶段。

7.3.2.1 和浏览器事件循环的区别

• 浏览器遵循 HTML 规范，一个宏任务 → 清空微任务 → 视情况渲染；Node 基于 libuv，分 timers、poll、check 等 6 个阶段
• Node 多了 process.nextTick（优先级高于 Promise 微任务）和 setImmediate（check 阶段执行）
• Node 11 之前微任务在阶段之间才清空，11 起和浏览器一致，每个回调之后就清空
• 主模块里 setTimeout(fn, 0) 和 setImmediate 谁先执行不确定（取决于进入事件循环时 1ms 是否已到）；但在 I/O 回调里一定是 setImmediate 先执行

7.3.2.2 check 阶段做了什么

check 阶段专门执行 setImmediate() 注册的回调。poll 阶段处理完 I/O 后，如果有 setImmediate 回调在排队，事件循环就不会在 poll 阶段阻塞等待，而是直接进入 check 阶段执行它们；每个回调执行完都会清空 nextTick 和微任务队列。check 之后是 close callbacks 阶段（socket.on('close') 等）。

7.4 Links

• JavaScript 异步、栈、事件循环、任务队列
• JavaScript：彻底理解同步、异步和事件循环(Event Loop)
• Event loops
• NodeJs 的 Event Loop 官方文档
• In The Loop - Jake Archibald（JSConf 演讲，讲浏览器事件循环和渲染时机）

八、原型链

• 创建对象的几种方法
• 原型、构造函数、实例、原型链
• instanceof 的原理
• new 运算符

8.1 创建对象的几种方法

// 第一种方式：字面量
var o1 = { name: 'o1' }
var o2 = new Object({ name: 'o2' })

// 第二种方式：构造函数
var M = function (name) {
  this.name = name
}
var o3 = new M('o3')

// 第三种方式：Object.create
var p = { name: 'p' }
var o4 = Object.create(p)

console.log(o1) // { name: 'o1' }
console.log(o2) // { name: 'o2' }
console.log(o3) // M { name: 'o3' }
console.log(o4) // {}

8.2 原型、构造函数、实例、原型链

flowchart LR
  C[构造函数] -->|prototype| P[原型对象]
  P -->|constructor| C
  C -->|new| I[实例]
  I -->|"__proto__"| P
  P -->|"__proto__"| P2[原型对象的原型，一直到 Object.prototype]

对象是函数创建的，而函数却又是一种对象。也是属性的集合，可以对函数进行自定义属性。 每个函数都有一个属性叫做 prototype。 这个 prototype 的属性值是一个对象，默认的只有一个叫做 constructor 的属性，指向这个函数本身。

var Fn = function () {
  this.name = 'WuChenDi'
  this.old = 23
}
var f1 = new Fn()
console.log(f1) // Fn { name: 'WuChenDi', old: 23 }
console.log(Fn)
console.log(Fn.prototype)
console.log(f1.__proto__ === Fn.prototype) // true
console.log(Fn.prototype.constructor === Fn) // true

从上面的代码可以看到，实例的原型指向构造函数的 prototype 属性。 f1.__proto__ 指向构造函数的 prototype 属性，就是对象的原型。所以 f1.__proto__ === Fn.prototype 为 true prototype 的属性值是一个对象，默认的只有一个叫做 constructor 的属性，指向这个函数本身。 __proto__ 就是指向构造函数的 prototype 属性，Fn.prototype 就是对象的原型 即，每个由构造函数创建的对象都有一个 __proto__ 属性，指向创建该对象的函数的 prototype。

var 对象名 = new 函数名()
对象名.__proto__ === 函数名.prototype

原型链的终点是 Object.prototype.__proto__ === null。另外 Function.__proto__ === Function.prototype、Object.__proto__ === Function.prototype，这两个是画原型链图时最容易绕晕的地方。

__proto__ 是历史遗留的访问器，规范只是为了兼容才保留在附录里。代码里读写原型用 Object.getPrototypeOf(obj) / Object.setPrototypeOf(obj, proto)，创建时指定原型用 Object.create(proto)；Object.create(null) 可以得到一个没有原型的纯字典对象。

8.3 instanceof

instanceof 运算符用于检测构造函数的 prototype 属性是否出现在某个实例对象的原型链上。

flowchart LR
  I[实例对象] -->|"__proto__"| P[原型]
  C[构造函数] -->|prototype| P
  P -->|constructor| C

instanceof 判断的就是：沿着实例的 __proto__ 往上找，能不能找到构造函数的 prototype。

// 第一种方式：字面量
var o1 = { name: 'o1' }
var o2 = new Object({ name: 'o2' })

// 第二种方式：构造函数
var M = function (name) {
  this.name = name
}
var o3 = new M('o3')

// 第三种方式：Object.create
var p = { name: 'p' }
var o4 = Object.create(p)

console.log(o3 instanceof M) // true
console.log(o3 instanceof Object) // true
console.log(o3.__proto__ === M.prototype) // true
console.log(M.prototype.__proto__ === Object.prototype) // true
console.log(o3.__proto__.constructor === M) // true

手写实现：沿着左边对象的原型链往上找，直到找到右边构造函数的 prototype，或者走到链的尽头 null。

{
  // instanceof 主要的实现原理就是只要右边变量的 prototype 在左边变量的原型链上即可。因此，instanceof 在查找的过程中会遍历左边变量的原型链，直到找到右边变量的 prototype，如果查找失败，则会返回 false，告诉我们左边变量并非是右边变量的实例。
  {
    function new_instance_of(leftVaule, rightVaule) {
      let rightProto = rightVaule.prototype
      leftVaule = leftVaule.__proto__
      while (true) {
        if (leftVaule === null) return false
        if (leftVaule === rightProto) return true
        leftVaule = leftVaule.__proto__
      }
    }
  }
  {
    const new_instance_of = function (leftVaule, rightVaule) {
      // 原生 instanceof 对原始值直接返回 false（1 instanceof Number === false）
      if (leftVaule === null || (typeof leftVaule !== 'object' && typeof leftVaule !== 'function')) {
        return false
      }
      let proto = Object.getPrototypeOf(leftVaule)
      while (true) {
        if (proto == null) return false
        if (proto === rightVaule.prototype) return true
        proto = Object.getPrototypeOf(proto)
      }
    }
  }
  // 总结：使用 typeof 来判断基本数据类型是 ok 的，不过需要注意当用 typeof 来判断 null 类型时的问题，如果想要判断一个对象的具体类型可以考虑用 instanceof，但是 instanceof 也可能判断不准确，比如一个数组，他可以被 instanceof 判断为 Object。所以我们要想比较准确的判断对象实例的类型时，可以采取 Object.prototype.toString.call() 方法
  // 补充：instanceof 在跨 iframe 时会失效（每个 iframe 有自己的 Array 构造函数），判断数组用 Array.isArray；
  // 类还可以通过 static [Symbol.hasInstance]() 自定义 instanceof 的行为
}

8.4 new 运算符

• 一个新对象被创建。他继承自foo.prototype
• 构造函数 foo 被执行。执行的时候，相应的传参会被传入，同时上下文 (this) 会被指定为这个新实例。 new foo 等同于 new foo()， 只能用在不传递任何参数的情况
• 如果构造函数返回一个 "对象" ，那么这个对象会取代整个 new 出来的结果。如果构造函数没有返回对象，那么 new 出来的结果为步骤1创建的对象

// 第一种方式：字面量
var o1 = { name: 'o1' }
var o2 = new Object({ name: 'o2' })

// 第二种方式：构造函数
var M = function (name) {
  this.name = name
}
var o3 = new M('o3')

// 第三种方式：Object.create
var p = { name: 'p' }
var o4 = Object.create(p)

M.prototype.say = function () {
  console.log('say hi')
}

var o5 = new M('o5')

var new2 = function (func, ...args) {
  var o = Object.create(func.prototype)
  var k = func.apply(o, args)
  // 构造函数返回对象或函数时才替换结果；注意 typeof null 也是 'object'，要排除
  if ((typeof k === 'object' && k !== null) || typeof k === 'function') {
    return k
  } else {
    return o
  }
}

var o6 = new2(M)
console.log(o6) // M { name: undefined }
console.log(new2(M, 'o7')) // M { name: 'o7' }
console.log(o6 instanceof M) // true
console.log(o6 instanceof Object) // true
console.log(o6.__proto__.constructor === M) // true

M.prototype.walk = function () {
  console.log('walk')
}

o6.walk() // walk
o3.walk() // walk

8.5 常问

8.5.1 JS 的 new 操作符做了哪些事情？

new 操作符新建了一个空对象，这个对象原型指向构造函数的 prototype，以这个对象为 this 执行构造函数；如果构造函数返回了一个对象（或函数）就用它作为结果，否则返回新建的对象。箭头函数和 class 的方法没有 [[Construct]]，不能被 new。

九、面向对象

9.1 类与实例

9.1.1 类的声明

// 类的声明（es5）
var Animal = function () {
  this.name = 'Animal'
}

// 类的声明（es6）
class Animal2 {
  constructor() {
    this.name = 'Animal2'
  }
}

9.1.2 生成实例

// 类的声明（es5）
var Animal = function () {
  this.name = 'Animal'
}

// 类的声明（es6）
class Animal2 {
  constructor() {
    this.name = 'Animal2'
  }
}

// 实例化
console.log(new Animal()) // Animal { name: 'Animal' }
console.log(new Animal2()) // Animal2 { name: 'Animal2' }

9.2 继承实现

本质就是原型链

9.2.1 概念

说到继承的概念，首先要说一个经典的例子。 先定义一个类（Class）叫汽车，汽车的属性包括颜色、轮胎、品牌、速度、排气量等，由汽车这个类可以派生出“轿车”和“货车”两个类，那么可以在汽车的基础属性上，为轿车添加一个后备厢、给货车添加一个大货箱。这样轿车和货车就是不一样的，但是二者都属于汽车这个类，这样从这个例子中就能详细说明汽车、轿车以及卡车之间的继承关系。 继承可以使得子类别具有父类的各种方法和属性，比如上面的例子中“轿车” 和 “货车” 分别继承了汽车的属性，而不需要再次在“轿车”中定义汽车已经有的属性。在“轿车”继承“汽车”的同时，也可以重新定义汽车的某些属性，并重写或覆盖某些属性和方法，使其获得与“汽车”这个父类不同的属性和方法。 继承的基本概念就初步介绍这些，下面我们就来看看 JavaScript 中都有哪些实现继承的方法。

9.2.2 继承的实现方式

9.2.2.1 构造函数继承

特点： 解决了子类实例共享父类引用属性的问题 创建子类实例时，可以向父类传递参数 可以实现多继承（call多个父类对象）

缺点： 实例并不是父类的实例，只是子类的实例 只能继承父类的实例属性和方法，不能继承原型属性/方法 无法实现函数复用，每个子类都有父类实例函数的副本，影响性能

function Parent1() {
  this.name = 'parent1'
}
Parent1.prototype.say = function () {}

function Child1() {
  Parent1.call(this)
  this.type = 'child1'
}
console.log(new Child1()) // Child1 { name: 'parent1', type: 'child1' }
new Child1().say() // TypeError: ...say is not a function，拿不到原型上的方法

9.2.2.2 原型链继承

特点： 子类实例既是子类的实例，也是父类的实例 父类原型上的属性/方法，子类都能访问到

缺点： 父类实例上的引用属性被所有子类实例共享（见下面的 play 数组） 创建子类实例时，无法向父类构造函数传参 无法实现多继承

function Parent2() {
  this.name = 'parent2'
  this.play = [1, 2, 3]
}

function Child2() {
  this.type = 'child2'
}
Child2.prototype = new Parent2()

var s1 = new Child2()
var s2 = new Child2()
console.log(s1.play, s2.play) // [ 1, 2, 3 ] [ 1, 2, 3 ]
s1.play.push(4)
// TODO: 原型链中的原型对象共用
console.log(s1.play, s2.play) // [ 1, 2, 3, 4 ] [ 1, 2, 3, 4 ]
console.log(s1.__proto__ === s2.__proto__) // true

9.2.2.3 组合方式继承

特点： 解决原型链实现继承的缺点

缺点： 父级构造函数执行了两次，影响性能

function Parent3() {
  this.name = 'parent3'
  this.play = [1, 2, 3]
}

function Child3() {
  Parent3.call(this)
  this.type = 'child3'
}
Child3.prototype = new Parent3()
var s3 = new Child3()
var s4 = new Child3()
s3.play.push(4)
console.log(s3.play, s4.play) // [ 1, 2, 3, 4 ] [ 1, 2, 3 ]

9.2.2.4 组合继承 - 优化1

特点： 父类执行一次(子类实例化执行)，Child4.prototype = Parent4.prototype解释（因为都是对象，都是引用类型，不会执行父级构造函数）

缺点： 如何区分一个对象是由它的子类实例化的，还是父类实例化的（s5是Child4还是Parent4直接实例化的）

function Parent4() {
  this.name = 'parent4'
  this.play = [1, 2, 3]
}

function Child4() {
  Parent4.call(this)
  this.type = 'child4'
}
Child4.prototype = Parent4.prototype
var s5 = new Child4()
var s6 = new Child4()
console.log(s5, s6) // Parent4 { name: 'parent4', play: [ 1, 2, 3 ], type: 'child4' } Parent4 { name: 'parent4', play: [ 1, 2, 3 ], type: 'child4' }

console.log(s5 instanceof Child4, s5 instanceof Parent4) // true true
console.log(s5.constructor) // [λ: Parent4]

9.2.2.5 组合继承 - 优化2

Child5.prototype = Object.create(Parent5.prototype)解释：Object.create来创建一个中间对象，把两个原型对象区分开，这个中间对象还具备一个特性，它的原型对象是父类的原型对象，这样就可以连起来，通过给Child5的原型对象的constructor做修改，就可以正常区分开父类和子类的构造函数

function Parent5() {
  this.name = 'parent5'
  this.play = [1, 2, 3]
}

function Child5() {
  Parent5.call(this)
  this.type = 'child5'
}
Child5.prototype = Object.create(Parent5.prototype)
Child5.prototype.constructor = Child5

var s7 = new Child5()
console.log(s7 instanceof Child5, s7 instanceof Parent5) // true true
console.log(s7.constructor) // [λ: Child5]

这就是常说的寄生组合继承，是 ES5 下最完善的方案。

ES6 的 class Child extends Parent 在语义上就是寄生组合继承（Babel 把 class 降级出来的代码几乎和上面一样），另外还多做了两件事：Object.setPrototypeOf(Child, Parent) 让静态方法也能继承；子类必须先调 super() 才能用 this。现在写业务代码直接用 class 即可，私有字段用 #name（ES2022），静态初始化用 static {} 块。面试问「手写继承」时，答出寄生组合继承并说明它和 class 的对应关系就够了。

十、数据结构与 GC

10.1 数据类型

10.1.1 原始值类型（值类型/基本数据类型）

• Number
• String
• Boolean
• Null
• Undefined
• Symbol（ES2015）
• BigInt（ES2020）

（一共 7 种，Object 属于下面的引用类型。typeof null === 'object' 是历史 bug，判断 null 要用 === null。）

10.1.2 对象类型（引用数据类型）

• 标准普通对象：object
• 标准特殊对象：Array、RegExp、Date、Math、Error……
• 非标准特殊对象（原始值的包装对象）：new Number()、new String()、new Boolean()……
• 可调用/执行对象"函数"：function

10.1.3 类型转化

显式类型强制转换是指当开发人员通过编写适当的代码用于在类型之间进行转换

Number(value)

隐式类型转换是指在对不同类型的值使用运算符时，值可以在类型之间自动的转换

1 == null

在 JS 中只有 3 种类型的转换

• 转化为 Number 类型：Number() / parseFloat() / parseInt()
• 转化为 String 类型：String() / toString()
• 转化为 Boolean 类型: Boolean()

10.1.4 堆/栈

• JS 就是动态语言，因为在声明变量之前并不需要确认其数据类型，所以 JS 的变量是没有数据类型的，值才有数据类型，变量可以随时持有任何类型的数据。
• JS 数据类型可分为两大类——基本类型和引用类型。
  • 基本类型的数据是存放在栈中，引用类型的数据是存放在堆中的。
  • 堆中的数据是通过引用和变量关联起来的。
  • 闭包除外，JS 闭包中的变量值并不保存在栈内存中，而是保存在堆内存中。

「基本类型在栈、引用类型在堆」是便于理解的简化模型。实际 V8 里只有小整数（Smi）会直接存在栈/寄存器里，字符串、浮点数、BigInt 等也都是堆上对象。面试按简化模型回答即可，被追问时能说出这一点更好。

10.2 垃圾回收

10.2.1 什么是垃圾回收？

10.2.1.1 手动回收和自动回收

通常情况下，垃圾数据回收分为手动回收和自动回收两种策略。

手动回收

例如以前学 C 的时候，何时分配内存、何时销毁内存都是由代码控制的，如下：

#include <stdlib.h>

int main() {
  // 手动申请一块能放 10 个 int 的内存
  int *arr = (int *)malloc(sizeof(int) * 10);
  arr[0] = 1;
  // 用完必须手动释放，忘了就是内存泄漏，释放后再访问就是野指针
  free(arr);
  return 0;
}

自动回收

自动垃圾回收的策略，如 JavaScript，产生的垃圾数据是由垃圾回收器来释放的，并不需要手动通过代码来释放。下面记录几个小疑惑。

• **对于栈中的垃圾回收，**JS 引擎通过向下移动 ESP（extended stack pointer当前执行状态针）指针（记录调用栈当前执行状态的指针），来销毁该函数保存在栈中的执行上下文（变量环境、词法环境、this、outer），这里是不需要通过 V8 的垃圾回收机制的，效率非常高。
• **对于堆中的垃圾回收，**主要通过副垃圾回收器（新生代）和主垃圾回收器（老生代）负责的，副垃圾回收器采用 scavenge 算法将区域分为对象区域和空闲区域，通过两个区域的反转让新生代区域无限使用下去。主垃圾回收器采用Mark-Sweep（Mark-Compact Incremental Marking 解决不同场景下问题的算法改进）算法进行空间回收的。无论是主副垃圾回收器的策略都是标记-清除-整理三个大的步骤。另外还有新生代的晋升策略（两次未清除的），大对象直接分配在老生代。

10.2.1.2 新生代和老生代

新生代

算法：Scavenge 算法

老生代

算法：标记 - 清除（Mark-Sweep）算法

算法：标记 - 整理（Mark-Compact）算法

优化算法：增量标记（Incremental Marking）算法

V8 现在的垃圾回收器叫 Orinoco，在上面三种算法基础上大量使用多线程：新生代用并行 Scavenge（多个辅助线程同时复制存活对象）；老生代用并发标记（标记工作主要在后台线程完成，主线程几乎不停顿）、并发 / 惰性清除，只有整理阶段需要短暂暂停主线程。另外还有空闲时 GC（利用帧间空闲时间回收）。面试时能说出「分代 + 增量 + 并行 + 并发」这几个关键词就够了。

10.2.2 判断内存泄漏

• 可能长时间运行页面卡顿，感官上猜测可能会有内存泄漏，通过 Chrome DevTools 的 Performance、Memory 面板收集数据。
• 在页面进行各种交互，在一定的时间内（越长越好），生成统计数据，观察内存变化（timeline），如变化规律为周期且平稳的，则不存在泄漏可能。但是变化趋势是向上，就存在内部泄漏的可能！
• 统计图表里的 JS heap、Documents、Nodes、Listeners 分别对应 JS 堆内存、文档数、DOM 节点数、事件监听器数。哪条曲线只涨不降，就往对应方向排查。
• 确认有泄漏后，用 Memory 面板在操作前后各拍一次堆快照（Heap Snapshot），选 Comparison 视图看新增了哪些对象，再通过 Retainers 找到是谁引用着它。

10.2.3 工作中避免内存泄漏

常见的泄漏来源：

• 意外的全局变量（非严格模式下给未声明变量赋值）
• 忘记清除的 setInterval / setTimeout
• 组件卸载时没有移除的事件监听、订阅、IntersectionObserver / ResizeObserver
• 已经从 DOM 树上移除、但仍被 JS 变量引用的 DOM 节点（detached DOM）
• 闭包无意间持有了大对象，或者无限增长的缓存 Map

对应的做法：

• 确定不使用的临时变量置为 null
• 在 React useEffect 的清理函数、Vue onUnmounted 里成对释放定时器、监听和订阅，监听可以统一用 AbortController 解绑
• 以对象为 key 的缓存用 WeakMap / WeakSet，key 被回收时条目会自动消失；需要弱引用时用 WeakRef + FinalizationRegistry
• 缓存设上限（LRU）

10.3 闭包

闭包就是能够读取其他函数内部变量的函数，或者子函数在外调用，子函数所在的父函数的作用域不会被释放。 当在一个函数内定义另外一个函数就会产生闭包。

10.3.1 作用

为什么要用： 匿名自执行函数：我们知道所有的变量，如果不加上 var 关键字，则默认的会添加到全局对象的属性上去，这样的临时变量加入全局对象有很多坏处，比如：别的函数可能误用这些变量；造成全局对象过于庞大，影响访问速度(因为变量的取值是需要沿着作用域链逐层查找的，全局变量在链的最末端)。除了每次使用变量都是用 var 关键字外，我们在实际情况下经常遇到这样一种情况，即有的函数只需要执行一次，其内部变量无需维护，可以用闭包。

结果缓存：我们开发中会碰到很多情况，设想我们有一个处理过程很耗时的函数对象，每次调用都会花费很长时间，那么我们就需要将计算出来的值存储起来，当调用这个函数的时候，首先在缓存中查找，如果找不到，则进行计算，然后更新缓存并返回值，如果找到了，直接返回查找到的值即可。闭包正是可以做到这一点，因为它不会释放外部的引用，从而函数内部的值可以得以保留。

function memoize(fn) {
  const cache = new Map()
  return function (arg) {
    if (!cache.has(arg)) cache.set(arg, fn(arg))
    return cache.get(arg)
  }
}

其他常见用途：封装私有状态（模块模式）、柯里化 / 偏函数、防抖节流（见 17.1.15）。React Hooks 的「过期闭包」问题也是常考点：useEffect 或定时器回调捕获的是创建时那一次渲染的 state，依赖数组没写全就会读到旧值。

有了 ES Module 和块级作用域，用 IIFE 隔离变量的需求基本没有了，但闭包本身是 JS 函数的基础机制，谈不上「少用」。要注意的只是别让长生命周期的闭包（比如全局事件回调）引用用完就该释放的大对象。

10.4 Links

浏览器工作原理与实践：https://time.geekbang.org/column/article/131233

V8 博客 - Trash talk: the Orinoco garbage collector：https://v8.dev/blog/trash-talk

十一、TypeScript

TypeScript 在中高级前端面试里已经是默认技能，基础语法很少单独考，区分度在两个方向：类型编程（能不能读懂、写出工具类型）和业务类型设计（能不能用类型把业务约束表达清楚）。

本章的类型示例都用 TypeScript 7 的 tsc --strict 检查通过。为了直接展示类型推导的结果，借用了 type-challenges 里的两个测试工具：Expect<Equal<A, B>> 能编译通过，就说明 A 和 B 完全相同；// @ts-expect-error 标记的那一行本来就应该报错。

type Equal<X, Y> = (<T>() => T extends X ? 1 : 2) extends <T>() => T extends Y ? 1 : 2 ? true : false
type Expect<T extends true> = T

11.1 基础

11.1.1 type 和 interface

• interface 只能描述对象（包括函数和类的形状），支持 extends 继承和声明合并（同名 interface 会自动合并，常用来扩展第三方库的类型，比如给 Window 加属性）。
• type 是类型别名，能表示任何类型：联合、交叉、元组、条件类型、映射类型等。
• 描述对象时两者基本可以互换，团队统一一种即可。常见约定是对外暴露、可能被扩展的对象类型用 interface，其余用 type。

11.1.2 any、unknown、never

void 表示函数没有有意义的返回值；object 表示非原始值；{} 表示除 null 和 undefined 以外的任何值，不要把它当作「空对象」使用。

11.1.3 类型收窄

TypeScript 会根据控制流自动收窄联合类型。收窄的手段有 typeof、instanceof、in、字面量比较、判别字段，以及自定义的类型谓词（is）和断言函数（asserts）：

function format(input: string | number | Date) {
  if (typeof input === 'string') return input.trim()
  if (typeof input === 'number') return input.toFixed(2)
  return input.toISOString() // 这里 input 已被收窄为 Date
}

interface Fish { swim(): void }
interface Bird { fly(): void }
function isFish(pet: Fish | Bird): pet is Fish {
  return 'swim' in pet
}
function move(pet: Fish | Bird) {
  if (isFish(pet)) pet.swim()
  else pet.fly()
}

function assertIsString(value: unknown): asserts value is string {
  if (typeof value !== 'string') throw new TypeError('not a string')
}
function parse(raw: unknown) {
  assertIsString(raw)
  return raw.toUpperCase() // 断言之后 raw 是 string
}

11.2 泛型

泛型就是类型的参数。用 extends 约束泛型的范围，keyof 取对象所有键组成的联合类型，T[K] 取对应属性的类型（索引访问类型）：

function getProp<T, K extends keyof T>(obj: T, key: K): T[K] {
  return obj[key]
}
const user = { name: 'wudi', age: 30 }
const n = getProp(user, 'name') // string
type _g1 = Expect<Equal<typeof n, string>>
// @ts-expect-error 'email' 不在 keyof typeof user 里
getProp(user, 'email')

function longest<T extends { length: number }>(a: T, b: T): T {
  return a.length >= b.length ? a : b
}
longest('abc', 'de')
longest([1, 2], [3])

什么时候需要泛型：返回值类型依赖参数类型的时候。如果泛型参数只出现一次（比如 function f<T>(x: T): void），它就没有意义，直接写成 unknown 即可。

11.3 条件类型与 infer

条件类型 T extends U ? X : Y 是类型层面的三元表达式。两个重点：

• 分发：当 T 是裸类型参数、传入的又是联合类型时，条件类型会对联合的每个成员分别求值再合并。不想分发时，用 [T] 把它包起来。
• infer：在 extends 子句里声明一个待推断的类型变量，用来「提取」类型的一部分。内置的 ReturnType、Parameters、Awaited 都是这样实现的。

type IsString<T> = T extends string ? true : false
type _c1 = Expect<Equal<IsString<'a'>, true>>
type _c2 = Expect<Equal<IsString<string | number>, boolean>> // 分发：true | false

type NoDistribute<T> = [T] extends [string] ? true : false
type _c3 = Expect<Equal<NoDistribute<string | number>, false>>

type MyReturnType<T> = T extends (...args: any[]) => infer R ? R : never
type MyParameters<T> = T extends (...args: infer P) => any ? P : never
type MyAwaited<T> = T extends PromiseLike<infer V> ? MyAwaited<V> : T
type ElementOf<T> = T extends readonly (infer E)[] ? E : never

declare function fetchUser(id: number, withPosts?: boolean): Promise<{ id: number }>
type _c4 = Expect<Equal<MyReturnType<typeof fetchUser>, Promise<{ id: number }>>>
type _c5 = Expect<Equal<MyParameters<typeof fetchUser>, [id: number, withPosts?: boolean]>>
type _c6 = Expect<Equal<MyAwaited<Promise<Promise<string>>>, string>>
type _c7 = Expect<Equal<ElementOf<string[]>, string>>

11.4 映射类型与模板字面量类型

映射类型遍历一个联合类型（通常是 keyof T）生成新的对象类型，as 子句可以重映射或过滤键（映射成 never 的键会被去掉）。模板字面量类型在类型层面拼接字符串，配合 infer 还能解析字符串：

type Getters<T> = {
  [K in keyof T as `get${Capitalize<string & K>}`]: () => T[K]
}
type _m1 = Expect<Equal<Getters<{ name: string; age: number }>, { getName: () => string; getAge: () => number }>>

type OmitByValue<T, V> = { [K in keyof T as T[K] extends V ? never : K]: T[K] }
type _m2 = Expect<Equal<OmitByValue<{ a: string; b: number; c: () => void }, Function>, { a: string; b: number }>>

type EventName<T extends string> = `on${Capitalize<T>}`
type _m3 = Expect<Equal<EventName<'click' | 'focus'>, 'onClick' | 'onFocus'>>

type CssSize = `${number}${'px' | 'rem' | '%'}`
const w: CssSize = '100px'
// @ts-expect-error 单位不合法
const bad: CssSize = '100pt'

// 从路由字符串里提取参数名
type RouteParams<S extends string> = S extends `${string}:${infer P}/${infer Rest}`
  ? P | RouteParams<`/${Rest}`>
  : S extends `${string}:${infer P}`
    ? P
    : never
type _m4 = Expect<Equal<RouteParams<'/users/:id/posts/:postId'>, 'id' | 'postId'>>

11.5 手写工具类型

面试最常让手写的是这几个，核心就是映射类型、修饰符（?、readonly 前面加 - 表示去掉）和条件类型：

type MyPartial<T> = { [K in keyof T]?: T[K] }
type MyRequired<T> = { [K in keyof T]-?: T[K] }
type MyReadonly<T> = { readonly [K in keyof T]: T[K] }
type Mutable<T> = { -readonly [K in keyof T]: T[K] }
type MyPick<T, K extends keyof T> = { [P in K]: T[P] }
type MyRecord<K extends keyof any, V> = { [P in K]: V }
type MyExclude<T, U> = T extends U ? never : T
type MyExtract<T, U> = T extends U ? T : never
type MyOmit<T, K extends keyof any> = MyPick<T, MyExclude<keyof T, K>>
type MyNonNullable<T> = T & {}

type DeepPartial<T> = T extends (...args: any[]) => any
  ? T
  : T extends object
    ? { [K in keyof T]?: DeepPartial<T[K]> }
    : T
type DeepReadonly<T> = T extends (...args: any[]) => any
  ? T
  : T extends object
    ? { readonly [K in keyof T]: DeepReadonly<T[K]> }
    : T

interface Todo { title: string; done: boolean; meta?: { tags: string[] } }
type _u1 = Expect<Equal<MyPartial<Todo>, Partial<Todo>>>
type _u2 = Expect<Equal<MyRequired<Todo>, Required<Todo>>>
type _u3 = Expect<Equal<MyPick<Todo, 'title'>, Pick<Todo, 'title'>>>
type _u4 = Expect<Equal<MyOmit<Todo, 'done'>, Omit<Todo, 'done'>>>
type _u5 = Expect<Equal<MyExclude<'a' | 'b' | 'c', 'a'>, 'b' | 'c'>>
type _u6 = Expect<Equal<MyNonNullable<string | null | undefined>, string>>
type _u7 = Expect<Equal<MyRecord<'x' | 'y', number>, Record<'x' | 'y', number>>>
type _u8 = Expect<Equal<Mutable<Readonly<Todo>>, Todo>>
const patch: DeepPartial<Todo> = { meta: {} } // 嵌套对象也变成可选

Omit 的 K 约束是 keyof any 而不是 keyof T，所以传入不存在的键不会报错，这是内置 Omit 的一个常见坑。需要严格检查时可以自己定义 StrictOmit<T, K extends keyof T>。

11.6 satisfies、as const 与判别联合

type Color = 'red' | 'green'
const palette = {
  red: '#f00',
  green: [0, 255, 0],
} satisfies Record<Color, string | number[]>
palette.red.toUpperCase() // satisfies 保留了推断：red 是 string
palette.green.map((c) => c * 2) // green 是 number[]

const annotated: Record<Color, string | number[]> = { red: '#f00', green: [0, 255, 0] }
// @ts-expect-error 类型注解会丢掉具体信息，这里只知道是 string | number[]
annotated.red.toUpperCase()

const ROLES = ['admin', 'editor', 'viewer'] as const
type Role = (typeof ROLES)[number]
type _s1 = Expect<Equal<Role, 'admin' | 'editor' | 'viewer'>>

type RequestState<T> =
  | { status: 'idle' }
  | { status: 'loading' }
  | { status: 'success'; data: T }
  | { status: 'error'; error: Error }

function render(state: RequestState<string[]>) {
  switch (state.status) {
    case 'idle':
      return '未开始'
    case 'loading':
      return '加载中'
    case 'success':
      return state.data.join(',') // 这里能访问 data
    case 'error':
      return state.error.message
    default: {
      // 新增一种 status 却忘了处理时，这里会编译报错
      const exhaustive: never = state
      return exhaustive
    }
  }
}

• satisfies：检查值是否符合某个类型，但变量的类型仍然是推断出来的具体类型。相比类型注解，它不会把信息「放宽」掉，适合写配置对象。
• as const：把字面量推断为只读的最窄类型，常用来从常量数组派生联合类型，让枚举值只维护一份。
• 判别联合：联合的每个成员都有一个字面量类型的公共字段，switch 这个字段时 TypeScript 能自动收窄到具体成员。在 default 分支把值赋给 never 就是穷尽检查，新增成员却忘了处理时会编译报错。这种写法比一堆可选字段（data?、error?）更能防止出现「既成功又失败」的非法状态。

11.7 业务类型设计

type Brand<T, B extends string> = T & { readonly __brand: B }
type UserId = Brand<string, 'UserId'>
type OrderId = Brand<string, 'OrderId'>
const toUserId = (id: string) => id as UserId
declare function getOrder(id: OrderId): void
// @ts-expect-error UserId 不能传给需要 OrderId 的地方
getOrder(toUserId('u_1'))

interface ApiResponse<T> { code: number; message: string; data: T }
declare function request<T>(url: string): Promise<ApiResponse<T>>
async function loadUsers() {
  const res = await request<{ id: number; name: string }[]>('/api/users')
  return res.data.map((u) => u.name)
}

// 函数重载：返回类型依赖参数时比联合类型更精确
function createElement(tag: 'a'): HTMLAnchorElement
function createElement(tag: 'img'): HTMLImageElement
function createElement(tag: string): HTMLElement
function createElement(tag: string) {
  return document.createElement(tag)
}
const a = createElement('a') // HTMLAnchorElement
type _b1 = Expect<Equal<typeof a, HTMLAnchorElement>>

几个实用原则：

• 让非法状态无法表示：用判别联合代替多个可选字段和布尔标记。
• 品牌类型（branded type）：结构相同但语义不同的值（用户 ID 和订单 ID 都是字符串），加一个只存在于类型层面的标记，防止传错。
• 从单一来源推导：类型从常量（as const）、schema 或接口定义推导出来，不要手写两份再靠人工同步。
• 类型只在编译期存在：接口返回、JSON.parse、表单输入这些外部数据，类型注解只是「假设」。真正的校验要在运行时做，用 zod / valibot 定义 schema，类型从 schema 推导：

import { z } from 'zod'

const UserSchema = z.object({
  id: z.number(),
  name: z.string().min(1),
  role: z.enum(['admin', 'editor', 'viewer']),
})
type User = z.infer<typeof UserSchema> // 类型从 schema 推导，只维护一份

const result = UserSchema.safeParse(await res.json())
if (!result.success) throw new Error(result.error.message)
const user: User = result.data