Bun 速度下的 Next.js

Lydia介绍了自己在Vercel和BUN的背景，说明Next.js虽然在框架层面进行了大量性能优化（如Webpack/TurboPack、图片字体优化、服务端渲染、ISR和RSC等），但这些优化都受到底层Node.js运行时的限制。她指出Node.js虽然是可靠的默认运行时，但从2009年沿用至今的架构已成为现代应用性能的瓶颈，特别是在无服务器函数和开发服务器这类需要快速启动的短爆发场景中。因此，要实现真正的性能飞跃，必须重新思考运行时本身而不仅仅优化框架。

演讲者详细讲解了Node.js的内部架构，解释了从JavaScript代码到操作系统的执行链路：代码必须经过V8引擎、Node的C++绑定、LibUV库，最后才能进行系统调用。这个多层抽象过程涉及线程工作和事件循环管理，造成了性能开销。她指出Node.js在2009年的单线程、异步I/O模型是基于当时硬件资源有限（四核CPU、内存和存储受限）的设计决策，但在2025年的硬件条件下（数百核CPU、数TB内存、快速存储）已显得过时。这说明了为什么即使框架再优化也很难突破性能天花板。

BUN是从零开始为现代硬件构建的全新运行时，采用Zig语言而非Node.js的C++，并使用苹果的JavaScriptCore引擎替代V8。核心优势在于Zig的低级操作能力允许BUN直接进行系统调用，而无需通过LibUV抽象层，大大减少了中间层。JavaScriptCore引擎启动速度极快，因为它可以延迟某些初始化优化，这对开发服务器和无服务器环境等短生命周期任务特别有利。结果是从启动到文件访问、HTTP服务器等所有操作都显著加速，演讲者强调这不仅是框架层面的优化，而是运行时根本架构的改进。

BUN提供了大量内置API（SQL、S3、Redis、哈希、Shell等），这些功能完全用Zig原生实现而非简单包装NPM依赖，性能相比Node.js替代品提升显著：SQL客户端比MySQL 2快11倍，S3客户端比AWS SDK快6倍。这种设计理念借鉴了Go和Python等语言的内置功能丰富传统，改变了JavaScript开发者长期以来为几乎每个功能安装依赖的习惯。这些API开箱即用，用户可以在服务器函数和React服务器组件中直接使用，无需额外配置，同时支持多个提供商（Amazon S3、Cloudflare R2、Supabase存储等）的兼容性。

BUN附带了高性能工具链：包管理器比YARN、NPM和PNPM分别快17倍、7倍和4倍，用户无需修改项目即可使用BUN install；内置的打包器和转译器支持TypeScript和JSX开箱即用，无需Webpack或ESBuild配置；测试运行器在SSR 1000个React测试时分别比Vitest快14倍、比Jest快23倍。这些工具可以独立使用——例如可以在Node.js项目中单独使用BUN install获得速度提升，或用bun x替代npx获得即时启动改进（BUN create-next-app比npx快5倍）。整个工具链设计强调零配置和即用体验。

在Next.js项目中使用BUN非常简单——只需在dev或start命令中添加--bun标志，例如`bun run --bun next dev`，无需修改任何应用代码或中间件，保持100% Node.js兼容性。--bun标志用于跳过Node.js shebang检测，确保使用BUN运行时而非默认Node.js。在生产部署方面，Vercel已实现本地BUN支持，使开发者能像部署普通Next.js项目一样轻松部署BUN应用，并能实现30%的CPU使用率降低。演讲者展示了实际案例：使用BUN的HONO API在Vercel上的CPU消耗显著下降。对于尚未完全迁移的用户，可以在Render、Railway等平台使用Docker容器化方式部署。

演讲者建议用户采用可逆的分阶段采用策略：第一步使用bun install替代npm/yarn，获得包管理速度提升；第二步在本地用`bun run --bun`测试BUN运行时，验证应用兼容性；第三步逐步采用BUN原生API（如S3、SQL等），而不一定要全部替换NPM依赖。这种方式的优点是每一步都可逆，如果遇到问题可以随时切回Node.js。演讲者强调BUN的工程师团队正在不断推进JavaScript性能极限，最后总结：Next.js改变了网络开发方式，BUN改变了驱动它的运行时，两者结合将为开发者带来显著的开发体验和性能提升。