ESBuild 与 SWC：高性能编译器如何让前端构建快出百倍

CH-29-01-030·约 19 分钟·前端开发与AI交互·更新 2026-08-13

想象你是一家生意火爆的餐厅老板，后厨却只有一位主厨。这位主厨技艺精湛，但只有一双手、一口锅——所有食材必须他亲手洗、亲手切、亲手炒，客人一多就只能干等。前端的传统构建工具（Babel、Webpack）正是这样的“一人后厨”：它们用 JavaScript 编写，天然受限于 JS 引擎的单线程模型，每次构建都要把成千上万个代码文件重新“洗、切、炒”一遍。当项目从几十个文件膨胀到上万模块，编译耗时从几秒涨到几分钟，开发体验变成“改一行代码，喝一杯咖啡才有结果”。为了根治这个痛点，业界掀起了一场“后厨革命”——用 Go 和 Rust 这样的系统级语言重写编译器。ESBuild（Go 出身）和 SWC（Rust 出身）是这场革命的两面旗帜：前者把整条构建流水线改造成多灶台并联的高速厨房，后者用自动化料理机把转译、压缩做到极致。它们让编译时间从分钟级降到秒级，甚至毫秒级。本文就用这个“厨房”比喻，带你拆解这两把“核武器”的原理、性能与落地姿势。

岗位关联

理解 ESBuild/SWC 的工作原理与选型逻辑，能让你在构建优化、工程提速场景中直接产出可量化的收益，这是前端基建与 AI 交互工程师的必备认知。

可视化演示
工具缘起：单主厨后厨的极限
ESBuild 原理：Go 厨房的多灶台并联
SWC 原理：Rust 料理机的精准转译
并行架构：从一锅乱炖到流水线
性能对比：三方主厨同台竞技
工程集成：新设备如何嵌入老后厨
优化与选型：后厨升级路线图
AI 应用场景
Python 演示
常见误区
面试题

可视化演示

对比ESBuild(Go)与SWC(Rust)高性能编译器，展示编译流水线、构建性能基准及Vite/Next.js/Webpack工具链集成，含六边网格背景和发光动画。

本节配有交互动效（进入视口后自动加载，约 3KB）。

工具缘起：单主厨后厨的极限

想象你经营一家爆火的餐厅：开业时一天 10 桌客人，主厨一个人洗菜、切菜、炒菜绰绰有余；三年后一天 100 桌，后厨还是那位主厨、那一口锅。每个客人都在等菜，排队时间从 5 分钟变成 40 分钟。前端项目经历的正是这个过程：十年前一个项目几十个 JS 文件，今天一个中大型项目动辄上万模块、上千个 npm 依赖。每次构建都要把每个文件重新“洗、切、炒”一遍，传统工具 Babel 和 Webpack 因为用 JavaScript 编写，天然受限于 JS 引擎的单线程模型——再贵的 CPU 也只能用上一个核，其余核心都在“围观”。

于是，业界开始思考：能不能换一种方式做菜？答案是“换一种厨房设备”：用 Go 或 Rust 这类系统级语言重写编译器。它们能直接编译成机器码运行，不再受 JS 引擎的约束，还能利用多核 CPU 并行处理文件。ESBuild 就是 Go 语言的产物，SWC 则是 Rust 语言的产物——它们的登场，让同一批代码的构建时间从“以分钟计”降到“以秒计”，数量级的提升正如给后厨一次性装上了十口灶台。

但并行不是免费的。计算机科学家 Amdahl 早就用一条公式指出了并行化的天花板：

ESBuild 和 SWC 之所以敢说“快 10 到 100 倍”，是因为它们用工程手段把 P 压到接近 1：解析、转换、生成、压缩几乎全部并行化。主厨没有变勤快，但后厨从“一个人一口锅”变成了“一队人十口锅”。

S_{\text{max}} = \frac{1}{(1-P)+\frac{P}{n}}

公式说明：P 是可并行的任务比例，n 是处理器核心数。只有当可并行比例无限接近 1 时，速度才能随核心数线性提升；只要有 20% 的任务必须串行，8 核的极限加速也只有 3.33 倍。

可并行的比例 PP 表示整个构建过程中能同时分配给多个核心处理的占比，好比 100 道菜里有 80 道可以交给不同厨师并行烹制。 $P$
必须串行的比例 (1-P)剩下无法拆分的工作，比如最后统一装盘、整体调度，注定只由一个人的双手完成。 $(1-P)$
并行摊薄后的耗时可并行部分被平均分到 n 个核心，这一项从 P 变成 P/n，这正是“多灶台”的价值所在。 $\frac{P}{n}$
理论加速上限用串行总时间 1 除以并行化之后的总时间，得到速度上限；分母越小，加速越明显。 $S_{\text{max}} = \frac{1}{(1-P)+\frac{P}{n}}$

ESBuild 原理：Go 厨房的多灶台并联

如果传统 Babel 是主厨亲自洗切炒，ESBuild 就像 Go 工程师团队安装的“多灶台并联系统”——一次性给后厨送来几十个独立灶位（goroutine，Go 语言里的轻量级工人线程），每口锅都能独立完成一道菜，还有一台“智能备料柜”（缓存）：昨天切好的半成品直接取用，不必重新切。

ESBuild 是 Go 语言编写的 bundler（打包器），核心工作分三步：第一步，并发解析——同时读取所有源文件，每个文件在独立 goroutine 中被解析成 AST（抽象语法树，可以理解为“把代码拆解成一张标准化的食材处理清单”）；第二步，并发转换——在 AST 层面把 TypeScript 类型注解剥掉、把 JSX 编译成标准 JS 调用；第三步，并发生成——输出最终代码，顺带完成 tree shaking（抖落枯叶，把没被引用的代码移除）和 minify（压缩）。文件没变时，则直接命中缓存，跳过全流程。

一次完整的构建，在抽象层面就是三个阶段耗时的累加：

这套“多灶台 + 备料柜”让 ESBuild 在打包领域快出 10 到 100 倍。但它还有一个固有串行环节——依赖关系图的合并，这恰恰是下一节 SWC 与并行架构要补的课。

T_{\text{build}} = T_{\text{parse}} + T_{\text{transform}} + T_{\text{generate}}

公式说明：parse 是解析源码成 AST，transform 是语法转换，generate 是生成输出代码。串行执行时总耗时等于三者之和；ESBuild 让三阶段在不同文件上并行交错，总耗时逼近最慢的那个文件。

解析耗时 T_parse把源码字符串变成 AST 语法树的时间，相当于拆箱、摘菜、把食材按种类分好。 $T_{\text{parse}}$
转换耗时 T_transform把 TS/JSX 等高级语法转换成标准 JS 的时间，相当于按菜谱把食材炒成半成品。 $T_{\text{transform}}$
生成耗时 T_generate把 AST 输出为最终 JS 代码的时间，相当于装盘出餐。 $T_{\text{generate}}$
总耗时公式串行模式下三者相加；并行模式下，不同文件的三个阶段可以重叠，总耗时远小于简单求和。 $T_{\text{build}} = T_{\text{parse}} + T_{\text{transform}} + T_{\text{generate}}$

SWC 原理：Rust 料理机的精准转译

如果说 ESBuild 是“多灶台大厨房”，SWC 就像是 Rust 工程师打造的“自动化料理机”——它的强项不是人多，而是一台机器内部的高效流水：机械臂（Rust 的所有权模型与零成本抽象）动作精准、没有多余能耗（没有垃圾回收暂停），专门负责把“TS/JSX 这类高级食材”快速处理成“标准 JS 半成品”。

SWC 全称 Speedy Web Compiler，核心能力两条：一是转译（transpile），把 TypeScript 的类型信息剥掉、把 JSX 编译成 React 运行时调用，速度比 Babel 快 20 倍以上；二是压缩（minify），提供官方 swc_minify，在保证语义不变的前提下缩短变量名、删除空白。它还支持多线程：每个文件在独立的 CPU 线程中被转译，多核利用率极高，因此被 Next.js 选作默认编译内核。

评价一台“料理机”的关键指标是吞吐量——单位时间内能处理多少源码：

SWC 并不抢打包的活，它把“备菜”这一环做到极致。用它替换 Babel，就像在单主厨后厨里先塞进一台全自动料理机——改动最小，收益却立竿见影。

\text{Throughput} = \frac{S_{\text{code}}}{T_{\text{transform}}}

公式说明：S_code 是源码总字符数，T_transform 是转译总耗时，二者相除得到每秒处理的代码量。吞吐量越大，说明这台“料理机”产能越高。

源码体量 S_code本次需要转换的源码总字符数，相当于今天要处理的总食材重量。 $S_{\text{code}}$
转译耗时 T_transform从开始到全部文件转换完成所花的总秒数，相当于料理机的总加工时间。 $T_{\text{transform}}$
吞吐量公式源码体量除以耗时，得到每秒处理多少字符，数值越高产能越强。 $\text{Throughput} = \frac{S_{\text{code}}}{T_{\text{transform}}}$

并行架构：从一锅乱炖到流水线

有了多灶台还不够，如果所有厨师挤在同一张台面洗菜，还是会乱成一团。真正的现代后厨讲究“流水线”：有人专门洗、有人专门切、有人专门炒，不同菜的工序在时间上交错进行。ESBuild 和 SWC 的内部架构正是如此。

它们的并行设计有四板斧：第一，任务分片——以“一个文件”为最小单位，把成百上千个文件均匀分给多个 worker；第二，流水线处理——文件 A 还在生成阶段时，文件 B 已经进入转换阶段，文件 C 正在解析，三个阶段在不同线程上重叠执行，谁都不闲着；第三，内存高效利用——Go 和 Rust 直接操作原生内存，AST 不需要像 JS 那样经历对象序列化与反序列化，省下大量开销；第四，避免重复解析——watch 模式和增量编译只对变更文件重跑管道，其余文件直接读取“冰箱”（缓存）。

增量构建的平均耗时，可以由命中率加权得出：

真正让“改一行代码，50 毫秒出结果”的，不是单纯速度快，而是流水线加冰箱的组合拳。这也是老工具与新一代工具在架构层面最本质的差距。

T_{\text{incr}} = h \times T_{\text{cache}} + (1-h) \times T_{\text{full}}

公式说明：h 是缓存命中率。命中 h 比例的文件只花读取缓存的少量时间，未命中的 (1-h) 比例文件需要全量编译。缓存命中率越高，整体构建越快。

缓存命中率 h有 h 比例的文件可以直接从磁盘缓存读取上次结果，好比从冰箱里取出半成品，无需重新洗切。 $h$
缓存读取耗时 T_cache远小于全量编译耗时，因为跳过了 parsing 和大部分 transform 阶段。 $T_{\text{cache}}$
未命中部分耗时剩下 (1-h) 的文件必须从原始源码重新走完整流程，这是无法偷懒的成本。 $(1-h) \times T_{\text{full}}$
期望总耗时两部分按比例相加，h 越接近 1，总耗时越接近缓存读取时间，构建自然越快。 $T_{\text{incr}} = h \times T_{\text{cache}} + (1-h) \times T_{\text{full}}$

性能对比：三方主厨同台竞技

为了让你直观感受差距，我们摆一场擂台：同样的 100 道菜（1000 个模块），请 Babel、SWC、ESBuild 三位主厨分头处理，计时开始。结果往往是：Babel 还在洗第一筐菜，SWC 已经端出了全部半成品；Webpack 还在慢吞吞地打包，esbuild 已经完成了全流程。

具体数字上：转译速度，SWC 单线程比 Babel 快约 20 倍，多线程场景差距更大；打包速度，esbuild 官方基准显示比 Webpack、Rollup 快 10 到 100 倍，全量构建场景差距最悬殊；冷热启动，esbuild 的 watch 模式冷启动约 50 毫秒，热更新几毫秒，而老工具动辄几百毫秒起步；压缩效果，SWC minify 比 Terser 快 5 到 10 倍，压缩率只差 1% 到 2%，几乎无损换速。

衡量“快多少”统一用加速比公式：

但要提醒你：速度只是“入场券”，不是“免死金牌”。快，还得兼容生态、易于调试、方便渐进式接入——这正是工程集成要解决的核心问题。

\text{Speedup} = \frac{T_{\text{old}}}{T_{\text{new}}}

公式说明：T_old 是旧工具完成同一任务的耗时，T_new 是新工具耗时，二者相除就是提速倍数。20 倍意味着旧工具要 10 分钟，新工具只需 30 秒。

旧工具耗时 T_old用 Babel、Webpack、Terser 完成同一构建任务的秒数，是擂台赛的基准线。 $T_{\text{old}}$
新工具耗时 T_new用 ESBuild 或 SWC 完成同一任务的秒数，代表改造后的水平。 $T_{\text{new}}$
加速比公式两者相除，结果大于 1 说明变快，越大越快。 $\text{Speedup} = \frac{T_{\text{old}}}{T_{\text{new}}}$

工程集成：新设备如何嵌入老后厨

后厨改革最忌推倒重来——老餐厅还有几百桌客人在等菜，你不可能停业三个月。聪明的做法是“先用新设备替换最慢的工序，再逐步整体升级”。

目前业界最主流的三种集成姿势：其一，Vite 的构建内核——开发模式下用 esbuild 预构建 node_modules 里的上千个依赖（打成浏览器能直接加载的 ESM 格式并缓存），生产构建仍用 Rollup 做精细分包与 tree shaking；其二，Next.js 全面采用 SWC——从 12 版本起，编译和压缩默认走 SWC，替代了 Babel 与 Terser；其三，与 Webpack 共存——老项目不必推倒重来，只需在 webpack.config.js 里引入 esbuild-loader 或 swc-loader，把 babel-loader 这一环替换掉，Webpack 的模块图能力原样保留。插件生态方面，esbuild 提供 plugin API 但目前成熟度不如 Webpack，SWC 有 @swc/cli、@swc/jest 与 wasm 插件机制，但企业级自定义 transform 仍不如 Babel 社区丰富。

要不要迁移？可以用“净收益”公式做决策：

升级路线图常常从“换一个 loader”开始，像给后厨先添一台料理机，再逐步扩建灶台。步子太大容易扯到蛋，渐进才是工程化的精髓。

R = N \times (T_{\text{old}} - T_{\text{new}}) - C_{\text{migrate}}

公式说明：N 是将来要执行的构建次数，每次省下 (T_old - T_new) 的时间，减去一次性迁移成本 C_migrate，就是净收益。只有构建次数足够多，升级才划算。

构建次数 N未来一个月或一个季度内预计执行的构建次数，相当于餐厅未来要接待的客流量。 $N$
单次节省时间新旧工具单次构建耗时之差，数值越大，升级价值越高。 $T_{\text{old}} - T_{\text{new}}$
迁移成本 C_migrate改造配置、测试兼容性所投入的人力时间，相当于新设备的采购与培训费用。 $C_{\text{migrate}}$
净收益公式总节省减去一次性成本，结果为正才值得动手。 $R = N \times (T_{\text{old}} - T_{\text{new}}) - C_{\text{migrate}}$

优化与选型：后厨升级路线图

不同餐厅定位不同：快餐店重速度，私房菜重品质。选择构建工具同样要看项目气质——小项目要“零配置上手快”，老项目要“渐进迁移不出错”，框架项目要“跟着框架默认走”。

几条实战优化策略：缓存策略上，esbuild 可开启持久化缓存（write: true）配合 incremental API，swc-loader 也支持配置持久化缓存目录，CI 中把缓存目录挂载为持久化存储，热构建直接翻倍提速；场景选型上，新项目推荐 Vite 全家桶，老项目用 swc-loader 替换 babel-loader、用 esbuild 做产物压缩，框架项目直接用 Next.js 内置的 SWC，无需额外配置；趋势判断上，Rolldown（Rust 版 Rollup）、Turbopack（Rust 版 Webpack）都在延续“原生语言重写”这条路线，未来构建工具会全面 native 化。最后要有生态权衡意识：工具越新，插件越少、坑越新鲜，建议先在 CI 中灰度一台机器，对比产物差异后再推广到全员。

临界点可以用“回本次数”来算：

后厨革命没有终点。核心不是“哪把刀最快”，而是把工程师从等待编译的无意义消耗中解放出来，去做真正有价值的“菜品研发”。理解了原理与选型逻辑，你就能为自家后厨画出最合适的升级路线图。

N_{\text{min}} = \left\lceil \frac{C_{\text{migrate}}}{T_{\text{old}} - T_{\text{new}}} \right\rceil

公式说明：迁移成本除以单次构建节省的时间，再向上取整，就是“至少构建多少次才能回本”的阈值。客流量（构建频率）达不到这个数字，升级就不划算。

迁移成本 C_migrate一次性投入的改造时间，比如搭配置、改脚本、灰度验证。 $C_{\text{migrate}}$
单次节省时间每次构建能省下的时间，分母越大回本越快。 $T_{\text{old}} - T_{\text{new}}$
回本阈值公式两者相除后向上取整，得到必须构建多少次才不亏。 $\left\lceil \frac{C_{\text{migrate}}}{T_{\text{old}} - T_{\text{new}}} \right\rceil$

AI 应用场景

场景一：开发服务器秒启动与热更新

阶段：前端开发环境搭建（开发期构建）

解决的问题：传统 Webpack dev server 冷启动动辄 30 秒以上，热更新也要数秒，频繁改动时等待时间极长。Vite 用 esbuild 预构建 node_modules 依赖，配合浏览器原生 ESM 按需加载，让“改一行代码，百毫秒内看到结果”成为现实。

具体案例：某中后台项目有 800 多个 npm 依赖，Webpack 冷启动 42 秒，热更新约 3 秒；迁移到 Vite 后启动降至 1.2 秒，热更新降到 50 毫秒以内，后端联调效率显著提升。

场景二：CI 流水线构建提速

阶段：持续集成（CI）构建与发布阶段

解决的问题：CI 中每次代码推送都要全量构建，Babel 转译加 Terser 压缩占了整个流水线 80% 的时间。用 swc-loader 替换 babel-loader、用 SWC minify 替换 Terser 后，转译和压缩两步都能提速数倍到数十倍。

具体案例：某电商前端仓库有 1200 个 TypeScript 文件，CI 构建从 18 分钟降到 2.5 分钟，日发布频率从 2 次提升到 6 次，紧急缺陷修复的响应速度大幅改善。

场景三：Monorepo 增量构建与缓存

阶段：大规模多包仓库的持续构建

解决的问题：Monorepo 中几十个 package 每次全量重编，浪费严重且拖慢开发节奏。ESBuild 的增量构建 API 与磁盘缓存，配合 Git 变更检测，可以实现“只重编受影响的包”，将平均等待降到亚秒级。

具体案例：某技术团队用 esbuild 的 incremental API 自研了轻量构建脚本，结合变更文件列表做定向编译，每个包的构建时间从平均 8 秒降到 0.5 秒，全仓同步构建从 20 分钟降到 3 分钟。

Python 演示

python45 行

import timefrom concurrent.futures import ProcessPoolExecutor # 模拟前端构建：64 个代码文件，单文件处理耗时 0.05 秒FILES = 64WORKERS = 4SINGLE_FILE_TIME = 0.05  def process_file(index):    # 对应编译器三阶段：解析 -> 转换 -> 生成    time.sleep(SINGLE_FILE_TIME)    return index * 2  def serial_build(file_list):    results = []    for f in file_list:        results.append(process_file(f))    return results  def parallel_build(file_list):    with ProcessPoolExecutor(max_workers=WORKERS) as pool:        return list(pool.map(process_file, file_list))  def main():    files = list(range(FILES))     start = time.time()    serial_build(files)    t_serial = time.time() - start     start = time.time()    parallel_build(files)    t_parallel = time.time() - start     print(f"串行耗时: {t_serial:.3f}s")    print(f"并行耗时: {t_parallel:.3f}s")    print(f"加速比: {t_serial / t_parallel:.2f}x")  if __name__ == "__main__":    main()

目的：用 Python 多进程模拟“单线程串行构建”与“四 worker 并行构建”的耗时差异，直观验证 ESBuild/SWC 提速背后“多核并行”这一核心思想。

FILES = 64定义 64 个待构建的源文件，对应现代前端项目里的模块数量。
SINGLE_FILE_TIME = 0.05模拟编译器处理单个文件的耗时，包含解析、转换、生成三个阶段。
def process_file(index):模拟编译器处理一个模块的完整工序，这里用 sleep 代替真实的计算时间。
results.append(process_file(f))串行构建：一个“主厨”依次处理每个文件，任务只能排队。
with ProcessPoolExecutor(max_workers=WORKERS) as pool:创建 4 个 worker 的进程池，相当于给后厨配备 4 个并行灶台。
return list(pool.map(process_file, file_list))将 64 个文件自动分发给 4 个 worker 并行处理，对应 esbuild 的多线程构建调度。
print(f"加速比: {t_serial / t_parallel:.2f}x")用串行耗时除以并行耗时，得到直观的“提速倍数”。

常见误区

误区很多初学者看到两个工具都“快”、都用“原生语言”，就以为它们是同一个东西的两种实现，随便挑一个就能解决所有构建问题。结果配置半天发现该慢还是慢，于是得出“高科技编译器也不过如此”的结论。

正解两者定位互补而非重复。ESBuild 本质是 bundler（打包器），主业是“把几千个模块合成几个文件”，转译只是副业；SWC 本质是 transpiler（转译器），主业是“把 TS/JSX 转成标准 JS”以及压缩。实践中 Vite 用 esbuild 预打包依赖，生产打包却仍用 Rollup；Next.js 用 SWC 做编译。选型要看你的瓶颈在“打包”还是“转译”。

为何常见：两者的官网和宣传语都强调“快”，营销话术高度相似，初学者容易被速度标签吸引，忽略了它们处在构建流水线的不同环节。

误区以为把一个 loader 换上，依赖解析、tree shaking、分包、缓存等所有环节就全都变成 esbuild 在处理，构建时间理应立刻降到 esbuild 的官方基准水平。

正解loader 只替换“源码到 JS”这一道工序。整个打包流程仍由 Webpack 调度，模块图构建、chunk 分割、插件执行仍是 JS 单线程。真正“全量接管”需要把打包器本身换成 esbuild，或直接迁移到 Vite。工程集成的改动范围，决定了你能拿到多少收益。

为何常见：loader 是 Webpack 中最常接触的扩展点，大家容易把“替换了一个环节”误当成“替换了整个系统”，低估了 Webpack 主流程的固定开销。

误区看到并行能大幅提速，就把 worker 数设成 CPU 线程数的几倍，以为线程越多越快。结果构建时间没降反升，还以为是工具不行。

正解并行度超过物理核心数后，线程上下文切换和内存带宽竞争会抵消收益；Amdahl 定律也告诉我们，串行部分才是真正的天花板。工程经验上，worker 数设为物理核心数或核心数减一（留一个给操作系统）通常最优，具体要以本机 benchmark 为准。

为何常见：“多多益善”的直觉在并发领域并不成立，初学者没有把“资源竞争的固定损耗”算进总账里。

误区以为 SWC 速度碾压 Babel，输出结果也一模一样，于是全局替换、删掉 Babel 配置，结果某天线上出现一段语法解析失败的代码，排查半天才发现是装饰器语法差异。

正解SWC 对齐了绝大多数 Babel presets，但个别 Babel 插件生态（如企业自定义 transform、特定 decorator 行为）在 SWC 上没有对应实现，边界语法也可能有细微差异。正确姿势是小范围灰度、对比产物差异、跑完 E2E 测试再逐步放量，而不是一把梭。

为何常见：benchmark 只测速度不测语义等价性，大家容易把“快”等同于“好”，忽略了对兼容性验证的必要投入。

面试题

Q1. esbuild 是用什么语言编写的？

单选题 · easy

A.Rust 系统级语言
B.Go 原生语言编写← 正确答案
C.C++ 高性能语言
D.JavaScript 解释型语言

答案：B。esbuild 是 Go 语言编写的打包器，这正是它能多线程并行、直接编译为机器码的原因。SWC 才是 Rust 编写，C++ 和 JavaScript 都不是这两个工具的实现语言。

Q2. SWC 的功能定位最接近以下哪个传统工具？

单选题 · easy

A.Webpack 打包器
B.Vite 开发服务器
C.Babel 转译器← 正确答案
D.ESLint 代码检查

答案：C。SWC 的定位是“转译器”，把 TS/JSX 转成标准 JS，并提供压缩能力，这正是 Babel 的职责范围。Webpack 负责打包，Vite 是构建框架，ESLint 负责代码规范检查，都不是 SWC 的直接对标物。

Q3. 前端构建中，"tree shaking"在厨房比喻里最接近什么操作？

单选题 · easy

A.把全部食材一次性下锅
B.挑出有用食材丢弃多余← 正确答案
C.把大块食材切成小块
D.将当日剩菜放进冰箱

答案：B。tree shaking 是“抖落枯叶”，把没被引用的代码从最终产物中移除，只保留真正用到的模块。就像厨师从一筐菜里挑出今晚要用的部分，其余放回仓库，而不是全部下锅。

Q4. 关于增量构建，下列说法正确的是？

单选题 · mid

A.每次都重新解析并编译全部源码
B.只处理变化文件并复用缓存结果← 正确答案
C.只对代码做压缩而不做转译
D.需要人工指定本次变更的文件

答案：B。增量构建的精髓是“从冰箱里拿半成品”——借助缓存，只对发生变更的文件重新走解析、转换、生成全流程，其余文件直接复用上次输出。它的命中率越高，构建越快，这正是 esbuild 和 SWC 的优势所在。

Q5. 根据 Amdahl 定律，当可并行比例 P=0.8、核心数 n=8 时，理论最大加速比是多少？

单选题 · mid

A.恰好等于核心数 8.0 倍
B.约 3.33 倍的极限提升← 正确答案
C.约 2.86 倍的极限提升
D.约 6.40 倍的极限提升

答案：B。代入公式 1/[(1-0.8)+0.8/8] = 1/(0.2+0.1) = 3.33 倍。即使有 8 个核心，只要 20% 的任务必须串行，加速上限就被锁死在 3.33 倍，这就是并行化天花板。

Q6. Vite 使用 esbuild 主要完成什么任务？

单选题 · mid

A.生产环境最终打包产物
B.依赖预构建与开发提速← 正确答案
C.代码静态检查与类型校验
D.将产物压缩成单行文件

答案：B。Vite 在开发模式下用 esbuild 对 node_modules 里的依赖做预构建，把它们打成浏览器能高效加载的 ESM 格式并缓存，让冷启动和热更新快到毫秒级。生产打包仍由 Rollup 负责精细分包。

Q7. 某项目用 swc-loader 替换 babel-loader 后 CI 从 10 分钟降到 2 分钟。此时再增加 4 倍并行 worker，下列哪个说法最准确？

单选题 · mid

A.构建时间必定再降 4 倍
B.受 Amdahl 定律限制不能按倍计算← 正确答案
C.一定会导致构建速度变慢
D.提速效果与并行度完全无关

答案：B。增加 worker 只能加速“可并行部分”，loader 之外的 Webpack 主流程（模块图合并、插件、IO）仍是串行或固定开销。Amdahl 定律指出加速上限取决于串行比例，所以实际收益要实测，不能简单按倍数推导，更不保证必降 4 倍。

Q8. 下列哪项是 ESBuild 在“解析”阶段提速的主要原因？

单选题 · hard

A.跳过语法分析直接输出代码
B.用 goroutine 并发解析多个文件← 正确答案
C.依赖正则表达式替换代替 AST
D.只在最终打包时才解析源码

答案：B。ESBuild 用 Go 的 goroutine 对每个文件独立、并发地做词法与语法分析，把 CPU 多核吃满。它并没有跳过 AST，也没有用正则代替解析——正则无法处理嵌套语法，这恰恰是旧工具性能差的原因之一。

Q9. 以下哪些是 SWC 相比 Babel 的显著特点？

多选题 · hard

A.使用 Rust 编写并支持多线程← 正确答案
B.提供官方压缩代码的能力← 正确答案
C.转译速度大幅快于 Babel← 正确答案
D.无法被框架用于生产构建

答案：ABC。SWC 用 Rust 编写，零成本抽象加多线程并行，单线程转译就比 Babel 快约 20 倍；它还内置 minify 能力，可替代 Terser。D 说法错误——Next.js 恰恰在生产构建中默认采用 SWC 做编译。

Q10. 关于“原生语言重写”（native rewrite），下列说法正确的是哪几项？

多选题 · hard

A.指用 Go/Rust 重写构建工具核心← 正确答案
B.指用 TypeScript 重写业务应用代码
C.是前端构建工具的发展趋势← 正确答案
D.必然使最终产物体积变得更小

答案：AC。native rewrite 指用 Go、Rust 等系统级语言重写编译器与打包器，摆脱 JS 引擎单线程限制，这是 esbuild、SWC、Rolldown、Turbopack 共同的趋势。B 是业务代码重构，D 中“必然更小”过于绝对——压缩率未必优于成熟的 JS 压缩器，速度提升才是重点。