企业官网建设流程全解析

最近几年，前端框架似乎越来越喜欢做全栈。

React 有 Next.js，Vue 有 Nuxt，Svelte 有 SvelteKit。它们不再只负责页面渲染，而是逐渐将路由、数据获取、服务端逻辑、缓存等能力整合到同一套开发体系中。

但我一直有一个疑问：既然前后端分离已经是一套成熟的开发模式，为什么我们还需要越来越复杂的全栈框架？

对于很多项目而言，使用 Vite 构建前端，再搭配 Elysia 提供独立 API，似乎也能很好地完成任务。前端负责界面与交互，后端负责业务逻辑，各自独立开发、构建和部署。

那么，Next.js、Nuxt、SvelteKit 这些全栈框架，究竟解决了什么问题？它们真的比 Vite + Elysia 更好吗？

这篇文章不打算简单地比较框架的功能数量，而是从架构设计、开发体验、性能与部署成本等角度，分析两种开发模式的取舍。

一、为什么越来越多框架开始做全栈？

先看传统的前后端分离架构。

浏览器 │ ▼ 前端应用（Vue / React / Svelte） │ │ HTTP API ▼ 后端服务（Elysia / NestJS 等） │ ▼ 数据库

前端负责页面展示、用户交互和客户端状态，后端负责业务逻辑、权限校验和数据访问。双方通过 API 通信，各自独立部署。

这套架构没有过时，至今仍然适合大量 Web 应用。

但它也有一些需要额外处理的问题。

1. 页面渲染不再只是客户端的事情

传统 SPA 通常需要浏览器下载并执行 JavaScript，再完成页面渲染和数据获取。

对于管理后台，这往往完全可以接受。但对于公开内容网站，开发者可能更希望服务器直接返回包含页面内容的 HTML。

于是，SSR、SSG 等渲染方式逐渐成为现代 Web 开发的重要组成部分。

• CSR：浏览器负责渲染页面。

• SSR：服务器根据请求生成 HTML。

• SSG：在构建阶段提前生成 HTML。

全栈框架将这些能力与路由、数据加载和页面组件整合起来，让开发者不必从零搭建一整套渲染方案。

2. 前后端之间存在重复工作

在传统架构中，前端需要调用 API，处理请求状态和错误；后端需要定义接口、校验参数和返回数据。

如果没有合适的类型共享机制，双方还可能重复维护接口定义。

全栈框架可以将页面与服务端数据获取放进同一套开发模型中。一些框架还提供服务端函数、表单处理或类型推导能力，减少开发者手动组织代码的工作。

但这并不意味着前后端分离无法解决这些问题。通过共享 Schema、类型推导和 API 客户端，同样可以建立可靠的开发流程。

3. 框架希望提供一套完整的解决方案

Next.js、Nuxt、SvelteKit 的核心价值，不只是让前端代码和后端代码写在同一个项目里，而是统一处理应用中的许多问题：

• 页面路由和布局。

• 数据获取与加载状态。

• 服务端渲染和静态生成。

• 服务端逻辑与接口处理。

• 缓存、重新验证和部署集成。

它们通过约定减少重复配置，让开发者更快进入业务开发。

代价是，开发者也需要理解框架的约定和运行机制。

全栈框架的本质，是用一套集成的开发模型，换取更少的重复配置和更统一的应用体验。

二、Next.js、Nuxt、SvelteKit 分别解决什么问题？

虽然它们经常被放在一起比较，但三者首先服务于不同的 UI 框架。

Next.js：充分利用 React 生态

Next.js 的一个明显优势，是能够利用庞大的 React 生态。

对于已经熟悉 React、需要构建复杂 Web 应用的开发者，它提供了一套比较完整的开发方案。

不过，Next.js 的 App Router 也引入了一些需要认真理解的概念，例如 Server Components、Client Components、缓存与重新验证。

这些机制并不是简单增加几个 API，而是影响组件在哪里执行、数据在哪里获取，以及页面如何生成。

它们能够解决实际问题，但也带来了额外的学习成本。

Nuxt：让 Vue 开发者拥有完整的应用框架

Nuxt 围绕 Vue 提供了约定式路由、自动导入、useFetch、useAsyncData和 Nitro 等能力。

对于已经熟悉 Vue Composition API 的开发者来说，它的学习路径通常比较自然。

这里还有一个容易被忽略的细节：Nuxt 本身就使用 Vite 作为默认构建工具。

因此，Nuxt 并不是 Vite 的替代品。它是在底层开发与构建工具之上，提供更完整的应用框架能力。

SvelteKit：简洁的组件体验与完整的应用能力

SvelteKit 为 Svelte 提供路由、数据加载、表单处理和服务端功能。

Svelte 的组件写法比较简洁，响应式模型也有自己的特点。对于喜欢轻量语法、希望减少样板代码的开发者，它是值得考虑的选择。

SvelteKit 同样基于 Vite 的开发和构建流程。

由此可见，三者真正值得比较的是应用层面的设计：如何组织路由、如何加载数据、如何划分服务端与客户端逻辑，以及如何控制渲染和缓存。

底层使用什么构建工具，只是其中的一部分。

三、Vite + Elysia：把前后端职责分开

如果不采用全栈应用框架，我们可以自行组合前端和后端技术。

例如：

前端： Vite + Vue / React / Svelte 后端： Elysia + Bun 通信： HTTP / SSE / WebSocket 数据层： 数据库 + ORM

前端使用 Vite 进行开发和构建，生产环境输出静态资源；Elysia 作为独立后端，负责 API、业务逻辑和数据访问。

这是我比较喜欢的一种架构。

原因并不是它一定比全栈框架更快，而是它的职责边界清楚，技术选择也比较自由。

1. 前端和后端可以独立演进

假设我们正在开发一个 AI 聊天应用。

前端负责聊天界面、消息列表、流式输出和交互状态；后端负责调用大模型、管理会话、校验权限和访问数据库。

当我们更换前端 UI 框架时，只要 API 契约保持兼容，后端通常不需要跟着修改。

反过来，如果后端从 Elysia 换成 NestJS，只要对外接口兼容，前端也不必大规模重写。

这种边界对于多客户端应用尤其有价值：Web、移动应用和其他客户端可以共同使用一套后端 API。

2. 不需要 SSR，就没有必要强行引入 SSR

并不是所有 Web 应用都需要服务端渲染。

对于管理后台、内部工具和 AI 聊天应用，SEO 往往不是核心需求，客户端渲染完全可以胜任。

使用 Vite 构建 SPA，可以直接将静态资源部署到 CDN 或静态文件服务器，让浏览器负责页面渲染。

后端只需要承担实际的业务请求。

如果项目确实需要 SSR，也可以选择支持 SSR 的方案，而不是为了框架完整性，默认给所有页面增加服务端渲染流程。

架构设计应该由项目需求决定，而不是由框架能提供什么功能决定。

3. 后端技术不必跟随前端框架

使用 Vite + Elysia，我们可以根据实际需求选择后端技术。

喜欢 Bun 的运行体验，可以选择 Elysia；业务结构更复杂，希望采用更明确的模块化组织方式，可以考虑 NestJS；其他团队也可以使用自己熟悉的后端语言和框架。

前端不必知道后端内部使用了什么技术，只需要遵守双方约定的 API 契约。

这种自由度很有吸引力。

当然，自由度越高，也意味着越多事情需要自己设计：项目结构、接口规范、鉴权、日志、错误处理、监控和部署流程，都不能完全依赖一个统一框架替你决定。

四、性能和内存：全栈框架一定更重吗？

这是我比较关心的问题。

如果前端最终可以构建成静态资源，为什么还需要让一个 JavaScript 应用在服务器上持续运行？

不过，这里必须先区分框架的能力和应用的运行方式。

1. 静态前端不需要为每次页面访问执行服务端渲染

对于 Vite 构建的 SPA，生产环境通常只需要分发 HTML、CSS、JavaScript 和其他静态资源。

这些资源可以交给 CDN 或 Nginx 提供，不需要为每个页面请求执行一遍服务端渲染逻辑。

Elysia 仍然需要运行，但它主要负责后端业务请求。

对于不需要 SSR 的项目，这是一种相对直接的部署方式。

2. SSR 增加服务端工作，但不代表一定更慢

SSR 需要服务器生成页面，有时还要获取数据、执行组件逻辑和处理缓存。

这确实会增加服务端计算需求。

但 SSR 也可以与缓存、静态生成和增量更新结合，避免每次请求都重新执行完整的渲染流程。

Next.js、Nuxt 和 SvelteKit 都支持不同的渲染策略，并不是所有项目都需要让每个页面请求经过完整的动态渲染。

因此，不能简单地说全栈框架一定更占内存，也不能认为前后端分离一定更快。

3. Bun + Elysia 的轻量优势值得关注，但应该通过实测验证

我喜欢 Elysia 与 Bun 的组合，因为它提供了相对直接的开发体验和独立的后端架构。

但框架本身的基准测试，并不能直接代表生产环境的实际内存占用。

运行时成本还取决于依赖数量、数据库连接池、缓存、并发量和业务逻辑。

如果真的要比较，可以在相同业务、数据库和测试条件下，测量常驻内存、请求延迟、吞吐量和部署资源成本。

轻量是一个值得追求的目标，但是否真正轻量，最终还是应该看具体实现和测试结果。

五、开发体验：整合得越多，就一定越好吗？

两种架构其实是在不同地方节省成本。

全栈框架减少重复配置，将路由、渲染、数据获取和服务端能力整合在一起。对于个人开发者或小团队，这可以明显降低项目启动和维护的成本。

而前后端分离更强调职责边界，允许前端和后端独立部署、独立演进，并让多个客户端共享同一套业务 API。

但前后端分离也会产生额外工作。

例如：

• 如何共享 API 类型？

• 如何统一处理鉴权和错误？

• 如何管理跨域与环境配置？

• 如何确保前后端部署版本兼容？

• 如何组织多个项目之间的公共代码？

如果这些问题没有处理好，所谓的架构自由就可能变成重复代码和维护负担。

反过来，全栈框架虽然提供了更多集成能力，但开发者也需要接受它的设计约定。当项目需求与框架的默认模型不匹配时，调整起来未必轻松。

因此，真正应该比较的不是哪种架构写起来代码更少，而是整个项目需要维护多少复杂度。

六、类型安全：独立后端就一定会重复维护接口吗？

TypeScript 开发者通常很关心前后端之间的类型共享。

如果前端和后端都使用 TypeScript，能否让 API 的输入、输出和错误类型保持一致？

这也是我喜欢 Elysia 的一个原因。

Elysia 可以结合 Eden Treaty，让客户端从服务端路由定义中获得类型信息，减少重复维护接口类型的工作。

但要注意，类型共享不等于运行时校验。

TypeScript 类型主要在编译阶段提供约束，不能保证用户提交的数据一定符合预期。服务端仍然需要运行时参数校验、鉴权和业务规则检查。

同样，全栈框架也可以结合共享 Schema、类型推导和 API 客户端工具，建立可靠的类型体系。

所以，类型安全不是全栈框架独有的优势。更重要的是，项目是否有清晰的接口契约，以及能否确保契约和实际实现保持一致。

七、到底应该怎么选？

我不会给出一个适用于所有项目的答案，而是根据需求做选择。

这张表表达的是我的默认倾向，而不是绝对规则。

例如，Next.js、Nuxt 和 SvelteKit 也能支持静态生成；Vite 也可以配合 SSR 方案。两种架构并不是非此即彼，实际项目还可以根据不同页面的需求采用混合方案。

八、我的选择：不是追求最完整的框架，而是控制不必要的复杂度

如果让我为很多中小型 Web 项目选择一套默认技术栈，我会认真考虑：

• 前端：Vite + Vue / React。

• 后端：Bun + Elysia。

• 数据库：PostgreSQL 或 MySQL。

• 数据访问：根据需求选择 ORM。

• 通信：HTTP、SSE 或 WebSocket。

我喜欢这种组合，是因为它的职责边界比较明确，也允许我根据实际需要替换其中某个部分。

但我不会认为它适合所有项目。

如果项目的核心需求就是复杂的服务端渲染，使用成熟的全栈框架可能更省事；如果团队已经深度使用某个框架，迁移架构也未必能带来收益。

技术选型真正应该考虑的，不是框架能提供多少功能，而是项目需要什么功能，以及实现这些功能需要承担多少维护成本。

全栈框架的价值，是将常见能力整合起来，让开发者少做重复工作。

Vite + Elysia 的价值，则是让前后端职责更加独立，给予开发者更大的架构选择空间。

两种方式没有绝对的高下。

框架整合得越多，不代表项目就越先进；把事情拆得越开，也不代表架构就越优雅。真正重要的是，框架提供的便利，是否值得我们为它承担相应的复杂度与约束。

与其追求一套能解决所有问题的框架，不如先明确项目真正需要什么，再选择最适合它的工具。

这可能才是技术选型中最值得坚持的原则。