Next.js 并非最好的框架，它是最稳妥的选择。

Next.js 是使用最广泛的 React 框架，但它也是最令人讨厌的框架之一。

调查显示，虽然其使用率很高，但满意度正在下降。人们抱怨其复杂性以及 App Router。他们认为它过于臃肿，或者强迫你使用 Vercel。

其中一些说法是事实，但大部分并非如此。

大多数人要么选错了工具，要么在试图对抗工具的设计逻辑，然后就开始责怪工具。

我使用 Next.js 进行开发已有多年。我曾将其用于那些一旦出错就会造成实际经济损失的平台。以下是我的观点。

Next.js 并不是最好的框架，它是最稳妥的选择。这两者是完全不同的概念。

实际项目有很多需求。你不仅需要一个内容网站，还需要仪表盘、编辑器预览以及应对大规模访问的能力。

其他框架在单一任务上更胜一筹：

  • Astro 非常适合静态网站。
  • SvelteKit 在开发者体验和精简输出方面表现卓越。

但当需求变得复杂时，Next.js 就会脱颖而出。

它提供了许多内置功能，否则你必须自己动手实现：

  • Incremental Static Regeneration，无需完整重新构建即可更新页面。
  • Draft Mode，方便进行编辑预览。
  • Edge runtime，用于实现快速的中间件和身份验证。
  • Streaming 和 Suspense，用于处理缓慢的数据加载。
  • Server Actions，无需单独的 API 即可运行逻辑。

它还具有巨大的“引力”。它构建在 React 之上，因此 AI 模型的训练数据量非常庞大。当你使用 AI 编写 Next.js 代码时，效果会更好，因为相关的模式随处可见。

权衡是现实存在的，你应该了解这些代价：

  • 它具有高度的“主见”（opinionated）。如果你不需要它的某些特性，你就会感到处处受限。
  • 可移植性一直是个问题。长期以来，脱离 Vercel 运行一直很困难。
  • App Router 的转型过程既混乱又令人困惑。

教训在于：选择 Next.js 是一个“全盘接受”的决定。

如果你尊重框架并按照它的设计初衷去使用，它会助你一臂之力；如果你试图违背它的设计逻辑去强行使用，你将付出长期的代价。

我曾见过一个团队构建了一套自定义架构，但这破坏了 Next.js 的路由规则。虽然从工程角度看他们的选择是合理的，但却与框架产生了冲突。他们花了数月时间去为 SEO 和链接等问题编写各种变通方案（workarounds）。

问题不在于框架，而在于适配度。

如果你要构建一个必须运行多年的复杂系统，Next.js 是那个出错概率最低的选择。请在它设计的应用场景中使用它。

Source: https://dev.to/fredcorr/nextjs-isnt-the-best-framework-its-the-most-reliable-bet-5e2c