你的项目真的需要 Next.js 吗？

Source: Dev.to

Introduction

最近，我看到越来越多的团队把项目从 Next.js 迁移到 TanStack。像 Inngest（将本地开发时间缩短了 83 %）、OpenPanel 和 Documenso 这样的案例变得越来越常见。每次读到这些故事，我都会想：一开始 Next 真的是正确的选择吗？

我了解其中的挑战——从 Pages Router 迁移到 App Router，对开发者体验的影响，关于 Vercel 锁定的讨论，以及在迁移过程中出现的一些安全顾虑。但也许重点并不是“Next 很糟”。真正的问题可能是：这些项目一开始真的需要使用 Next 吗？

What Next.js Is Designed For

Next.js 是一个有明确取向的框架，用于构建 React 应用，重点在服务器端渲染（SSR）。它是为 SSR、ISR、SSG 以及所有 Vercel 推广的这些缩写而设计的。

最初的目标很明确：

• 尽可能多地预渲染
• 提供 HTML 以优化 SEO
• 减少加载时间
• 在构建后交付极高性能的体验

理想情况下，你会生成静态页面，在需要时失效缓存，并交付更快的页面。

Typical Use Cases

• 博客
• 新闻门户
• 落地页
• 具有公开目录的市场平台
• 以 SEO 为核心的电商

换句话说：内容可以预渲染且 SEO 对成功至关重要的产品。

When Next.js May Not Be the Best Fit

当我们把为服务器端设计的工具用于完全动态、依赖客户端的系统时，就会出现问题：

• 交互性强的内部系统
• 包含大量过滤器、模态框、复杂本地状态以及频繁数据更新的应用
• 几乎所有内容都取决于登录用户及其最近操作的产品

在这些情况下，几乎没有东西可以静态生成。SEO 不是优先级，预渲染的 HTML 也无关紧要。真正重要的是状态管理和交互性。

TanStack as an Alternative

TanStack 的模型更接近传统的 SPA，SSR 只是一个可选功能，而不是架构前提。标准工作流很简单：

1. 路由
2. 查询
3. 变更
4. 失效

不必时刻担心组件是应该在服务器端还是客户端渲染。应用本质上是客户端优先，使用服务器渲染是有意识的选择——而不是起点。

Closing Thoughts

也许现在发生的事情并不是“拒绝 Next”。它可能只是反映了在当下选择最合适的框架，而不是基于架构和产品的决定（向 React 致敬，因为它有竞争者提供更优雅的解决方案，但这又是另一个话题）。

我刚开始在个人博客上写作并分享我的想法，欢迎提出新思路和反馈！Visit: