AI帮我造博客（五）：前端选型——为什么是 Next.js？
📖 本文是「AI帮我造博客」系列第五篇。上一篇：AI帮我造博客（四）：后端选型——内容从哪里来？
TL;DR（30秒速览）
前端选型是博客搭建中最容易"选择困难"的环节。我在 AI 的帮助下，系统地梳理了渲染模式、主流框架、以及它们与 Strapi 的适配度，最终选择了 Next.js。
| 选型维度 | 我的选择 | 核心理由 |
|---|---|---|
| 界面库 | React | 生态最强，优秀组件库多 |
| 开发框架 | Next.js | 页面加载快，还能自动更新内容 |
| 渲染策略 | 增量静态生成 | 既有静态页面的速度，又有动态更新的能力 |
| 路由模式 | 新版路由 | 是未来趋势，值得踩坑 |
| AI 交互 | 结构化提示词 | 用约束换取精确方案，而非开放式问答 |
一句话总结：技术选型没有绝对的好坏，只有"适不适合"。对于内容驱动的博客，Next.js 的 ISR 是目前最完美的平衡点。
一、先搞懂问题：前端在整体架构中干什么？
上一篇我们选定了 Strapi 作为后端。它专注于内容管理，通过 API 提供数据。
那前端需要做什么？其实就三件事：
- 数据获取：通过 HTTP 请求从 Strapi API 拿到文章、分类、标签等数据
- 内容渲染：把数据变成用户能看到的 HTML 页面
- 用户交互：处理搜索、评论、导航等交互功能
听起来简单？问题在于"内容渲染"这一步有很多种方式——这就是让我头疼的地方。
在选择前端框架之前，必须先理解渲染模式——这是影响博客性能、SEO（即搜索引擎优化，让你的文章能被百度、Google 搜到）和用户体验的关键因素。
二、渲染模式：现代 Web 的四种核心策略
我被 Next.js 文档里的一堆缩写搞晕了：SSR、SSG、ISR、CSR... 这些到底是什么意思？
别慌，接下来我用"餐厅"的比喻来解释这四种渲染模式。看完你会发现，其实没那么复杂。
2.1 CSR（客户端渲染）= 自助火锅
工作原理：
用户访问 → 服务器返回一个空盘子（空 HTML）→ 浏览器拿食材（下载 JS）→ 自己动手涮（渲染页面）服务器只给你一个基本的 HTML 骨架和一堆 JavaScript 文件。所有的"烹饪"工作都在用户的浏览器里完成。
这种方式的问题：
- 用户进门先看到空盘子（首屏加载慢）
- 搜索引擎爬虫看不懂 JavaScript，只能看到空盘子（SEO，即搜索引擎优化困难）
- 手机性能差的用户吃不上饭（依赖设备性能）
适合场景：后台管理系统、数据仪表盘——这些不需要被搜索引擎收录的应用。
结论：博客需要 SEO，CSR 直接出局。
2.2 SSR（服务端渲染）= 现炒现卖
工作原理：
用户点单（访问页面）→ 厨师（服务器）现场炒菜（生成 HTML）→ 上菜（返回完整页面）每次有用户访问，服务器都会实时渲染一个完整的 HTML 页面。用户和搜索引擎都能直接看到内容。
优点：
- 菜永远是热的（数据实时最新）
- 顾客一坐下就有菜看（首屏快）
- 外卖评价员（搜索引擎）能看到完整菜品（SEO 友好）
缺点：
- 厨师累死（服务器压力大）
- 高峰期容易翻车（并发能力受限）
- 厨房要一直开着（服务器成本高）
适合场景：需要实时数据、个性化内容的应用，比如社交媒体信息流。
2.3 SSG（静态站点生成）= 预制菜
工作原理：
早上（构建时）→ 厨师把所有菜都炒好（生成静态 HTML）→ 放进保温柜（部署到 CDN，即内容分发网络，相当于在全球各地都放了保温柜）
用户点单 → 直接拿走在部署之前，就把所有页面都渲染好了。用户访问时，直接返回静态文件，不需要任何计算。
优点：
- 出餐速度极快（毫秒级响应）
- 可以放到全球各地的保温柜（CDN 加速）
- 几乎不用厨房（服务器成本极低）
- SEO 完美
缺点：
- 不管早上还是晚上，吃到的都是早上的味道（内容不更新）
- 如果菜单有 1000 道菜，早上要炒很久（构建时间长）
- 改一道菜，整个菜单都要重新炒一遍
适合场景：内容固定、更新不频繁的网站，比如文档站、落地页。
2.4 ISR（增量静态再生）= 预制菜 + 定时补货
这是 Next.js 的杀手锏，也是我最终选择的方案。
工作原理：
早上 → 先做好一批预制菜（生成静态页面）
用户点单 → 直接上菜（返回缓存版本）
同时后台检查 → 这道菜做了多久了？
如果超过保鲜期 → 后台悄悄重新做一份（后台重新生成）
下一位顾客 → 吃到新鲜的核心理念：用户永远能快速拿到菜（缓存响应），但菜会在后台自动保持新鲜（按需更新）。
优点：
- 接近 SSG 的速度
- 内容可以自动更新
- 不需要每次修改都重新构建整个站点
- 构建时间不随页面数量线性增长
缺点：
- 配置相对复杂
- 内容更新有一定延迟（最长等于过期时间）
进阶技巧：分档 ISR
实际使用中，不同类型的页面可以设置不同的"保鲜期"：
| 页面类型 | 刷新周期 | 理由 |
|---|---|---|
| 首页/列表 | 15 分钟 | 新文章需要较快出现 |
| 分类/标签 | 1 小时 | 变化不频繁 |
| 文章详情 | 24 小时 | 内容稳定，偶尔改错别字 |
更进一步：On-Demand ISR（按需刷新）
如果等不及"保鲜期"怎么办？Next.js 还支持"主动刷新"——当后端内容更新时，通过 Webhook（一种自动通知机制，就像厨房做好菜后按铃通知传菜员一样）通知前端立即刷新特定页面。这样既保留了静态页面的速度，又能做到"发布即生效"。
我的决策：采用分档 ISR 作为基础策略，后续再实现 On-Demand ISR 进一步优化。
2.5 渲染模式对比一览
| 维度 | CSR | SSR | SSG | ISR |
|---|---|---|---|---|
| 首屏速度 | 慢 | 快 | 最快 | 最快 |
| SEO | 差 | 优 | 最优 | 最优 |
| 内容实时性 | 实时 | 实时 | 构建时 | 准实时 |
| 服务器负担 | 极轻 | 重 | 极轻 | 轻 |
| 构建时间 | 短 | 无 | 长 | 中等 |
| 托管成本 | 低 | 高 | 最低 | 中 |
博客的最佳策略：
- 文章页：ISR（兼顾速度和更新）
- 首页/列表页：ISR 或 SSG
- 搜索功能：CSR（纯交互，不需要 SEO）
洞察：当技术文档像天书时，让 AI 用你能理解的比喻来解释。理解了原理，选型就不再是"盲选"。
三、前端框架生态：有哪些选择？
搞懂渲染模式后，接下来要选具体的框架了。
现代前端开发有两层结构，可以类比成"食材"和"厨房"的关系：
- UI 库（食材）：React、Vue、Svelte —— 负责构建界面组件，是基础原料
- 元框架（厨房）：Next.js、Nuxt、Astro —— 在 UI 库之上，提供路由、数据获取、渲染策略等完整解决方案，是把食材变成菜品的流水线
下面我让 AI 帮我逐个梳理这些主流元框架：
3.1 Next.js —— React 生态的标准答案
定位：混合渲染全栈 React 框架
核心特点：
- 支持所有渲染模式（SSG、SSR、ISR、CSR），可按页面级别自由选择
- 文件系统路由：
pages/blog/[id].js自动成为/blog/123的路由 - 内置图片优化、代码分割、TypeScript 支持
- App Router（新版路由系统）支持 React Server Components（RSC，服务端组件，让部分代码在服务器运行，减少浏览器负担）
生态优势：
- GitHub 130k+ Stars，npm 周下载 6M+
- 企业级验证：Netflix、GitHub、Notion 都在用
- Strapi 官方示例首选，集成教程最多
- shadcn/ui、Radix 等优秀组件库 React 优先
劣势：
- 学习曲线较陡（尤其是 App Router）
- 部分功能与 Vercel 平台绑定较深（但可以用 Docker 容器化自部署，Docker 就像一个"标准集装箱"，把应用打包好随处运行）
3.2 Astro —— 内容网站的性能之王
定位：零 JavaScript 的内容优先框架
核心特点：
- 默认输出纯静态 HTML，不发送任何 JavaScript
- 部分水合（Partial Hydration）：只有需要交互的组件才发送 JS
💡 "水合"是什么？静态 HTML 就像一具"雕塑"，好看但不能动。"水合"就是给雕塑注入灵魂（加载 JS），让它能响应点击、滚动等操作。"部分水合"意味着只给需要动的部分注入灵魂，其他保持静态。
- 框架无关：同一项目可混用 React、Vue、Svelte 组件
性能优势：
- Lighthouse 性能分：99/100（因为客户端几乎零 JS）
- 构建时间快（小规模项目）
劣势：
- 默认全静态，动态功能需额外配置
- 没有内置 ISR 支持
- 生态相对较新（2021 年发布）
适合场景：90% 静态内容、10% 交互的内容网站。
3.3 Nuxt —— Vue 生态的 Next.js
定位：Vue 开发者的全栈解决方案
核心特点：
- 支持 SSR、SSG、ISR（称为 Hybrid Rendering）
- 自动导入：组件、组合函数无需手动 import
- Vue 3 的 Composition API（组合式 API，让代码组织更灵活）和响应式系统
优势：
- Vue 生态最佳方案
- 中文社区强大，学习资源丰富
- 渐进式学习曲线
劣势：
- 生态不如 React/Next.js 丰富
- 企业级案例相对较少
3.4 Remix —— 现代 Web 标准的布道者
定位：渐进增强的服务器优先框架
核心特点：
- 每次请求都 SSR，通过 HTTP 缓存获得静态速度
- 基于 Web 标准（使用浏览器原生的数据获取方式，不造私有轮子）
- 渐进增强：即使 JavaScript 失败也能工作
优势：
- 动态内容性能优秀
- 无构建时间（与数据解耦）
- 架构优雅
劣势：
- 无内置 SSG/ISR
- 生态相对较新（2021 年开源）
- 服务器成本比纯静态高
3.5 框架对比一览
| 框架 | 渲染模式 | 学习曲线 | 生态成熟度 | 博客适配度 |
|---|---|---|---|---|
| Next.js | 全支持 | 中高 | ⭐⭐⭐⭐⭐ | ⭐⭐⭐⭐⭐ |
| Astro | SSG 为主 | 低 | ⭐⭐⭐ | ⭐⭐⭐⭐ |
| Nuxt | 全支持 | 中 | ⭐⭐⭐⭐ | ⭐⭐⭐⭐ |
| Remix | SSR 为主 | 中高 | ⭐⭐⭐ | ⭐⭐⭐ |
四、我的选型决策过程
梳理完生态后，我让 AI 帮我做一个适合我的决策分析。
4.1 我的需求画像
面对 Next.js、Remix 这些神仙打架的框架，我没有直接拍脑袋。我决定让 AI 扮演架构师，基于我的实际约束给出建议。
为了避免 AI 给出“Next.js 和 Remix 都不错”这种模棱两可的废话，我必须把我的三个核心痛点明确告诉它：
- SEO 是生死线：必须被 Bing 和 Google 收录，首屏要快。
- 后端已锁死：必须配合 Strapi 自托管，不能依赖 Vercel 的 Serverless。
- 不想折腾基建：我是后端思维，不想在 Webpack 配置上浪费生命。
基于这些约束，我编写了如下 Prompt（提示词）：
科普：什么是 Prompt？
简单说，Prompt 就是你发给 AI 的指令。就像你需要给员工下达清晰的需求单一样，你给 AI 的指令越精准、背景信息越全，它干出来的活就越漂亮。如果你只扔给它一句"帮我选个框架"，它大概率会回给你一篇正确的废话。
下面是我为了这次选型，专门打磨的一个结构化 Prompt：
Prompt 示例：
"作为一名资深全栈架构师，请协助我进行博客项目的前端技术栈选型。
项目背景：
- 核心需求：构建一个面向技术读者的个人博客，既要极致的 SEO（First Contentful Paint < 1.0s），又要具备现代 Web App 的流畅体验（如路由无刷新跳转）。
- 数据特征：预计 100-500 篇文章，每周更新 1-3 篇，偶尔需要修改旧文（需要考虑缓存失效问题）。
- 后端环境：已确定使用 Strapi + Postgres 自托管方案，提供 REST API。
- 团队配置：我是一名偏后端工程师，熟悉 React 基础，但不想在 Webpack/Vite 配置上花费太多精力。
- 交互需求：必须包含全站搜索、TOC 目录导航和评论系统。
请对比 React 生态下的主流方案（Next.js / Remix / Vite+React），并重点回答：
- 针对我的 SEO 和性能需求，哪种渲染模式（SSR/SSG/ISR）最合适？
- 考虑到 Strapi 后端，哪个框架的数据获取（Data Fetching）集成更优雅？
- 请给出一个明确的推荐结论，并以此结论列举 3 个最大的潜在坑点。"
4.2 为什么这个 Prompt 有效？（AI 交互复盘）
这也是我想分享的一个重要技巧。如果只问 "哪个前端框架最好？"，AI 只会像文档复读机。上面这个 Prompt 之所以能得到高质量建议，是因为它严格遵循了 Persona (角色) + Context (上下文) + Task (任务) + Output (输出要求) 的"提问公式"。
我总结了其中的四个设计巧思，你可以直接复用到其他技术决策场景中：
-
设定专家人设 (Persona Setting)
"作为一名资深全栈架构师..."
作用：拉高 AI 的回答水位。如果不加这句，AI 可能会平铺直叙；加了这句，AI 就会开始思考权衡（Trade-off），比如成本、维护难度、生态兼容性等架构师才考虑的问题。 -
前置"硬约束" (Context & Constraints)
我没有只说 "我要写博客"，而是把边界条件卡得很死：- 性能指标化：
SEO+First Contentful Paint < 1.0s，这直接排除了纯 SPA 方案。 - 资源具象化：
偏后端工程师+不想折腾 Webpack，这暗示 AI 不要推荐过于底层、需要大量魔改配置的方案，要推荐开箱即用的框架。
- 性能指标化：
-
限制竞品范围 (Scope Limiting)
"请对比 React 生态下的主流方案..."
作用：防止 AI 发散。圈定 React 生态能保证建议的落地可行性，避免它给你推荐虽然好用但你完全不熟悉的技术栈（比如 Go 或者 Rust 的前端框架）。 -
强制"反向思考" (Negative Tactic)
"请给出一个明确的推荐结论，并以此结论列举 3 个最大的潜在坑点。"
作用：这是最高明的一手。大多数 AI 倾向于说好话（讨好人类）。强制它列出**"坑点"**，不仅能验证这个方案是否真的适合你，还能帮你提前做好心理准备（比如 Next.js 的 App Router 学习曲线确实陡峭）。
一句话经验：你给出的约束（Context）越具体，AI 帮你做的决策产生的价值就越高。
4.3 排除法：先划掉不合适的
Astro：
- 优点：性能极致，简单直观
- 问题：没有内置 ISR，内容更新需要重新构建部署
- 结论：如果我的博客只是静态展示，Astro 是首选。但我希望改个错别字不用触发整个部署流程，暂时排除。
Remix：
- 优点：架构优雅，动态性能好
- 问题：每次请求都走服务器，成本比静态高；生态较新
- 结论：作为新手，我需要更多社区资源和教程，暂时排除。
Nuxt：
- 优点：Vue 上手更快，中文资源好
- 问题：很多我眼馋的 UI 组件库（比如 shadcn/ui）是 React 优先
- 结论：如果不是为了 UI 生态，Nuxt 其实是很好的选择，惜败。
4.4 最终选择：Next.js
Next.js 胜出的理由：
-
ISR 完美适配博客场景
- 文章发布后静态化，访问速度快
- 修改错别字后，1 小时内自动更新
- 不需要手动触发重新部署
-
生态最强，资源最多
- 遇到问题最容易找到答案
- Strapi 官方集成示例
- shadcn/ui 等优秀组件库
-
未来可扩展
- App Router 支持 React Server Components
- 可以逐步添加复杂功能（用户系统、Newsletter 等）
4.5 关于 App Router 的决定
Next.js 有两套路由系统：
- Pages Router：经典方案，稳定成熟
- App Router：新方案，支持 React Server Components
App Router 的坑确实很多。举个最典型的例子让你感受一下：很多旧的第三方库一用就报错 window is not defined。
我问 AI 为什么会这样，AI 解释说：
"Server Component 在服务器运行，没有浏览器里的 window 对象。你需要在组件文件顶部加
'use client'指令，把它标记为客户端组件。"
这个 'use client' 就像是一张"特许通行证"，告诉 Next.js："这一小块代码，请按老规矩在浏览器里跑，不要在服务器上瞎折腾。"
我的决策：虽然坑多，但 RSC 是 React 的未来。做新项目，肯定要选未来的技术栈。踩坑的过程也是学习的过程。
五、技术决策的一般规律
回顾整个选型过程，我总结了几条规律：
5.1 按项目类型选择
| 内容更新频率 | 推荐方案 | 核心特征 |
|---|---|---|
| 低（周/月更） | Astro | 极致性能 |
| 中等（日更+偶尔修改） | Next.js ISR | 性能与动态平衡 |
| 高（实时/个性化） | Remix SSR 或 Next.js SSR | 实时交互优先 |
5.2 按团队背景选择
| 团队情况 | 推荐方案 | 理由 |
|---|---|---|
| 前端新手 | Astro | 语法简单，概念少 |
| React 熟练 | Next.js | 充分利用生态 |
| Vue 背景 | Nuxt | 无缝过渡 |
| 追求前沿 | Remix | 学习现代 Web 标准 |
5.3 按成本和部署方式考量
| 方案 | 托管成本 | 说明 |
|---|---|---|
| Astro SSG | 最低 | 纯静态托管，CDN 即可 |
| Next.js ISR (Vercel) | 低 | 平台托管，零配置 |
| Next.js ISR (Docker) | 中 | 自建服务器，完全可控 |
| Next.js SSR | 中高 | 需要持续的服务器资源 |
关于部署方式的选择：
- Vercel 等平台托管：零配置、自动扩容，适合快速上线
- Docker 容器化部署：环境隔离、版本可控、易回滚，适合自建基础设施
六、小结
前端选型这一步，我通过 AI 的帮助，建立了系统的知识框架：
- 理解渲染模式：CSR、SSR、SSG、ISR 各有适用场景
- 了解框架生态：Next.js、Astro、Nuxt、Remix 各有所长
- 匹配自身需求：博客场景 + React 生态 → Next.js ISR
最终选型：
- 框架：Next.js 14（App Router）
- 渲染策略：分档 ISR（首页 15min，分类 1h，详情 24h）
- 部署方式：Docker 容器化（自建镜像仓库，完全可控）
- 未来优化：On-Demand ISR（发布即生效）
如果你是新手，这些概念可能听起来还有点晕。没关系，只要记住一点：
Next.js 帮我们搞定了最难的"做饭"（渲染）环节，我们需要做的，只是把"食材"（内容）准备好。
下一篇，我们不再纸上谈兵，直接开始动手写代码——从设计和实现一个高颜值的首页开始。
航海日志
| 本次航线 | 遇到的暗礁 | 带回的货物 | 下一站 |
|---|---|---|---|
| 前端选型 | 被渲染模式概念绕晕 | 系统的技术选型方法论 | 首页设计与实现 |
📚 AI帮我造博客系列导航
上一篇：AI帮我造博客（四）：后端选型——内容从哪里来？
下一篇：AI帮我造博客（六）：零设计基础做首页——从蒙眼指挥到截图驱动的三轮进化