狠狠吐槽一下SSR/Next.js（四）：Next.js 的隐性成本正在被大模型掀翻

stonefisher

253人浏览 · 2026-07-07 10:42:06

stonefisher · 2026-07-07 10:42:06 发布

开篇：当 AI 开始计算"框架税"

过去三年，有无数文章分析Next.js的"好处"：

更好的SEO
更快的首屏
更全栈的能力

但没人计算过一件事：使用Next.js的隐性成本。

学习成本（新成员上手要多久？）
调试成本（一个水合错误要花多少小时？）
升级成本（major版本迁移要几个sprint？）
工具成本（AI写错的代码要人工改几次？）

这些成本，在人类开发者主导的时代，被当做"不可避免的工程开销"默默承受了。

但在AI时代，这些成本突然被放大了10倍。

因为AI会"加速"一切，包括你的错误。

你用AI生成代码速度翻倍 → 生成错误代码的速度也翻倍
你用AI调试效率提升 → 发现环境问题的效率也提升
你用AI重构的频次增加 → 遇到破坏性变更的频次也增加

AI是一面放大镜，把Next.js所有隐性问题照得清清楚楚。

今天，我们就来盘点那些在AI时代，变得格外扎眼的"Next.js新槽点"。

槽点一：Token 税——每个 Next.js 特性都在烧你的钱

在AI时代，Token就是金钱。

你用Cursor、Copilot、ChatGPT，每一次对话都在消耗Token。Token消耗越多，你的时间成本、API费用、订阅费就越高。

现在我们来算一笔账：让AI理解一个Next.js项目，需要多少Token？

1. 上下文污染

要让AI正确生成Next.js代码，你需要给它提供：

text

- next.config.js 配置（至少200行）
- tsconfig.json 配置（至少50行）
- .env 变量列表（至少20个变量）
- 项目路由结构（几十个文件路径）
- 用的什么Router（Pages还是App）
- 版本号（12、13还是14）
- 用了哪些额外库（tRPC、Prisma、NextAuth...）

这些信息塞进AI上下文，至少消耗 2000-5000 Token。每次对话都要重复。

2. 反复纠错的"轮回税"

普通框架：AI生成代码 → 跑通（1-2轮对话）

Next.js：AI生成代码 → 报错 → 贴错误 → AI修改 → 报另一个错 → 贴错误 → AI再修改 → 又报错 → 发现是环境问题 → 手动改 → 勉强跑通（5-10轮对话）

每轮对话都是Token。Token就是时间。时间就是钱。

我们做个保守估算：

场景	普通框架	Next.js	Token浪费倍率
生成一个列表页	500 tokens	2000 tokens	4x
修复一个数据获取bug	300 tokens	1500 tokens	5x
升级依赖版本	100 tokens	3000 tokens	30x
新人上手第一个功能	1000 tokens	8000 tokens	8x

你用Next.js，就等于在AI时代主动给自己加了一个"消费升级"的buff。

你的Token账单比人家贵3-5倍，效率还更低。

这不是"全栈"，这是"全贵"。

槽点二：文档分散——AI 的训练数据"落后于版本"

大模型的知识截止日期，是它的"天花板"。

GPT-4的知识截止到2023年10月。Claude 3.5到2024年4月。

而Next.js呢？

2022年10月：Next.js 13 发布，App Router来了
2023年5月：Next.js 13.4，Server Actions稳定
2023年10月：Next.js 14，Turbopack推进
2024年5月：Next.js 15，React 19 集成…

Next.js的迭代速度，超过了AI模型的更新速度。

这意味着什么？

场景一：AI给你生成了不存在的API

“用 next/router 的 useRouter 来处理App Router的动态路由。”

——错。App Router要用 next/navigation 的 useRouter。

“用 getServerSideProps 在Server Component里获取数据。”

——错。Server Component里直接 async function 就行。

“用 next/head 来设置页面标题。”

——错。App Router用 export const metadata。

AI的训练数据里塞满了老版本的信息，它分不清哪个API属于哪个版本。

你让AI帮你写代码，结果它把"考古"的工作甩给了你。

场景二：AI给你"跨版本混搭"

这是一个真实案例。我让AI把一段"Pages Router代码"迁到"App Router"：

AI给出的代码里，同时出现了：

getStaticProps（Pages Router语法）
export const metadata（App Router语法）
import { useRouter } from 'next/router'（Pages Router语法）
一个用了 'use client' 的组件（App Router语法）

它把两个世界的写法"熔合"在了一起。

然后我告诉AI：“这是一个App Router项目，不要用Pages Router的API。”

AI回答：“抱歉，我混淆了。下面是修正后的版本…”

然后它又引入了 第三个版本 的写法。

AI不是笨，是Next.js的"版本碎片化"把AI搞分裂了。

场景三：AI的"版本选择恐惧症"

你问AI：“Next.js里怎么设置动态路由？”

AI会给你列出：

Pages Router方式：pages/[slug].js + getStaticPaths + getStaticProps
App Router方式：app/[slug]/page.js + generateStaticParams + generateMetadata
还有一种古老的方式：pages/[slug].js + getServerSideProps（在Pages Router里）

然后AI说：“请根据你的项目版本选择合适的方案。”

你在用一个AI"诊断"你的版本，而不是"写代码"。

这不叫AI辅助编程，这叫AI帮你"做选择题"——还是多选题。

槽点三：Prompt 复杂度爆炸——你要先成为"Next.js架构师"才能用好AI

在普通框架里，你给AI的prompt可以很简单：

“帮我写一个展示商品列表的页面”

AI就能生成。

在Next.js里，你的prompt必须"武装到牙齿"：

“帮我写一个展示商品列表的页面。用的是Next.js 14，App Router，Server Component模式。不需要’use client’，数据从Prisma读取，用async函数获取。不要用getServerSideProps，那些是Pages Router的写法。路由在app/products/page.tsx。页面SEO用export const metadata来配置，不要用next/head。如果有加载状态，用Suspense处理…”

你看到了吗？一个简单的页面，你要在prompt里写清楚：

框架版本（14）
路由模式（App Router）
组件类型（Server Component）
数据来源（Prisma）
获取方式（async函数）
废弃API（避免getServerSideProps）
文件路径（app/products/page.tsx）
SEO方式（export const metadata）
加载状态（Suspense）

你的"认知负载"没有降低，反而从"自己写代码"变成了"指导AI写代码"——而指导本身需要同样的知识。

你问：“那我不写这么多，让AI自己判断呢？”

AI会给你一个"大杂烩"代码，包含所有版本的写法，然后你需要自己去筛选哪个能用。

这等于你把"写代码"变成了"审代码"——后者可能更累。

槽点四：AI Code Review 失效——连工具都不知道"正确"是什么

在现代软件开发里，AI Code Review（代码审查）已经越来越重要。

工具会自动检查你的代码：

有没有安全隐患
有没有性能问题
有没有违反最佳实践

但面对Next.js的代码，AI Code Review工具基本"瞎了"。

为什么？

因为"正确"的Next.js写法，取决于太多变量：

这个文件是用Pages Router还是App Router？
这个组件是Server Component还是Client Component？
这段代码在哪个版本里是正确的？
这个模式是在新版本里推荐，还是在旧版本里必须？

AI Review工具没有"版本感知"，也没有"路由模式感知"。

它会给你一个"通用"的建议，比如：

“不建议在getServerSideProps里使用客户端Hook。”

——如果这是App Router项目，根本没有getServerSideProps。建议无效。

“建议使用Image组件替代img标签。”

——但如果是在一个Server Component里，Image组件的某些用法已经变了。

你收到的"最佳实践建议"，有一半是错的。

这导致：

开发者开始忽视AI Review工具的建议（“每次都不准”）
团队内部的"约定"超过工具的建议（“我们按自己习惯来”）
最终回到"人工Review"时代（效率倒退）

AI时代的Code Review自动化，在Next.js面前形同虚设。

槽点五：代码生成的质量退化——AI 的"平均化"趋势在伤害你

大模型的训练数据，来自全世界的开源代码。

它生成的不是"最优代码"，而是"最常见的代码"（average code）。

在普通React生态里，最常见和"最优"相差不大。因为范式简单，大家都那么写。

但在Next.js生态里，由于版本和模式的碎片化——最常见的写法，往往是"最安全的写法"，而不是"最优的写法"。

AI倾向于生成什么？

用 'use client' 把所有组件都变成客户端组件（因为这样不会出错）
用 useEffect + fetch 代替 getServerSideProps（因为这样不会涉及服务端环境问题）
用 any 类型代替精确的类型（因为这样不会触发类型冲突）
用 typeof window !== 'undefined' 到处添加判断（因为这样能防止水合报错）

这些写法"安全"吗？安全。
这些写法"正确"吗？正确。
这些写法"高效"吗？——不高效。 它们抹掉了SSR的所有好处，把Next.js用成了一个"更慢的React"。

AI在教你如何"绕过Next.js"，而不是"用好Next.js"。

因为"绕过"在训练数据里更多，"用好"的训练数据太少（不同的版本、不同的模式，很难形成统一的模式）。

AI的"平均化"特性，会让你的Next.js代码变得越来越"平庸"，越来越"凡俗"，越来越像普通的React（甚至不如普通React）。

槽点六：自动化测试的噩梦——AI生成的测试，永远在"挂科"

在AI时代，自动生成单元测试和集成测试已经是标配。

但面对Next.js的代码，AI生成的测试用例，失败率极高。

为什么？

原因一：组件需要"环境模拟"

tsx

// 这个组件里，哪些逻辑在服务端跑？哪些在客户端跑？
// 测试用例要在哪个环境里跑？
export default function Profile({ user }) {
  // 这个useEffect里访问了window
  useEffect(() => {
    localStorage.setItem('lastVisit', Date.now());
  }, []);
  
  // 这个函数在客户端执行
  const handleClick = () => {
    fetch('/api/profile');
  };
  
  // 这段JSX在服务端和客户端都执行
  return <div>{user.name}</div>;
}

AI生成的测试用例，如果用了jsdom模拟浏览器环境，那么在测试getServerSideProps时会失败（因为那里没有window）。
如果用了node环境，那么测试useEffect时会失败（因为那里没有localStorage）。

AI不知道应该在哪个"环境"里跑哪个测试。

普通框架：测试全在jsdom里跑，一直正确。
Next.js：测试要在不同环境里"分片"跑，AI完全搞不定。

原因二：路由依赖难以模拟

AI生成的测试，经常依赖next/router或next/navigation的useRouter。

但测试框架里怎么模拟useRouter？怎么模拟getServerSideProps的context参数？怎么模拟redirect和notFound？

AI生成的"模拟代码"往往不完整，导致测试报错。

原因三：API路由测试的"连坐效应"

Next.js的pages/api或app/api里的代码，依赖了前端项目的配置和依赖。

AI想为API路由生成测试时，它需要：

模拟整个Next.js的请求上下文
设置正确的环境变量
初始化数据库连接
处理前端配置

一个API路由的测试，要拉起半个项目。

AI不会做这些。它只会生成一个简单的"调用这个函数，检查返回值"的测试——然后失败。

结果：AI测试生成，在Next.js里几乎不可用。

你只能人工写测试。AI生成的10个测试，有8个需要你大幅修改。

AI在提升其他框架的测试覆盖率，在Next.js这里，AI在浪费你的时间。

槽点七：Coding Agent 的"任务断裂"

最新的AI开发范式，是"自主编码Agent"——给AI一个需求，它会自动：

拆解任务
生成代码
运行测试
修复错误
提交代码

这种Agent在Next.js项目里，表现极差。

为什么？

因为Next.js的"环境跳跃"，导致Agent的"任务链"频繁断裂。

一个典型场景：

Agent任务：“给商品详情页添加一个’加入购物车’按钮。”

步骤1：Agent修改了app/product/[id]/page.tsx（Server Component），添加了一个按钮。
步骤2：但按钮需要useState来管理状态，所以Agent把这个按钮拆成了一个Client Component，加了'use client'。
步骤3：但Client Component不能直接用getServerSideProps获取数据，所以Agent改成useEffect获取。
步骤4：但useEffect获取需要API端点，所以Agent去app/api/cart/route.ts写了一个API。
步骤5：但API需要鉴权，所以Agent去改了中间件（Middleware）。
步骤6：改了中间件后，发现它影响了其他路由，Agent需要回溯修改…

Agent的"任务链"从"加一个按钮"分裂成：

Server Component修改
Client Component创建
API路由创建
中间件修改
回归测试

一个简单的需求，引发了5-6个文件的改动，跨越了3-4种代码环境。

Agent在不断的"环境切换"中，丢失了任务的"主目标"。它会频繁"卡住"，需要人工介入。

普通框架（纯Vite+React）： Agent加一个按钮 → 改一个文件 → 完成。

Next.js： Agent加一个按钮 → 改5个文件 → 失败 → 你手动收拾残局。

这哪里是"AI替我写代码"？分明是"AI给我制造了一堆新bug，我来修"。

槽点八：Vercel AI SDK——用AI"掩盖"问题的黑色幽默

Vercel自己也意识到了AI的重要性。他们推出了"Vercel AI SDK"，一个辅助开发AI应用的官方库。

但我读他们的文档时，看到了一个讽刺的现实：

“Vercel AI SDK is designed to work seamlessly with Next.js App Router, Server Components, and Server Actions.”

翻译：“我们的AI工具，专门优化了Next.js最复杂的那些特性。”

我理解他们想卖"AI+Next.js"的捆绑套餐。

但这里有一个黑色幽默：

Vercel在用一个"AI辅助库"，来帮助开发者跨越"Next.js自身复杂性"这座大山。

你用一个工具去对付另一个工具制造的麻烦——而麻烦本来就不该存在。

如果没有Server Components的复杂数据流，为什么需要AI来"优化"数据获取？
如果没有App Router的混乱路由，为什么需要AI来"辅助"路由管理？
如果没有SSR的"环境分裂"，为什么需要AI来"解析"哪个代码在哪跑？

Vercel AI SDK的存在，本质上就是一个"补丁"。

他们在用AI，来"弥补"Next.js在AI时代暴露的缺陷。

“新AI工具解决旧框架问题”——这个逻辑本身就是对框架的控诉。

总结：Next.js的"AI税"清单

最后，我们来列一张清晰的"AI税"清单。你在Next.js项目里每用一次AI工具，就要支付这些隐性成本：

税种	描述	成本等级
Token通胀税	上下文更大，对话轮次更多	⭐⭐⭐⭐⭐
版本考古税	AI的知识过时，你负责"版本校验"	⭐⭐⭐⭐⭐
Prompt膨胀税	每个需求都要写超长prompt来"防呆"	⭐⭐⭐⭐
代码平庸税	AI生成"安全但低效"的写法	⭐⭐⭐⭐
测试失效税	AI生成的测试大多没法用	⭐⭐⭐⭐
Agent断裂税	AI Agent频繁卡住，需要人工介入	⭐⭐⭐⭐⭐
工具失效税	Code Review、自动重构全部"打折"	⭐⭐⭐⭐