静态站点生成SSG这个概念其实不算新Jekyll、Hugo这些老牌工具都玩了好多年了。但最近两年情况确实不一样了Next.js和Nuxt.js这两个全栈框架把SSG从“博客专用”拉回到了“正经项目也能用”的位置上。我在几个真实业务里测过这两套方案踩了不少坑也摸清了不少门道今天把这轮探索的过程和结论整理出来给正在选型的同学一个参考。如果你正在纠结这么几个问题站点需要极致的加载速度但又不想完全放弃动态能力、团队已经有React或Vue基础想直接上手、或者想在一套代码里同时搞定静态页面和接口逻辑那这篇文章正好对你有用。我会从框架设计思路讲起再分别给出两套框架的实际操作步骤和避坑经验。1. SSG为什么值得重新审视1.1 从“静态页”到“静态生成”的认知升级很多人对静态站点的印象还停留在“一堆HTML扔到服务器上”这没错但只是最基础的那一层。现代SSG的核心逻辑是在构建阶段把页面渲染成纯静态文件部署后完全不依赖Node服务请求进来直接返回现成的HTML。这也意味着首屏速度、SEO友好度、抗并发能力都天然占优而且托管成本低到可以忽略。但传统SSG有个致命短板——内容一变就得重新构建整个站点。一个上千篇文章的站点每次改个错别字都要全量rebuild体验非常糟糕。Next.js和Nuxt.js解决的核心问题其实就在这里它们把“静态生成”和“动态更新”之间的墙拆掉了。Next.js有ISR增量静态再生Nuxt.js有基于Nitro的混合渲染都能实现局部更新这在以前是没法想象的。我的理解是这两套框架不是来“取代”Hugo或Jekyll的而是把SSG从“写博客的工具”升级成了“建业务站的方案”。如果你的网站需要表单提交、登录态、个性化推荐这些交互纯静态方案会很吃力而这两套框架可以在需要的时候随时切到服务端渲染或客户端渲染这个灵活性是传统SSG给不了的。1.2 Next.js与Nuxt.js在SSG赛道上的位置先给个直观定位Next.js是React生态的默认选择Nuxt.js是Vue生态的事实标准。两者在做SSG这件事上的思路高度一致——都提供了构建时静态生成的能力也都允许页面级混合渲染。区别主要在使用习惯、生态工具链和部署形态上。我在实际测试中最大的感受是两者在SSG能力上其实打成了平手。真正影响选择的往往是你团队的框架基础。React背景的团队用Next.js基本零成本上手Vue背景的团队选Nuxt.js同样顺滑。硬要让一个写了三年Vue的人转React或者反过来学习成本远比框架本身的差异大得多。不过细看还是有一些值得注意的差异点。Next.js的国际化方案和图片优化组件非常成熟尤其next/image的自动WebP转换和尺寸适配做内容站能省不少事。Nuxt.js则胜在目录结构和约定式路由更直观它把pages/、layouts/、components/这些概念定得很清晰新手上手路径更平滑。2. 框架选型技术栈背后的取舍逻辑2.1 生态相关性选框架其实是选社区每次有人问我Next.js和Nuxt.js怎么选我第一反应永远是反问你们团队React和Vue哪个更熟这不是敷衍而是这个领域最真实的选型逻辑。SSG本身只是框架的一个能力维度你真正的日常工作是在这个框架上写业务代码生态的丰富程度直接决定开发效率。React生态的优势是组件库和工具链极其庞大无论是做营销页、文档站还是电商详情页总能找到直接能用的轮子。Next.js作为官方推荐的React框架在SSG场景下能无缝对接各种React生态资源。Vue生态相对小一圈但核心工具链反而更统一Vue Router、Pinia、Nuxt本身就是一个整体开发体验上的一致性很强。这里我要多说一句做SSG项目主题和模板的获取难度往往比技术选型更现实。很多团队没有专职前端需要买现成的主题快速上线。Next.js的主题市场明显更活跃质量也更高Nuxt的官方主题商店虽然存在但数量和更新频率都差一些。如果你是要快速交付给客户这一点请务必考虑进去。2.2 渲染策略差异不只是“静态”那么简单光说“静态生成”其实掩盖了很多细节。Next.js和Nuxt.js都支持页面级配置渲染模式这意味着同一个站点里有的页面可以构建时静态生成有的页面可以服务端渲染有的页面可以在客户端动态加载。关键区别在于各自的实现方式。Next.js的ISR是我个人最喜欢的功能。它允许你在构建时生成静态页面同时设置一个revalidate时间在这个时间窗口之后第一次访问会触发后台重新生成并更新静态文件。这让“静态”和“新鲜”不再对立。比如说博客的浏览量统计虽然可以用客户端JS做但ISR方案能让数字基本实时更新还保持静态页面的性能这个体验是很奇妙的。Nuxt.js这边则把重心放在了Nitro服务引擎上。Nuxt 3之后整个框架底层重写SSG输出已经不只是纯静态文件那么简单它把服务端逻辑也打包成了一个独立服务。这带来一个好处你在Nuxt里写的API路由在静态部署时也能以serverless函数的形式托管到Vercel或Netlify上。也就是说同一个项目既能出静态文件又能跑接口部署形态非常灵活。2.3 路由、数据获取与开发体验对比从开发者每天打交道最多的路由和数据获取来看两者存在明显风格差异。Next.js用的是文件系统路由app目录模式下还引入了布局、加载态、错误边界这些文件约定结构更复杂但表达力更强。Nuxt.js同样基于文件路由但加了layouts/目录做布局复用配合definePageMeta做页面级配置整体更符合Vue开发者习惯的“约定大于配置”的理念。数据获取是SSG项目的核心环节。Next.js在pages目录下用getStaticProps在app目录下用fetch配合缓存配置Nuxt.js则提供了useAsyncData和useFetch这两个组合式函数。我用过几次之后的感受是Nuxt.js的写法更贴近Vue的组合式API风格逻辑复用比较自然Next.js的route handler方式则更接近Web标准写过API的人不会陌生。开发体验上两家的热更新都很成熟。不过有个小细节值得注意Next.js 13之前用的是Webpack冷启动速度一般14之后默认切到Turbopack快了不少。Nuxt 3则直接用Vite做底层启动速度一直是他的一大优势尤其在大型项目上体感差距是很明显的。3. 实操Next.js搭建SSG站点的完整流程3.1 初始化项目与关键配置先说最常用的方式用create-next-app初始化。如果你的项目需要静态导出也就是纯SSG不依赖服务端能力命令是这样的npx create-next-applatest my-static-site --typescript --tailwind --eslint cd my-static-site这里有一步很容易被忽略静态导出需要改next.config.js里的输出模式。在Next.js 14版本中配置如下const nextConfig { output: export, images: { unoptimized: true, }, }; module.exports nextConfig;output: export意味着构建时只生成静态文件不再包含任何Node服务逻辑。这里有个大坑我得提前说静态导出模式下next/image组件默认的图片优化服务是不可用的因为那依赖服务端运行时。你必须把images.unoptimized设为true或者直接用普通img标签否则构建会直接报错。如果你不需要纯静态导出而是想用ISR方案那就简单很多不用设output: export只要按正常模式部署到Vercel或者自己的Node服务器就行。3.2 动态路由与增量静态再生SSG项目最典型的场景是内容型站点比如文档、博客、商品详情。这些页面结构相似但内容不同需要用到动态路由。在app目录下一个动态路由页面的布局通常是这样的// app/posts/[slug]/page.tsx export async function generateStaticParams() { const posts await getPosts(); return posts.map((post) ({ slug: post.slug, })); } export default async function PostPage({ params }: { params: { slug: string } }) { const post await getPost(params.slug); return article{post.title}/article; }generateStaticParams的作用就是告诉Next.js构建时要预先渲染哪些路径。比如博客有100篇文章这个函数返回100个slug对象构建时就会生成100个静态HTML。如果你的文章是随时更新的又不想每次手动重新构建ISR就是解决方案。在抓数据的fetch里配上next: { revalidate: 3600 }意思是每小时重新生成一次该页面。我在实际项目里的组合拳是构建时生成全部历史文章新发布的文章通过ISR在1小时内增量生成效果接近实时又保持静态性能。这里有个细节特别提醒generateStaticParams返回的只是“构建时渲染哪些页面”并不限制“访问哪些路径”。如果用户访问了一个没有预先生成的slugNext.js默认会尝试在请求时渲染。你要么提前把所有可能的路径都列出来要么就配合ISR让它“按需生成并缓存”这两种思路要想清楚再动手。3.3 部署要点与性能实测静态导出模式下构建产物就是一个out目录可以直接扔到任意静态托管平台。Netlify的配置大概是这样[build] command npm run build publish out如果你要用ISR那部署目标就得是支持函数计算的平台比如Vercel、Netlify或者自己的Docker容器。部署到Vercel最简单仓库一推自动识别Next.js项目什么都不用配。我在一个1000页左右的文档站上实测过静态导出模式下每页HTML体积平均在8~15KB配好CDN之后全球首屏基本都能压缩在1秒以内。同一个站点如果走Vercel的ISR方案首屏多出一个边缘网络查询时间但换来的是内容更新不需要重新构建。纯性能选静态导出内容新鲜度优先选ISR这个权衡要按业务场景来。4. 实操Nuxt.js搭建SSG站点的完整流程4.1 初始化项目与目录约定Nuxt 3的初始化同样很干净npx nuxilatest init my-nuxt-site cd my-nuxt-site npm install纯静态导出模式在nuxt.config.ts里配置export default defineNuxtConfig({ ssr: true, // SSG是SSR的构建时版本所以保持默认即可 nitro: { preset: static, }, });这里要解释一个容易让新人困惑的点Nuxt 3默认是SSR模式但这并不影响SSG。当你设置nitro.preset static时Nuxt会抓取你站点里的所有可路由页面在构建时把它们预渲染成HTML。默认情况下它只会预渲染首页。你需要告诉它哪些页面要预渲染这就要靠routeRules或者爬虫策略了。我常用的做法是开启nitro.prerender.crawlLinks让构建工具自动爬取页面里所有链接并生成对应页面。对于内容站来说特别方便export default defineNuxtConfig({ nitro: { preset: static, prerender: { crawlLinks: true, }, }, });爬取链接这个方案对“页面与页面之间有互相链接”的站点很好用但如果你有热爱文章却不被任何页面引用的“孤立页面”它就不会被预渲染。稳妥的做法是同时配置routes数组把重要路径手工补充进去。4.2 数据获取与使用体验Nuxt 3里做SSG数据获取推荐用useAsyncData配合useFetch。官方文档里的典型写法是这样script setup const { data: posts } await useFetch(/api/posts); /script template ul li v-forpost in posts{{ post.title }}/li /ul /template关键在于在SSG构建时这个useFetch会真实发生在构建进程里结果会被序列化到静态HTML中。也就是说你请求外部API拿到的数据会在构建时固化到页面上访问者拿到的已经是渲染好的成品。我踩过一个比较深的坑是序列化问题。useAsyncData默认要求返回的数据是可序列化的如果你从API拿到的对象里带了Date类型或者循环引用构建时就会报错或者状态异常。解决办法是给useAsyncData传第三个参数比如transform函数提前把数据规整成纯JSON结构。另外要提醒的是时机问题。如果你用onMounted去请求数据那在SSG场景下就太晚了因为构建时根本不会执行onMounted数据只能在客户端加载页面体验会退化成SPA模式。想走SSG一定要用await useFetch或者await useAsyncData这种构建期能执行到的方式。4.3 部署与新版本的变化静态部署时Nuxt 3构建出来的内容在.output/public目录一阵操作之后直接把这个目录推到任意静态托管就行。Netlify里配置发布目录为.output/public构建命令是npm run generate或npm run build。这里要替大家区分一下两个命令npm run generate生成静态站点npm run build则会在构建时把Nitro服务也打包出来适用于部署到支持Node运行时的平台。如果你的项目写了server/api接口静态托管只能管住静态页面接口逻辑还是需要一个函数计算平台才能跑。架构上想清楚这一点可以减少很多上线后的意外。Nuxt 3相对Nuxt 2有一个很大的变化是Nitro引擎它把Web服务器、路由、静态资源整合成了一个多功能运行时。这意味着在纯静态模式下你仍然可以写server/api它会被转成serverless函数部署到支持的平台上。所以Nuxt做出来的不只是“一个静态站”而是一个“默认全栈但可以裁剪成纯静态”的应用。这个设计思路我很喜欢它给了项目后期扩展很强的灵活性。5. 常见问题排查与避坑经验5.1 Next.js高频问题实录我在Next.js项目上遇到的第一类高频问题是环境变量泄露。Next.js会把NEXT_PUBLIC_前缀的变量打进客户端代码里但SSG构建时这些变量会固化在HTML里。如果你误把服务端密钥也用NEXT_PUBLIC_开头那构建产物里就藏着你的密钥团队都看得到。解决方式很机械服务端和客户端变量分开命名密钥只走后端接口服务。第二类高发问题是图片优化在静态导出下不可用。上文提过next/image在output: export下默认不工作。解决方案有三条关闭优化、改普通img、或者构建时用next/image的loader配置对接自建CDN服务。我个人建议图片不多的话直接关闭优化最省心图片量大再考虑自建CDN方案。第三类是动态路由参数为字符串。generateStaticParams返回的参数类型默认是字符串但如果你在代码里做了数字运算比如Number(params.id)忘写了就会出现NaN之类的问题。用TypeScript的话给params声明类型能提前兜住这些低级错误。5.2 Nuxt.js高频问题实录Nuxt 3这边我遇到过的最典型问题是预渲染路由遗漏。开着crawlLinks时构建日志里出现了为数不少的路由没被生成。排查后发现问题多数出在“通过JS跳转连接到新页面”的链接爬虫只认a标签。解决办法就是手动扩充nitro.prerender.routes或者干脆不用crawlLinks把所有路由写清楚。第二个坑是数据获取时外部API不可用。构建阶段抓取数据如果API超时或返回错误构建会直接失败。我在本地还好好的到CI里就挂后来发现是CI环境没法访问内网API。处理建议是给抓取逻辑加上fallback和超时控制必要的话在构建机上配置内网访问权限。第三个很小但很实际的坑是构建时window未定义。因为SSG在构建时运行的是Node环境没有window、document。如果你在顶层组件直接使用这些浏览器对象构建就会崩。解决办法是放到onMounted里用或者做客户端专属的判断。老手常用的process.client判断在Nuxt 3里依然好用但更推荐直接用onMounted语义更清晰。5.3 选型建议与团队落地指南把两轮实操放在一起比较之后我给自己总结了一套选型逻辑写出来给大家参考场景推荐理由团队熟React / 项目重度依赖React生态Next.js生态完整ISR成熟团队熟Vue / 快速开发中小型内容站Nuxt.js结构清晰Vite构建快纯营销页/文档站追求极致性能Next.js 静态导出output:export产物干净有API逻辑的内容站Nuxt.js Nitro一套代码兼顾静态页和接口大型电商/复杂动态业务不建议纯SSG混合渲染是底线别硬做静态需要强调一点SSG不是性能银弹。如果你要做个性化推荐、实时聊天这类强交互功能静态生成的核心价值就被稀释了。SSG真正适合的是内容相对稳定、以读为主、需要SEO的场景。做技术选型时先确认业务的“内容新鲜度需求”再下结论而不是听别人说“SSG快”就盲目上。落地的时候还有个小建议不管选哪个框架先用一个真实的小页面跑通从开发到部署的完整链路。很多人第一天就把几百个页面写出来了结果部署阶段才发现静态导出和ISR的方案选错了返工成本极高。花半天时间先跑通一条链路后面再加页面就很顺了。最后分享一个比较朴素的个人体感这些年我越来越倾向于把站点拆成“内容层”和“交互层”内容层尽量用SSG交付交互层再单独做客户端增强。Next.js和Nuxt.js都很好地支持了这种拆分区别只是实现语法不同。你不用纠结“最好的框架”你只要明确“我的内容多久变一次、我的用户在哪一层交互”答案就自然出来了。希望这篇探索笔记能给你省点试错的时间。