加载失败
原贴来自作者在使用 Next.js App Router（由 Vercel 维护的 React 框架路由与布局系统）一年后的迁移经验分享，指出 RSC、Turbopack 等新特性带来的复杂性与稳定性问题。评论进一步扩展了实务证据：有人报告迁移后 pagespeed 与托管成本上升，有人抱怨 RSC 的实现会导致整页重挂载并丢失状态，也有人分享回退到 Vite + 轻量路由（如 Wouter）或传统后端框架（Django、Spring Boot、Flask/FastAPI）的成功案例。讨论还触及路由器在数据加载编排上的演进、具体路由库的差异（React Router v7、TanStack 等）以及社区为“创新戏剧”付出的长期维护成本。理解这些争论需要对 CSR/SSR/SSG 等渲染策略和常见构建工具（Vite、Webpack、Turbopack）有基本认识。
很多评论者直接指责 Vercel 自 App Router 以来做出令人困惑且破坏性的决策，列举了 Turbopack、缓存层、把 middleware 改称 "proxy"、奇怪的 layout 组件以及不断推送处于 alpha 的特性。有人具体指出 Next.js 的实现会破坏基本 JS API（例如 fetch 与重定向），托管集成半专有且容易出错，同时基础功能如 i18n 和认证没有稳定方案。还有真实案例称从 gulp 切换到 Next 后 pagespeed 与托管成本上升，表明在生产环境中存在性能与成本退化。总体结论是评论者对 Next.js 的生态稳定性与长期维护成本非常担忧，建议在关键项目上慎重或避免采用。
不少开发者表达了回归更简单工具链的实践：用 Vite 初始化、配合 React Router 或极简路由库 Wouter 就能覆盖大多数纯客户端应用的需求，构建默认更合理且“就能用”。当确需服务端能力时，团队更倾向用成熟后端（如 Spring Boot、Flask/FastAPI、Django）而不是把 Node/Next 当作万能后端，以避免 Next 带来的复杂性与维护负担。有人报告把 Next 替换为简单路由后代码更易理解、性能更好；也有人推荐 TanStack 等方案为替代，但同时指出具体实现（如回退键处理）仍有短板。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6]
React Server Components（RSC）在评论中成为争议核心：许多人抱怨 Next.js 在加载 Server Component 时会触发整页重挂载，从而丢失客户端状态，这一实现细节被视为严重缺陷。部分评论者认为 RSC 在理论上有优化初始加载的价值，但在实践中大幅增加复杂度，使原本简单的客户端交互更难构建和调试；因此对 SEO 的页面建议用静态生成（SSG），而对交互密集的应用建议采用纯客户端渲染或 PWA。也有评论保留希望态度，认为未来运行时或更成熟实现（如 bun）可能改善性能，但当前多数人选择禁用或回避 Server Components。
多条评论把问题上升到生态与激励层面，认为当前框架作者更倾向于制造新颖模式以获得关注（写技术亮点的博客比稳定可靠更有回报），这导致大量概念堆叠和频繁破坏性变更。评论指出这种文化造成升级/兼容性成本，让团队不得不花时间修复框架带来的问题而非专注产品与用户。评论举例说明许多长期成功的产品依赖“无聊但可靠”的技术栈（如 Django、Rails），并警告新潮方案或半成品被过度推广会带来长期运维负担。
关于路由的讨论既有对路由器角色演化的技术性思考，也有对具体库的使用反馈：部分人认为路由器正被赋予数据加载与预取编排的职责（类似查询规划器），这一自动化追求既能降低手工优化工作量也会引入难调试的复杂性。实务层面，React Router v7（与 Remix 的整合）、Next 的 Pages/App Router、Wouter、TanStack 等在模式与细节上有明显差异；例如有人抱怨 TanStack 在回退键（back button）处理上存在问题，会丢失用户数据。这些差异促使团队在可控性与功能性间权衡，很多人选择更轻量或更可预测的路由实现。
RSC (React Server Components): React Server Components（RSC）是一种把部分组件在服务器端渲染并与客户端组件混合的模型，目的是减少客户端 JS 负载。但在 Next.js 的实现里，评论指出 RSC 会触发整页重挂载、导致状态丢失并增加调试与工程复杂度。
App Router (Next.js App Router): Next.js App Router 是 Next.js 推出的文件路由与布局系统，设计上与 RSC、嵌套布局和数据获取机制紧密结合。评论中对其 API 频繁变更、概念堆叠和易用性提出批评。
Turbopack: Turbopack 是 Vercel 为替代 Webpack 在 Next.js 生态中推出的构建/打包器，宣称更快的开发体验。评论把它列为被过早强推的例子，担忧其 alpha 状态带来不稳定性。
渲染模式（SSR/SSG/ISG/PPR）: 这些缩写描述页面生成与更新的策略：SSR（Server-Side Rendering）在请求时服务器渲染页面；SSG（Static Site Generation）在构建时生成静态页面；ISG（增量静态重建）允许运行时逐页更新；PPR 等缩写通常指部分/渐进式渲染或预取策略。评论抱怨大量初始缩写增加理解成本。