Vue 编译器换掉 Source Map：为何快了三四成

热点文章给出的结论很直接：Vue 编译器替换 Source Map 生成实现后，编译快了三到四成；需要进一步确认的是它究竟少做了哪一步，而不是先把 Source Map 关掉。 这个“三四成”应当理解为特定代码路径和测试环境下的结果，不能直接外推为所有 Vue 项目都能获得同等收益。

这里的“换掉”指的是替换 Vue 编译器内部负责创建映射器、记录位置和编码输出的生成实现，并非取消 Source Map，也不同于调整 Webpack、Vite 的 devtool 配置。编译结果仍然需要提供符合 Source Map v3 格式的映射，只是生成过程换成了开销更低的实现。具体替换了哪个包、哪些函数，应以对应 Vue 提交为准，不能从热榜标题反推。

对开发者而言，需要回答三个问题：收益能否在自己的项目中复现，映射精度是否等价，以及最终产物与错误监控链路是否仍然兼容。

先分清三种性能

Vue 编译器负责解析 SFC、执行模板与脚本转换、生成渲染代码，并按需生成映射；打包器还要承担模块解析、TypeScript 或 Babel 转换、预处理、资源处理、压缩和映射合并；浏览器运行时则关心脚本解析、执行、渲染和更新。Source Map 主要服务于调试和错误定位，本身不是运行时优化手段。

Vue 3 的静态树提升、Patch Flag 等机制优化的是生成代码的执行与更新效率；Vue 2 编译器中的静态节点标记，则用于在后续更新时跳过静态节点。 这些机制与 Source Map 生成开销没有直接关系，不能拿它们解释此次三四成的编译提速。

因此，看到“编译快了三到四成”时，首先要确认分母究竟是 compiler-core 代码生成、compiler-sfc 单文件编译，还是包含所有 loader 和压缩步骤的完整构建。

位置数据构成主要成本

Source Map 建立的是原始代码与编译后代码之间的位置对应关系。编译器在解析阶段将位置信息保存在 AST 节点上，代码生成阶段再把原始位置与生成位置建立映射，最后经过 VLQ 编码写入 mappings。

成本通常来自大量映射对象的创建、原始位置与生成位置的反复记录、源文件列表和 sourcesContent 的维护，以及最终编码和序列化。映射越密集，相关对象分配和字符串处理的开销越明显。

mappings 通常与 version、file、sources、names、sourcesContent 等字段一起组成完整映射。 如果产物内嵌原始源码，映射文件体积也会增加。参考资料中的 Vue CLI 与 Webpack 对比测试说明，不同 devtool 配置确实会显著影响构建时间和产物体积，但该测试使用的是较旧的 Vue CLI、Vue 2 与 Webpack 环境，只能说明 Source Map 是一类值得控制的构建成本，不能证明新版 Vue 编译器的具体提速幅度。

生成链路决定优化上限

一次 Vue SFC 构建中，Source Map 可能经历多个阶段。

模板部分先由 Vue 编译器解析并生成渲染函数映射；<script setup> 和 TypeScript 代码还会经过 Babel、esbuild 或 TypeScript 转换，产生另一层映射；使用 <template src>、Pug 等外部模板或预处理器时，还可能引入 loader 映射。最后，Webpack 或 Vite 再根据 devtool 配置合并、保留或重新生成最终映射。

从 Source Map 的实现方式看，生成器通常有两条路径。低级 API 要求调用方逐项插入原始位置和生成位置，再统一编码；SourceNode 则在生成过程中携带节点位置，最后集中产出映射。 无论采用哪一种，如果旧实现需要为每个映射维护较多临时对象，或在输出阶段重复进行编码与索引处理，替换为开销更低的生成实现就可能获得可观收益。

因此，改动只发生在 Vue 编译器内部时，收益主要集中在模板或 SFC 编译环节。进入完整构建后，loader、模块解析、压缩和最终映射合并仍会占用时间，同一个改动在“仅运行 Vue 编译器”和“运行完整 Webpack/Vite 构建”中的提速比例不能直接等同。

性能结论必须限定环境

目前没有足够信息把报道中的三四成直接复述为普遍结论。要验证它，至少应固定基线提交、优化提交、Node 版本、依赖锁文件、测试机器和输入文件，并分别测试冷缓存与热缓存。

测试矩阵至少要包含四组结果：旧实现且不生成 Source Map、旧实现生成 Source Map、新实现不生成 Source Map、新实现生成 Source Map。其中，前两组用于计算旧实现的 Source Map 净成本，后两组用于计算新实现的 Source Map 净成本，两份净成本的差异用于确认新实现是否真的降低了这份成本。能够控制 sourcesContent 时，还应分别测试包含和不包含原始源码的情况。

每个场景预热后交替运行基线与优化版本至少 20 次，记录中位数、P95、CPU 时间、峰值内存和最终映射文件大小。单组件项目、模板数量多的项目、完整 SFC 项目和 CI 全量构建也应分开统计。

可以先记录测试环境：

node --version
npm --version
git rev-parse HEAD
npm ls vue @vue/compiler-sfc @vue/compiler-core vite webpack

模板编译的微基准可以写成下面的独立脚本。它只统计 compileTemplate，便于与完整构建区分：

// bench-compiler.mjs
import { createHash } from 'node:crypto'
import { readFile } from 'node:fs/promises'
import { performance } from 'node:perf_hooks'

const compilerPackage = process.env.COMPILER_PACKAGE || '@vue/compiler-sfc'
const filename = process.env.FIXTURE || 'fixtures/large.vue'
const sourceMap = process.env.SOURCE_MAP !== 'false'
const { parse, compileTemplate } = await import(compilerPackage)
const source = await readFile(filename, 'utf8')
const { descriptor, errors } = parse(source, { filename })

if (errors.length) throw new Error(errors.map(String).join('\n'))
if (!descriptor.template) throw new Error('Fixture has no template block')

function compile() {
  const result = compileTemplate({
    source: descriptor.template.content,
    filename,
    id: 'benchmark',
    compilerOptions: { sourceMap },
  })

  if (result.errors.length) {
    throw new Error(result.errors.map(String).join('\n'))
  }

  return result
}

for (let i = 0; i < 5; i++) compile()

const samples = []
let lastResult

for (let i = 0; i < 30; i++) {
  const start = performance.now()
  lastResult = compile()
  samples.push(performance.now() - start)
}

samples.sort((a, b) => a - b)

console.log({
  median: samples[Math.floor(samples.length / 2)],
  p95: samples[Math.ceil(samples.length * 0.95) - 1],
  mapBytes: lastResult.map
    ? Buffer.byteLength(JSON.stringify(lastResult.map))
    : 0,
  codeHash: createHash('sha256')
    .update(lastResult.code)
    .digest('hex'),
})

基线版本与候选版本应分别安装在干净工作树中运行，避免解析缓存和依赖差异污染结果：

SOURCE_MAP=true COMPILER_PACKAGE=@vue/compiler-sfc node bench-compiler.mjs
SOURCE_MAP=false COMPILER_PACKAGE=@vue/compiler-sfc node bench-compiler.mjs

完整构建则应增加冷缓存与热缓存两组测试。例如使用 hyperfine 时，可以分别执行：

hyperfine --warmup 0 --runs 20 'rm -rf node_modules/.vite node_modules/.cache && npm run build'
hyperfine --warmup 3 --runs 20 'npm run build'

正式比较时，应让基线与候选版本按 A/B 顺序交替执行，而不是只比较两次构建。Linux 下还可以用 /usr/bin/time -v 补充 CPU 时间和峰值内存，macOS 对应使用 time -l。最终提速比例应使用同口径的中位数计算，不能拿编译器微基准的结果代替完整构建结果。

映射正确比速度更难发现

映射错误通常不会让构建直接失败，只会在排障时暴露出来。因此，验收顺序应当是先确认生成代码，再检查映射。

第一项是生成代码。没有开启 Source Map 时，编译器生成的代码原则上不应因映射实现而变化。可以比较代码哈希，确认模板插值、静态提升、事件处理和指令参数没有变化。

第二项是映射内容。需要比较解码后的 mappings，以及 sources、names、sourcesContent 等字段。不同生成器可能采用不同但等价的分段方式，因此除了比较原始编码字符串，还应比较解码后的映射关系：

// compare-map.mjs
import assert from 'node:assert/strict'
import { readFile } from 'node:fs/promises'
import {
  TraceMap,
  decodedMappings,
  originalPositionFor,
} from '@jridgewell/trace-mapping'

const [beforePath, afterPath] = process.argv.slice(2)
const before = JSON.parse(await readFile(beforePath, 'utf8'))
const after = JSON.parse(await readFile(afterPath, 'utf8'))

assert.equal(after.version, 3)
assert.deepEqual(after.sources, before.sources)
assert.deepEqual(after.names, before.names)
assert.deepEqual(after.sourcesContent, before.sourcesContent)
assert.deepEqual(
  decodedMappings(new TraceMap(after)),
  decodedMappings(new TraceMap(before)),
)

const probes = [
  { line: 12, column: 4 },
  { line: 28, column: 10 },
]

for (const probe of probes) {
  console.log({
    probe,
    before: originalPositionFor(new TraceMap(before), probe),
    after: originalPositionFor(new TraceMap(after), probe),
  })
}

这里的探测坐标应替换为实际生成代码中的关键位置，例如模板插值、表达式、事件处理函数和必然抛错的语句。反查结果应落到预期的 .vue 文件与行列；如果完整映射存在差异，即使多数位置仍然正确，也需要逐段确认是否丢失了映射粒度。

第三项是消费端验证。在 Chrome、Firefox 中触发一个可控错误，检查堆栈能否回到原始组件；将最终产物和最终 Source Map 按 release、artifact 或构建编号上传到 Sentry、Bugsnag，确认平台能展示原始文件上下文。 还要单独运行 Jest、Vitest 的异常堆栈测试，并检查快照测试是否受映射展示或序列化结果影响。

兼容性要检查两端

兼容性不能只看 Vue 编译器自身，还要同时检查生成端和消费端。

生成端需要确认 Source Map v3 格式、sources 路径、sourceRoot、行列精度和 sourcesContent 没有变化，还要确认 TypeScript、Babel、模板预处理器和 loader 产生的旧映射仍能与 Vue 映射正确合并。Webpack 的 devtool 和 Vite 的 Source Map 选项控制的是打包阶段，它们可以叠加在 Vue 编译器的中间映射之上。

消费端则覆盖浏览器、错误监控平台、测试框架和下游构建工具。浏览器读取的是最终产物对应的映射，而不是 Vue 编译器返回的中间对象；Sentry、Bugsnag 上传的也应当是最终产物映射，并绑定正确的发布版本。测试框架如果依赖映射重写堆栈，生成器变化可能影响断言，即使业务代码没有变化。

Node 版本边界也需要记录。Source Map v3 格式本身并不要求某个 Node 版本，但替代生成库、构建工具和 loader 可能有各自的 engines 约束。升级验证应覆盖项目最低支持 Node 版本和 CI 当前版本，而不是只测试最新环境。

Vue 版本差异不能混算

这条热点针对的是 Vue 3 编译器工具链中的生成实现，不能外推到 Vue 2。Vue 2 使用独立的 vue-template-compiler，Vue 3 则由 @vue/compiler-core、@vue/compiler-dom 和 @vue/compiler-sfc 等包组成。只有包含对应提交的 Vue 3 版本才能获得这项收益，Vue 2 项目若要使用这项优化，需要单独获得回移支持。

Vue 2 编译器通过静态节点和静态根标记减少后续更新；Vue 3 的静态树提升、Patch Flag 等机制则优化生成代码的运行方式。 它们与 Source Map 生成器替换属于不同议题。升级说明如果只写“Vue 编译器快了三四成”，而不标明 Vue 版本、包子版本和提交，就会让 Vue 2 用户形成错误预期。

开发和生产不能一刀切

开发环境通常需要尽量完整的映射，以支持断点、原始文件展示和错误堆栈反查。生产环境则更适合把 Source Map 作为受控产物上传到错误监控平台，而不是直接公开部署。这样既能保留线上可观测性，也能减少源码暴露风险。

Webpack 的 devtool 属于另一层选择：

这些模式改变的是打包器如何保存和消费映射，不等同于 Vue 编译器内部生成实现的替换。 旧环境中的 devtool 基准数据，也不能直接证明新版 Vue 编译器获得了相同比例的提速。

升级应按收益和风险推进

优先级最高的通常是模板较多的大型 SFC、TypeScript 模板、包含预处理器链的项目、组件库和重复执行全量构建的 CI，因为这些场景更容易积累映射成本，也更容易从编译器级优化中获得收益。

纯 JavaScript 项目、已经关闭 Source Map 的项目，或者构建时间主要消耗在网络请求、资源处理和压缩上的项目，收益可能有限。组件库则要特别谨慎：它的映射可能被下游 Webpack、Vite、Rollup 或应用构建工具再次合并，错误不能只在本仓库内验证。

上线前至少应完成四项验收：生成代码保持一致、关键位置反查一致、浏览器与监控平台堆栈可解析、CI 基准没有引入明显回退。灰度期间再观察编译 P95、峰值内存、映射文件大小和错误还原失败率。

我的判断是：Source Map 不宜仅因构建开销而直接关闭；应优先减少重复生成和低效映射处理，同时保留线上可观测性。