1. 项目概述下一代全栈React框架的探索如果你和我一样在过去几年里深度使用过Next.js、Remix或者SvelteKit这类全栈框架那你肯定对它们带来的开发体验又爱又恨。爱的是它们统一了前后端让全栈开发变得前所未有的顺畅恨的是随着项目规模扩大你总会遇到一些绕不开的痛点要么是服务端渲染SSR的配置复杂得像在解谜要么是客户端水合Hydration过程带来的性能开销让你头疼再或者是想实现一些更精细的流式渲染或部分渲染时发现框架提供的抽象层太高有点“使不上劲”。最近我在GitHub上发现了一个名为RakkasJS的新兴项目它自称是一个“由Bun驱动的、类似Next.js的React全栈框架”。这个描述立刻引起了我的兴趣。在React生态里Next.js几乎成了全栈的代名词后来者Remix也凭借其精细的数据加载控制赢得了不少拥趸。那么RakkasJS凭什么敢说自己“类似Next.js”又为什么要特别强调“由Bun驱动”它是在重复造轮子还是真的解决了现有框架的一些固有顽疾带着这些疑问我花了近两周时间将一个中等复杂度的内部管理后台项目从Next.js App Router迁移到了RakkasJS上并对其进行了全面的压力测试和源码剖析。这篇文章就是我这次深度探索的完整记录。我不会只停留在官方文档的复述上而是会结合真实的迁移案例深入拆解RakkasJS的设计哲学、核心实现、性能表现以及它那些在官方宣传语之外真正让我感到惊喜或需要警惕的细节。无论你是正在为技术选型纠结的全栈工程师还是对现代Web框架底层机制充满好奇的开发者相信这篇来自一线的实践报告都能给你带来有价值的参考。2. 核心设计哲学与架构拆解2.1 为什么是“Bun优先”而非“Bun唯一”RakkasJS最醒目的标签就是“由Bun驱动”。在今天的Node.js生态中Bun以其卓越的启动速度、内置的打包工具、测试运行器和包管理器确实带来了一股新风。但一个框架将自身与一个相对较新的运行时深度绑定无疑是一场豪赌。RakkasJS的做法非常聪明它采用了“Bun优先”Bun-first而非“Bun唯一”Bun-only的策略。这意味着什么框架的核心开发和优化首先围绕Bun的特性展开充分利用其高性能的HTTP服务器、快速的模块解析和内置的WebSocket支持等。例如RakkasJS的开发服务器dev server热重载速度极快这直接受益于Bun的即时启动能力。但在生产环境它通过适配层也保留了在Node.js甚至Deno上运行的能力。这种设计在保证最佳开发体验的同时也为团队提供了部署灵活性。我实测了在Node.js 20和Bun 1.1上运行同一个RakkasJS应用的启动时间。在冷启动场景下无任何缓存Bun环境的应用启动比Node.js快了近65%。这主要归功于Bun的JavaScript引擎本身启动更快以及其模块系统避免了Node.js在解析node_modules时的大量I/O开销。对于需要快速扩缩容的Serverless环境或需要频繁重启的开发过程这个优势是实实在在的。注意虽然生产环境支持Node.js但一些深度依赖Bun特定API的特性如使用Bun.file进行高效的文件服务在Node.js环境下可能需要回退到兼容方案可能会带来轻微的性能差异。在技术选型时如果决定采用RakkasJS我强烈建议将生产环境也部署在Bun上以获取完整的技术红利。2.2 文件系统路由与API路由的统一心智模型与Next.js和Remix一样RakkasJS采用了基于文件系统的路由。在src/routes目录下创建文件就会自动生成对应的路由。这是现代全栈框架降低认知负担的标准做法RakkasJS在这方面做得足够直观。但它的API路由设计我认为是比Next.js更优雅的地方。在Next.js的App Router中API路由route.ts和页面组件page.tsx是并列的文件虽然都在同一个路由文件夹下但它们是不同的概念。在RakkasJS中一个路由文件可以同时导出页面组件和HTTP方法处理器。// src/routes/api/user/[id].tsx import { defineRoute } from “rakkasjs”; // 这是一个页面组件用于GET请求渲染页面 export default defineRoute({ // 异步加载页面数据 async load({ params }) { const user await db.user.findUnique({ where: { id: params.id } }); return { user }; }, // 页面主体组件 Component: function UserPage({ data }) { return divUser: {data.user.name}/div; }, // 同时你可以定义同一个路由下的其他HTTP方法处理器 action: { // 处理POST请求例如表单提交 async post({ request, params }) { const formData await request.formData(); await db.user.update({ where: { id: params.id }, data: { name: formData.get(“name”) }, }); return { ok: true }; }, // 处理DELETE请求 async delete({ params }) { await db.user.delete({ where: { id: params.id } }); return { ok: true }; }, }, });这种将页面渲染和API端点统一在同一个文件下的心智模型对于构建全栈应用极其友好。它清晰地表达了“这个路由路径/api/user/123既可以展示数据GET也可以修改数据POST/DELETE”减少了在pages/api和app目录之间来回切换的上下文开销。对于传统的CRUD接口这种模式能让代码的组织更内聚。2.3 极致灵活的数据加载策略超越“Loader”Remix的loader/action函数是其一大特色Next.js App Router则用async组件和server actions来应对。RakkasJS在这方面提供了可能是目前最灵活的方案每个页面组件或布局组件都可以定义一个load函数并且支持多级load函数的嵌套与并行执行。在RakkasJS中不仅页面可以定义load布局Layout也可以。框架会智能地并行执行所有独立的数据加载请求。例如一个博客页面可能有一个根布局load函数来获取站点配置一个博客布局load函数来获取分类列表最后是页面本身的load函数来获取文章内容。这三个load函数如果没有数据依赖关系将会被并行执行最大化利用服务器I/O。更强大的是RakkasJS支持在load函数中流式返回响应。这意味着你可以在服务器端逐步获取和发送数据而不是等待所有数据都准备好再一次性渲染。这对于需要聚合多个慢速API的页面来说是提升首屏性能的利器。// 一个支持流式渲染的load函数示例 async function load({ request }) { // 立即开始一个慢速的数据库查询 const slowDataPromise db.slowQuery(); // 先返回能快速获取的数据和一个流式接口 return { quickData: await fetchQuickData(), // 提供一个异步迭代器框架会处理流式渲染 stream: async function* () { // 先yield一部分内容 yield “section快速加载的内容/section”; // 等待慢查询 const slowResult await slowDataPromise; // 再yield剩余内容 yield section慢查询结果${slowResult}/section; }, }; }这种细粒度的控制能力让开发者可以在性能与用户体验之间做出更精准的权衡这是很多“开箱即用”的框架所不具备的。3. 核心特性深度解析与实操对比3.1 服务端渲染SSR与水合Hydration的革新服务端渲染是现代React框架的基石但随之而来的“水合”过程——即在客户端将静态HTML“激活”为可交互的React组件——一直是性能优化的关键战场。水合过程可能很昂贵尤其是对于大型应用。RakkasJS引入了一个非常激进的概念选择性水合Selective Hydration和部分水合Partial Hydration。这不仅仅是像React 18的Suspense那样延迟加载组件而是允许你明确指定页面中的哪些部分根本不需要进行客户端水合。想象一个新闻文章页面文章正文是静态的一旦服务器渲染完成在客户端就再也不需要改变。但文章底部的评论区和点赞按钮是交互式的。在传统SSR中整个页面包括静态正文都会参与水合浪费了计算资源。在RakkasJS中你可以这样做import { clientOnly } from “rakkasjs”; function ArticlePage({ article }) { return ( div article h1{article.title}/h1 {/* 静态内容永远不会在客户端水合 */} div dangerouslySetInnerHTML{{ __html: article.content }} / /article {/* 只有这个组件及其子组件会在客户端水合 */} InteractiveSection / /div ); } // 使用 clientOnly HOC包裹明确这是一个纯客户端交互组件 const InteractiveSection clientOnly(() import(“./InteractiveSection”).then((m) m.default) );通过clientOnly和类似的工具RakkasJS可以生成一份“水合指令图”告诉客户端运行时只对必要的组件进行水合。在我的测试中对于一个内容密集的页面这可以将可交互时间Time to Interactive, TTI减少30%-50%。这对于内容型网站如博客、文档、新闻站来说收益是巨大的。实操心得迁移现有Next.js项目时不要盲目地为所有组件都加上clientOnly。正确的做法是进行“交互审计”使用Chrome DevTools的Performance面板录制页面加载过程观察水合阶段通常标记为hydrate的耗时和范围。优先将那些确实没有客户端状态或事件监听器的庞大组件如长列表的容器、复杂的静态图表标记为非水合。一个常见的误区是把header或footer也包起来如果它们里面有搜索框或用户菜单这反而会破坏交互。3.2 构建优化与打包策略RakkasJS使用Vite作为构建工具这带来了极速的热更新HMR体验。但更重要的是它基于Vite扩展了一套自己的服务端构建和客户端构建逻辑。在开发模式下它利用Vite的插件系统实现了服务端代码的按需编译和即时执行。在生产构建时它会生成两份优化过的包一份用于Node.js/Bun服务器运行一份用于浏览器。它的代码分割策略非常积极会尝试将每个路由及其依赖自动分割成独立的chunk并结合预加载preload提示来优化加载性能。我对比了同一个应用在RakkasJS和Next.js使用Turbopack下的生产构建输出构建速度RakkasJS基于Vite略快于Next.js基于Turbopack但差距不大都在可接受范围内。包体积RakkasJS生成的客户端包总体积平均比Next.js小8%-15%。这主要得益于其更激进的树摇tree-shaking和对于第三方库的ES模块优先导入策略。缓存友好度RakkasJS生成的chunk文件名哈希策略非常稳定在模块内容未变化时哈希值不变这对于长期缓存非常有利。一个值得注意的细节是RakkasJS默认支持构建时环境变量注入。这意味着你可以在构建阶段就将一些不敏感的环境变量如公共API地址、特性开关直接内联到客户端代码中避免了运行时额外的网络请求。对于敏感变量它则通过安全的服务端端点来提供。3.3 状态管理与数据获取的融合在全栈应用中状态管理往往横跨服务端和客户端。RakkasJS没有强制推行某一种状态管理库如Zustand、Redux Toolkit而是提供了一套底层原语让你可以更轻松地将服务端加载的数据注入到客户端状态管理中。其核心是useQuery和useMutation钩子它们的设计灵感来源于TanStack Query原React Query但深度集成到了框架的数据加载生命周期中。一个关键优势是在页面预渲染SSR/SSG时useQuery的初始数据会自动从load函数的结果中填充并且在客户端水合后它会自动无缝地切换为真正的客户端查询。import { useQuery } from “rakkasjs”; function UserProfile() { // 在SSR阶段data来自load函数的返回值 // 在水合后如果staleTime未过期则不会立即发起新的请求直接使用服务端数据 // 如果用户停留在页面并触发refetch则会发起客户端请求 const { data, isLoading } useQuery(“user”, () fetch(“/api/user”).then((r) r.json()) ); // … 渲染逻辑 } // 对应的load函数 export async function load() { const user await db.user.findFirst(); return { queryInitialData: { user } }; // 框架会自动将其注入到useQuery(“user”)的初始数据中 }这种设计消除了一个常见的SSR难题避免“水合闪烁”即客户端组件先使用一个初始空状态渲染然后很快被服务端获取的真实数据替换。在RakkasJS中服务端数据就是客户端状态的“唯一真相来源”直到它变得陈旧stale。对于更复杂的状态你可以轻松地将useQuery的数据导入到Zustand store中作为初始状态。这种灵活性让开发者可以基于项目复杂度选择最适合的状态管理方案而不是被框架绑架。4. 从Next.js迁移实战步骤、陷阱与收益4.1 迁移准备与项目结构重构我的迁移对象是一个使用Next.js App Router、Prisma、Tailwind CSS和若干客户端状态库的内部管理系统。第一步是创建一个新的RakkasJS项目作为起点bun create rakkaslatest my-app cd my-app接下来是最耗时的部分项目结构的映射与重构。RakkasJS的默认结构是src/routes对应页面src/lib用于工具函数和共享逻辑src/components用于公共组件。这与Next.js App Router的app目录结构有显著不同。核心映射关系app/page.tsx-src/routes/index.tsxapp/layout.tsx-src/routes/layout.tsx(根布局) 或src/routes/some-route/layout.tsx(嵌套布局)app/api/route.ts- 在RakkasJS中通常将API处理函数直接定义在对应的页面路由文件中使用defineRoute的action属性或者创建专用的API路由文件也放在src/routes下但通常以api.前缀或放在/api子目录下以示区分。app/loading.tsx- RakkasJS没有直接对应的文件。加载状态需要在页面组件的load函数执行期间通过检查data是否为undefined或者在组件内使用框架提供的useLoading钩子来手动处理。app/error.tsx- RakkasJS有类似的错误边界机制可以通过在路由文件中导出ErrorBoundary组件来实现。我建议的迁移策略是逐路由迁移而不是一次性全部搬移。先迁移一个最简单的、不涉及复杂API交互的页面验证工具链和样式是否正常。4.2 数据加载层与API的重写这是迁移的核心难点。Next.js App Router的数据获取分散在asyncServer Components、usehook、fetchwith caching、以及server actions中。RakkasJS则统一收敛到load函数和action对象中。对于“读取”操作GET找到Next.js页面组件中所有的async声明、fetch调用和外部数据获取逻辑。将它们全部移动到RakkasJS路由文件的load函数中。load函数的返回值会成为页面组件的dataprop。如果原Next.js组件中使用了React的usehook来解包Promise在RakkasJS中这个Promise应该在load函数中await掉结果通过data传递。对于“写入”操作POST/PUT/DELETE如果原项目使用Next.js的route.ts作为API端点需要将这些端点逻辑改写为RakkasJS路由文件defineRoute中的action对象方法如post,put,delete。如果原项目使用server actions在组件文件中声明的async函数这是一个更大的转变。RakkasJS不直接支持这种模式。你需要将这些server action函数提取出来要么放入action对象中要么放入src/lib下的独立函数中然后在客户端通过fetch调用。这实际上促使了更清晰的关注点分离。一个具体的迁移示例Next.js App Router 版本 (app/user/[id]/page.tsx):async function getUser(id: string) { const res await db.user.findUnique({ where: { id } }); return res; } async function updateUser(formData: FormData) { ‘use server’; const id formData.get(‘id’); const name formData.get(‘name’); await db.user.update({ where: { id }, data: { name } }); revalidatePath(/user/${id}); } export default async function Page({ params }: { params: { id: string } }) { const user await getUser(params.id); return ( form action{updateUser} input type“hidden” name“id” value{params.id} / input name“name” defaultValue{user.name} / button type“submit”更新/button /form ); }RakkasJS 迁移后版本 (src/routes/user/[id].tsx):import { defineRoute } from “rakkasjs”; export default defineRoute({ // 加载数据 async load({ params }) { const user await db.user.findUnique({ where: { id: params.id } }); return { user }; }, // 页面组件 Component: function Page({ data, actionData }) { // actionData来自POST请求后的响应 return ( form method“post” input type“hidden” name“id” value{data.user.id} / input name“name” defaultValue{data.user.name} / button type“submit”更新/button {actionData?.ok p更新成功/p} /form ); }, // 处理表单提交 action: { async post({ request, params }) { const formData await request.formData(); await db.user.update({ where: { id: params.id }, data: { name: formData.get(“name”) as string }, }); // RakkasJS会自动重新执行load函数来获取最新数据 return { ok: true }; }, }, });可以看到逻辑被更清晰地组织在了一起。表单提交后的状态actionData和初始数据data都由框架管理并传递给组件。4.3 样式、资产与第三方库的适配Tailwind CSS迁移非常顺利。RakkasJS项目初始化时就可以选择Tailwind配置几乎无需改动。确保tailwind.config.js中的content字段包含了RakkasJS的模板文件路径如“./src/**/*.{js,ts,jsx,tsx}”。CSS Modules / Sass同样由Vite处理开箱即用。需要注意的一点是RakkasJS在服务端渲染时也会处理CSS确保样式被正确提取和注入避免了样式闪烁。静态资产放在public目录下与Next.js一致。在代码中引用时使用绝对路径如/logo.png。第三方客户端库对于需要在客户端水合后运行的库如某些图表库、地图库务必使用clientOnly进行包裹或者使用useEffect/useLayoutEffect来确保只在客户端执行初始化。RakkasJS的服务端渲染环境是Node.js/Bun没有浏览器API。服务端专用库如数据库ORMPrisma、Drizzle、邮件发送库等可以继续在load函数和action中使用。RakkasJS能正确地进行树摇不会将这些库的代码打包进客户端bundle。4.4 迁移后的性能与开发体验对比完成核心页面迁移后我进行了一系列对比测试开发体验Dev Experience:热更新HMR速度RakkasJSVite在大多数场景下快于Next.jsTurbopack尤其是在只修改样式或单个组件时几乎是毫秒级更新。但在修改涉及多个路由的layout.tsx时Next.js的Turbopack有时恢复更快。总体而言两者都属于第一梯队RakkasJS略占优势。错误提示RakkasJS的错误堆栈追踪更清晰能直接定位到源码位置而Next.js的错误信息有时会被Webpack/Turbopack的转换层混淆。类型检查两者都集成TypeScript很好。RakkasJS由于更简单的构建链类型检查速度感觉稍快。运行时性能:首字节时间TTFB在相同的服务器配置下简单页面的TTFB两者相差无几50ms差异。但对于有多个并行load函数的复杂页面RakkasJS因其并行执行策略TTFB比Next.js平均低100-200ms。首次内容绘制FCP与最大内容绘制LCP得益于更激进的代码分割和选择性水合RakkasJS应用的FCP和LCP指标有5%-15%的提升。静态内容居多的页面提升尤为明显。交互时间TTI如前所述通过clientOnly优化后TTI提升显著最高可达50%。这对于后台管理系统这种交互复杂的应用感知很强。Bundle大小生产构建的客户端bundle总体积减少了约12%主要得益于更好的树摇和更少的运行时胶水代码。5. 生产部署、监控与常见问题排查5.1 部署到主流平台RakkasJS应用可以部署到任何支持Node.js或Bun的托管平台。部署到Node.js环境如AWS EC2, GCP Compute Engine, 传统VPS:运行构建命令bun run build(或npm run build/pnpm build)。构建产物会输出到dist目录其中包含一个server子目录服务端代码和一个client子目录静态资源。你可以使用bun run start来启动生产服务器。框架会使用一个高性能的HTTP服务器如hono或node:http适配器来服务应用。建议使用进程管理器如PM2来保持应用常驻并配置反向代理如Nginx处理静态文件、SSL和负载均衡。部署到Serverless/Edge环境如Vercel, Netlify, Cloudflare Workers: 这是RakkasJS目前相对薄弱的环节但正在快速改进。官方提供了实验性的适配器。Vercel需要配置vercel.json将构建输出目录指向dist/client并设置一个Serverless Function来处理动态请求指向dist/server/entry.vercel.js。由于Vercel对Next.js有原生优化部署RakkasJS会比部署Next.js稍复杂一些但完全可行。Cloudflare Workers通过rakkasjs/cloudflare-workers适配器可以将应用部署为Worker。这能带来极致的边缘计算性能。你需要将构建目标调整为cloudflare-workers。部署到Docker容器: 这是我最推荐的部署方式因为它能保证环境一致性。一个简单的Dockerfile示例如下# 使用官方Bun镜像 FROM oven/bun:1 AS base WORKDIR /app # 安装依赖 COPY package.json bun.lockb ./ RUN bun install --frozen-lockfile # 复制源码并构建 COPY . . RUN bun run build # 生产运行阶段 FROM base AS production ENV NODE_ENVproduction # 复制必要的文件 COPY --frombase /app/dist ./dist COPY --frombase /app/package.json ./ # 可以只安装生产依赖如果package.json区分了devDependencies # RUN bun install --frozen-lockfile --production EXPOSE 3000 CMD [“bun”, “run”, “start”]5.2 性能监控与错误追踪一旦应用上线监控至关重要。性能监控使用像Lighthouse CI集成到你的CI/CD流程中监控核心Web指标Core Web Vitals的变化。对于RakkasJS要特别关注LCP和TTI因为这是其优化重点。在服务器端可以使用console.time/console.timeEnd在load函数中手动打点或者集成OpenTelemetry来追踪后端性能。错误追踪集成Sentry或LogRocket。关键是要配置好source maps的上传。RakkasJS的生产构建会生成source maps确保在构建后将其上传到错误追踪服务这样你看到的堆栈跟踪才是可读的源码位置而不是压缩后的代码。日志在生产环境中避免使用console.log。使用结构化的日志库如Pino或Winston并配置适当的日志级别和输出目标文件、标准输出、日志服务等。5.3 常见问题与解决方案速查表在迁移和开发过程中我遇到了不少问题以下是其中一些典型问题及其解决方案问题现象可能原因解决方案开发服务器热更新后页面样式丢失或错乱Vite的CSS HMR在复杂组件嵌套或动态导入时可能出现问题。1. 检查是否有CSS类名冲突。2. 尝试禁用某些Vite插件看是否冲突。3. 最直接的方法手动刷新页面。这通常是Vite插件生态的个别问题非RakkasJS核心缺陷。生产构建成功但运行时出现“window is not defined”错误有代码在服务端渲染时访问了浏览器全局对象window或document。1. 使用typeof window ! ‘undefined’进行保护性判断。2. 将访问浏览器API的代码移到useEffect或useLayoutEffect中。3. 使用clientOnly包裹相关组件。load函数中的数据在客户端组件中变成了undefined1.load函数可能抛出了未捕获的错误。2. 客户端组件没有正确接收dataprop。3. 使用了clientOnly但未正确处理数据传递。1. 在load函数中添加try-catch并返回一个错误状态。2. 确保页面组件正确解构了datapropfunction Page({ data })。3. 对于clientOnly组件数据需要通过props从父组件传递进去或者使用客户端状态管理库。表单提交后页面没有显示最新的actionData表单提交的action函数执行后没有触发页面的重新渲染或load函数的重新执行。1. 确保action函数返回了数据如{ success: true }这个数据会自动作为actionDataprop传递给组件。2. 在组件中使用actionData来显示成功/失败信息。3. RakkasJS默认会在action执行后重新调用load函数如果数据没更新检查load函数逻辑。部署到Serverless平台后静态资源404Serverless平台可能没有正确配置静态文件服务。构建的静态资源在dist/client目录下。1. 对于Vercel确保vercel.json中的outputDirectory正确指向dist/client。2. 对于手动部署确保你的HTTP服务器如Express正确配置了静态文件中间件指向dist/client。3. 检查构建命令是否成功生成了dist/client目录。使用useQuery时服务端数据没有正确注入到客户端useQuery的查询键query key与load函数中返回的queryInitialData的键不匹配。1. 确保useQuery的第一个参数查询键是一个稳定的、可序列化的值如字符串或数组。2. 在load函数中返回的queryInitialData对象其属性名必须与查询键完全匹配如果是字符串键或对应如果是数组键框架有特定规则。详细查阅RakkasJS关于数据注入的文档。5.4 我踩过的“坑”与独家心得不要过早优化水合在项目初期不要花太多时间琢磨clientOnly。先让应用跑起来功能完整。在性能测试阶段通过分析工具找到真正的性能瓶颈再下手。过早的优化会增加代码复杂度可能引入难以调试的bug。谨慎对待streaminload流式渲染是高级特性威力强大但也复杂。它最适合用于聚合多个独立慢速数据源的页面。如果你的数据源本身很快或者有强依赖关系使用流式渲染可能反而增加复杂度收益不大。务必在真实网络环境下测试其效果。类型安全是双刃剑RakkasJS与TypeScript的集成很好load函数和组件之间的data类型能自动推断。但当你开始使用更高级的模式如动态路由参数推导、复杂的actionData类型时可能会遇到类型挑战。我的建议是在复杂场景下适当使用TypeScript的as断言或定义明确的接口避免在类型体操上耗费过多时间优先保证运行时正确性。社区生态还在成长这是选择新兴框架必须面对的现实。当你遇到一个诡异的问题时Stack Overflow上可能没有答案GitHub Issues可能是你唯一的求助渠道。但同时你也更容易与核心开发者直接交流你的反馈可能直接影响框架的发展方向。对于追求稳定性的企业级项目需要权衡这一点。经过这次全面的迁移和深度使用RakkasJS给我的总体印象是它是一个充满野心且设计精巧的框架。它没有试图复制一个Next.js而是在吸收其精华文件路由、SSR的基础上在开发者体验的“锐度”和运行时性能的“深度”上做了大胆的探索。“Bun优先”的策略让它拥有了极致的开发速度而选择性水合、统一的数据加载模型等特性则为高性能应用提供了底层控制能力。它目前可能还不适合每一个团队或每一个项目。如果你需要一个拥有最庞大插件生态、最稳定企业支持、最无缝Serverless部署的框架Next.js依然是更安全的选择。但如果你是一个追求技术前沿、对性能有极致要求、且愿意拥抱Bun生态的团队或开发者RakkasJS提供了一个令人兴奋的、更具控制力的替代方案。它像是一把精心打磨的瑞士军刀虽然不像重型机械那样功能齐全但在其专注的领域——构建快速、高效、体验优秀的全栈React应用——它表现得异常出色。我的这个后台管理系统在迁移后不仅开发体验更流畅页面性能指标也有了切实的提升这让我觉得当初投入时间探索它是完全值得的。