Rolldown 插件改动回传提速 26 倍是怎么做到的

“26 倍”不能直接等同于整个 Vite 构建都快了 26 倍。按热榜文章的说法，这次优化针对的是 Rolldown 插件改动回传，也就是插件执行结果交回构建核心的环节；它不是所有项目、所有插件或完整生产构建的固定倍率。

要复核“26 倍”究竟测了什么，至少需要同时看到新旧 Rolldown 版本、机器配置、项目与模块规模、插件及钩子类型、冷热缓存、统计指标和重复测试结果。这些条件没有出现在当前可引用的材料中，因此这个数字只能视为来源方在特定测试中的比例，不能直接外推；“回传快了 26 倍”也不等于“完整构建快了 26 倍”。

插件改动回传位于以下链路：插件钩子执行 → 改动回传 → Rolldown 核心消费改动 → 相关模块或产物再处理。Rolldown 的底层插件接口采用 Rust trait，并保留了 Rollup 风格的生命周期和钩子。 但这只能说明架构基础，不能证明收益来自“换成 Rust 就更快”。现有材料能确认的优化位置是第二环；至于新版究竟减少了回传次数、数据复制与序列化、状态更新，还是无效工作的重复执行，必须由相关 diff、PR 或源码证明，不能擅自贴上“并行”“缓存”或“零拷贝”标签。复核时可以重点对照钩子调用次数、跨界数据量、复制与序列化次数、核心状态更新次数，以及最终被重新处理的模块数量。

局部优化能否改善完整开发流程的耗时，取决于其余环节。端到端延迟仍包含钩子自身、跨语言结果传递、核心状态更新和下游重建；如果只压缩回传一段，其他成本不变，总耗时的改善也不会达到同样的倍率。监听模式的增量重建和 HMR 会复用部分增量状态，生产构建通常走另一套冷缓存与产物生成路径，三者应当分别计时。资料中 Rolldown 整体构建快 10–30 倍属于另一项口径。 它与本次插件改动回传的 26 倍不能合并成同一个性能结论。

兼容性方面，理想状态是 Rollup 插件无需修改或只需少量修改即可运行在 Rolldown 上，而 Vite 插件本质上也依赖这类接口。 现有资料列出的重点钩子映射包括 resolveId、transform、renderChunk 和 buildEnd。 但“接口存在”不等于行为完全一致：

只做代码转换的 transform 插件，应同时关注转换结果与回传耗时；会改变依赖解析或 external 属性的插件，要观察后续模块的失效范围；使用 renderChunk 或 buildEnd 的插件，则要核对 chunk 与最终产物是否一致。JavaScript 插件和 Rust 原生插件应分开测试，不能用一类插件的结果代替另一类。升级 Vite 8 时，还要单独核对 Node 版本、CJS 互操作行为、插件兼容性和 monorepo 表现。

在自己的仓库中按以下顺序复测：

1. 固定 Node、Vite、Rolldown、依赖和插件版本，使用同一台机器测试同一个项目。
2. 分别测冷态生产构建、热态监听重建和 HMR，记录回传段耗时与端到端耗时，并重复测试多次，而不是只取单次最快值。
3. 对构建产物做哈希或语义差异比较，确认速度提升没有带来 chunk 内容漂移。
4. 按钩子清单回归返回值、异步行为和执行顺序，尤其检查 resolveId 的 null、external 以及 renderChunk 的 { code }。

这些复测结果比直接引用“26 倍”更适合作为升级依据。