RakkasJS深度解析：基于Bun的全栈React框架性能与迁移实践

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 <div>User: {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 rakkas@latest my-app cd my-app

接下来是最耗时的部分：项目结构的映射与重构。RakkasJS的默认结构是src/routes对应页面，src/lib用于工具函数和共享逻辑，src/components用于公共组件。这与Next.js App Router的app目录结构有显著不同。

核心映射关系：

• app/page.tsx->src/routes/index.tsx
• app/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。
• 服务端专用库：如数据库ORM（Prisma、Drizzle）、邮件发送库等，可以继续在load函数和action中使用。RakkasJS能正确地进行树摇，不会将这些库的代码打包进客户端bundle。

4.4 迁移后的性能与开发体验对比

完成核心页面迁移后，我进行了一系列对比测试：

开发体验（Dev Experience）:

• 热更新（HMR）速度：RakkasJS（Vite）在大多数场景下快于Next.js（Turbopack），尤其是在只修改样式或单个组件时，几乎是毫秒级更新。但在修改涉及多个路由的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）:

1. 运行构建命令：bun run build(或npm run build/pnpm build)。
2. 构建产物会输出到dist目录，其中包含一个server子目录（服务端代码）和一个client子目录（静态资源）。
3. 你可以使用bun run start来启动生产服务器。框架会使用一个高性能的HTTP服务器（如hono或node:http适配器）来服务应用。
4. 建议使用进程管理器（如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_ENV=production # 复制必要的文件 COPY --from=base /app/dist ./dist COPY --from=base /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 常见问题与解决方案速查表

在迁移和开发过程中，我遇到了不少问题，以下是其中一些典型问题及其解决方案：

5.4 我踩过的“坑”与独家心得

1. 不要过早优化水合：在项目初期，不要花太多时间琢磨clientOnly。先让应用跑起来，功能完整。在性能测试阶段，通过分析工具找到真正的性能瓶颈再下手。过早的优化会增加代码复杂度，可能引入难以调试的bug。

2. 谨慎对待streaminload：流式渲染是高级特性，威力强大但也复杂。它最适合用于聚合多个独立慢速数据源的页面。如果你的数据源本身很快，或者有强依赖关系，使用流式渲染可能反而增加复杂度，收益不大。务必在真实网络环境下测试其效果。

3. 类型安全是双刃剑：RakkasJS与TypeScript的集成很好，load函数和组件之间的data类型能自动推断。但当你开始使用更高级的模式，如动态路由参数推导、复杂的actionData类型时，可能会遇到类型挑战。我的建议是，在复杂场景下，适当使用TypeScript的as断言或定义明确的接口，避免在类型体操上耗费过多时间，优先保证运行时正确性。

4. 社区生态还在成长：这是选择新兴框架必须面对的现实。当你遇到一个诡异的问题时，Stack Overflow上可能没有答案，GitHub Issues可能是你唯一的求助渠道。但同时，你也更容易与核心开发者直接交流，你的反馈可能直接影响框架的发展方向。对于追求稳定性的企业级项目，需要权衡这一点。

经过这次全面的迁移和深度使用，RakkasJS给我的总体印象是：它是一个充满野心且设计精巧的框架。它没有试图复制一个Next.js，而是在吸收其精华（文件路由、SSR）的基础上，在开发者体验的“锐度”和运行时性能的“深度”上做了大胆的探索。“Bun优先”的策略让它拥有了极致的开发速度，而选择性水合、统一的数据加载模型等特性，则为高性能应用提供了底层控制能力。

它目前可能还不适合每一个团队或每一个项目。如果你需要一个拥有最庞大插件生态、最稳定企业支持、最无缝Serverless部署的框架，Next.js依然是更安全的选择。但如果你是一个追求技术前沿、对性能有极致要求、且愿意拥抱Bun生态的团队或开发者，RakkasJS提供了一个令人兴奋的、更具控制力的替代方案。它像是一把精心打磨的瑞士军刀，虽然不像重型机械那样功能齐全，但在其专注的领域——构建快速、高效、体验优秀的全栈React应用——它表现得异常出色。我的这个后台管理系统在迁移后，不仅开发体验更流畅，页面性能指标也有了切实的提升，这让我觉得，当初投入时间探索它是完全值得的。