如果一个页面有 1 万个列表项，用户在搜索框每敲一个字符，列表就整体重新过滤、重新渲染一次——输入会卡得没法用。useTransition 就是为了解决这类问题：把"不紧急的渲染"和"用户正在操作的渲染"分开，让输入永远先响应，重的活放到后台慢慢干，还可以随时被新输入打断。

本文先讲用法和简单示例（React 19 的写法），再深入 useTransition 的底层机制——lane 优先级模型、startTransition 内部做了什么、渲染为什么能被中断。

1. 一个场景：为什么需要"非紧急"更新​

先看问题。一个受控输入框 + 昂贵过滤：

function SearchList() {
  const [query, setQuery] = useState('');

  const results = useMemo(() => filterProducts(query), [query]); // 1 万条数据的过滤+渲染

  return (
    <div>
      <input value={query} onChange={(e) => setQuery(e.target.value)} />
      <ul>{results.map((p) => <li key={p.id}>{p.name}</li>)}</ul>
    </div>
  );
}

用户每敲一个字符：onChange → setQuery → 整棵列表重渲染。如果这次渲染要花 200ms，输入框就会滞后 200ms 才回显——因为输入框和列表共用同一个 state、同一次渲染，谁都跑不掉。

问题本质："输入框回显"（紧急）和"过滤并渲染列表"（不紧急）被绑死在一次更新里了。

监控前端性能有两条路线：**真实用户监控（RUM）**采集真实用户的实际体验，合成监控（Synthetic）则用脚本/无头浏览器"模拟访问"页面，在受控环境里测性能。RUM 是"事后诸葛"，合成监控是"事前预防"——它能在发布之前、上线之后、甚至上线之前就发现性能退化。

本文调研合成监控的完整玩法：它和 RUM 怎么分工、第三方工具有哪些、怎么接进 CI 当"性能门禁"、大厂自研/开放的产品长什么样、以及如果你想自己搭一套，核心模块和最小实现是什么。

React 的 Scheduler 本质是一个「任务队列 + 时间切片器」：任意时刻都可能有人提交任务，调度器要不断回答同一个问题——下一个执行谁？ 它的答案是按「过期时间」排序，谁先过期谁最紧急，先执行谁。

实现这个队列用的数据结构，不是数组加排序，也不是链表，而是一个几十行的小顶堆（Min-Heap）。这篇文章从队列的需求出发，对比各种方案的时间复杂度，讲清楚为什么堆是最优解。

「网站加载快吗？」这个问题，实验室（Lighthouse、压测）回答不了真实答案——用户可能在弱网、地铁、安卓千元机在后台还挂着几十个 App。性能是分用户、分设备、分网络、分地区的，只有从真实用户浏览器里采集到的数据，才反映真实体验。

这就是 RUM（Real User Monitoring，真实用户监控）——从真实用户的页面里采集性能与错误数据，用「真实发生」代替「假设场景」。

前端面试考算法，问的不是"你数学好不好"，而是两件事：你有没有数据结构意识（看到问题能想到该用栈、哈希表还是树），你有没有复杂度意识（知道这段代码是 O(n) 还是 O(n²)）。因为前端日常处理的 DOM、事件、状态、缓存，底层全是数据结构——只是平时被框架藏起来了。

这篇文章按"数据结构 → 算法 → 手写题"三层把最常考的内容串一遍：每个结构讲清特性、给一两个高频题、再落到前端场景。不贪多，但每一块都能直接拿去应对面试。

"首屏优化"是前端工程化里最常被问、也最难答好的话题——因为它不是一个技巧，而是一整套从指标定义 → 网络传输 → 资源加载 → 构建产物 → 渲染执行全链路的方法论。本文把这条链路完整走一遍：先讲清楚"快"到底指什么、慢在哪，再按层给出可落地的方案，最后用淘宝、美团、字节等大厂的真实实践收尾。

1. 为什么要优化首屏​

首屏慢的代价是实打实的商业数字。美团技术团队在《前端黑科技：美团网页首帧优化实践》里引用过一组业界数据：

• 57% 的用户更在乎网页在 3 秒内完成加载；
• 52% 的在线用户认为网页打开速度影响其对网站的忠诚度；
• 每慢 1 秒，页面 PV 降低 11%、用户满意度下降 16%；
• 近半数移动用户因 10 秒内没打开页面而放弃。

所以"秒开"不是一个技术执念，而是直接关系收入指标（转化率、跳出率、留存）。这也是为什么大厂会把首屏性能做成性能预算（Performance Budget）——把它当"依赖"一样锁进 CI，超了就不让发版。

一万条订单直接 map 渲染，浏览器会创建一万多个 DOM 节点——滚动掉帧、内存暴涨，甚至直接卡死。虚拟列表（Virtual List / Windowed Rendering）就是为了解决这个问题：不管数据有多少，始终只渲染视口附近的那几十个节点。但"上虚拟列表"只是第一步，真正难的是选型——不同场景（表格、feed、聊天、分组）该用哪个方案，不同数据量级该不该用、用什么级别的虚拟化，以及各种边界情况下的 fallback。

本文把主流方案和大厂实践完整调研一遍：原理 → 方案全景 → 场景选型 → 量级判断 → fallback。

相关工具安装​

WABT​

WABT（WebAssembly Binary Toolkit）是一个开源的WebAssembly编译器和工具集，可以将WebAssembly二进制文件转换为文本格式，反汇编，分析，优化，以及生成二进制文件。

• wat2wasm：将WebAssembly文本格式转换为二进制格式
• wasm2wat：将WebAssembly二进制格式转换为文本格式
• wasm-objdump：主要功能包括反汇编、查看文件结构、导入和导出分析等

安装

sudo apt-get install -y cmake make curl git
git clone https://github.com/WebAssembly/wabt
cd wabt
mkdir build
cd build
cmake ..
make
sudo make install

或者ubuntu可以直接使用apt安装

sudo apt-get install -y wabt

面试问 MySQL，十有八九会落到索引上。但很多人对索引的理解是碎片化的：知道"建索引能提速""最左前缀""不要前模糊 LIKE"，却说不清索引为什么快、B+Tree 好在哪里、二级索引为什么要回表、EXPLAIN 里的 Using index / Using index condition 到底差在哪。

这篇文章把 MySQL 索引从头到尾串一遍：从数据结构出发，到物理存储，再到联合索引与优化器行为。看完能自己判断"这个 SQL 该建什么索引、会不会命中"。

1. 索引是什么：从"全表扫描"说起​

在没有索引的 MySQL 表上查一行数据，InnoDB 只能从第一个数据页开始，把整张表的所有页依次读进内存，逐行比对条件。这就是全表扫描（full scan）——复杂度 O(n)，行数一多就慢。

索引做的事情，本质上和书的目录、字典的拼音检字表一样：额外维护一份"有序的、缩小范围的查找路径"，用少量 IO 定位到目标，而不是翻遍全书。

索引能提速的本质是把"线性查找"变成"树形查找"：读多少次磁盘，取决于树的高度，而不是表的行数。所以下文的一切，都围绕"把树做矮、把路径做窄"展开。