纯前端实现博客前后端分离：SSG、RSS与404难题全解析

博客内容该塞进源码吗？前后端耦合的痛点

对于很多用 Next.js、Hugo 这类框架搭建静态博客的开发者来说，一个绑不过去的问题是：文章内容和网站源码是否应该耦合在一起？

传统做法中，博客文章往往以 Markdown 文件的形式直接放在项目仓库里，随代码一起构建、一起部署。这带来一个显而易见的痛点——每次新增或修改一篇文章，都要触发整个前端的重新构建和部署。当文章量达到两三百篇时，这种「牵一发而动全身」的模式会变得异常笨重。

这里的「构建」指的是静态站点生成（SSG）过程。SSG 是现代前端框架（如 Next.js、Gatsby、Hugo）的核心构建策略之一——在构建阶段将所有页面预渲染为纯 HTML 文件，部署后无需服务器动态计算，直接由 CDN 分发静态文件。这带来了极致的加载速度和安全性，但代价是内容与构建过程紧密绑定。这与传统 CMS（如 WordPress）的「数据库驱动、按需渲染」模式形成鲜明对比——后者虽然性能稍逊，但内容更新完全独立于代码部署。

本文根据一位 B站UP主的实战分享整理，讲述了他如何用纯前端方案（即不改动服务端核心逻辑）实现博客的前后端彻底分离，并同步解决 RSS 订阅、评论区锚定、旧链接重定向等一系列连锁问题。

核心架构：前端做壳，Cloudflare Worker 做桥梁

分离方案的核心思想非常清晰：前端只是一个「壳子」，本身不存储真正的文章内容。

通过浏览器 F12 抓包可以验证，文章正文实际存储在后端（作者代号为「肉/row」的路径下）。而前后端之间的桥梁，是一个 Cloudflare Worker。

Cloudflare Worker架构示意

Cloudflare Worker 是一种基于 V8 引擎的边缘计算服务，运行在 Cloudflare 全球超过 300 个数据中心的边缘节点上。它允许开发者在用户请求到达源服务器之前，在离用户最近的节点上执行 JavaScript/TypeScript 代码。Worker 可以拦截和修改 HTTP 请求/响应、执行路由重写、生成动态内容，且冷启动时间通常在 5 毫秒以内。相比传统的 Lambda/云函数方案，Worker 的优势在于无需指定区域、全球就近响应，非常适合作为静态站点的「智能中间层」。

它的职责是：预构建文章索引。前端渲染文章列表时，实际上只需要一份文章索引（host.json），而不需要把全部正文打包进来。这份索引由 Cloudflare Worker 在预构建阶段生成，前端拿到索引后再去请求对应的正文。

这样一来，理论上后端更新了内容，前端抓取索引就能同步显示，无需重新部署。但这只是「看着解决了，并非完全解决」——真正的麻烦藏在后面几个连锁问题里。

RSS 订阅的三次曲折修复

原本以为最简单的 RSS 生成，反而成了整个过程中最折腾的环节。

RSS（Really Simple Syndication）是一种基于 XML 的内容分发协议，允许用户通过订阅器（如 Feedly、Inoreader 等）聚合获取网站更新，而无需逐一访问各站点。一个标准的 RSS 文件包含 channel（频道信息）和多个 item（文章条目），每个 item 通常包含 title、link、description、pubDate 等字段。订阅器会定期轮询 RSS 地址，对比已有条目发现新内容后推送给用户。在前后端分离的架构下，RSS 中 link 字段的准确性变得尤为关键——它决定了用户点击后跳转的目标页面，如果前后端路径不一致，订阅体验就会完全崩溃。

问题一：RSS 内容路径错误

作者的思路是在预构建阶段，让 Cloudflare Worker 顺便按规则生成一份 RSS。但生成后，订阅工具（follow）却提示找不到内容。原因在于生成的 RSS 默认指向了错误的路径。解决方法简单粗暴——把正确的 row 路径硬编码写进 RSS 里。

问题二：订阅路径不一致

第二个问题更微妙。用户订阅的 RSS 地址是 2x.z/rss.xml，而后端实际生成的却是 row-post.2x.z/rss.xml。两者对不上，订阅自然失效。

作者的解法是在 Worker 里写了一条路由规则，让访问 2x.z/rss.xml 时能正确命中到后端的 RSS 文件。同时，RSS 中的 link 字段虽然指向前端展示页，但内容由后端提供——用这种方式让第三方订阅器认为这是一个完整正常的文章，图片能正常加载，也不会跳转到后端裸链。

RSS路由规则配置

Next.js SSG 的 404 难题：静态站点生成的本质矛盾

RSS 解决后，一个更本质的矛盾浮出水面。

Next.js 在 SSG（静态站点生成） 模式下，要求每一个路径都对应一个预生成的 HTML 文件。比如 /post/micro-blog-servers 这个路径，必须存在对应的 .html 文件，否则直接 404。

这里需要理解 SSG 与其他渲染模式的本质区别：SSG 在构建时生成 HTML，SSR（Server-Side Rendering）在每次请求时由服务器动态生成 HTML，而 CSR（Client-Side Rendering）则完全由浏览器端 JavaScript 渲染页面。三者各有取舍——SSG 性能最优但灵活性最差，SSR 兼顾 SEO 和动态性但需要服务器资源，CSR 开发灵活但首屏加载慢且对搜索引擎不友好。这个本质矛盾正是 SSG 的先天局限：构建时路径已锁死，无法响应构建之后新增的内容。

之前为什么不出问题？因为前端构建时会拉取后端 JSON，看到有多少篇文章就生成多少条路由（比如 200 多条）。但一旦分离——后端新增文章而前端不重新部署，新文章的 HTML 就不存在，访问即 404。这恰恰又回到了「后端更新必须前端重新部署」的老路，与分离的初衷背道而驰。

作者列举了三种解决思路：

方案一：预构建（治标不治本）

即当前采用的方式，但缺点是后端更新后前端仍需部署一遍，等于没解决根本矛盾。

方案二：404 Fallback 做客户端渲染

利用 Cloudflare 的自定义 404 页面，把所有未生成 HTML 的路径都打到 404，再由这个页面做客户端解析——类似早期的「伪静态」思路。这本质上是将 SSG 退化为 CSR，类似于 SPA（Single Page Application）中使用 hash 路由或 history API fallback 的做法。

自定义404页面方案

但弊端很致命：现有文章是服务端渲染的，改成 SPA 客户端渲染需要大量重写代码，成本太高，最终放弃。此外，CSR 模式意味着搜索引擎爬虫可能无法正确索引页面内容（尽管 Googlebot 已支持 JavaScript 渲染，但延迟和可靠性仍存在问题），对已有的 SEO 排名会造成不可逆的伤害。

方案三：Query 查询参数路由（最终采用）

最终选择的是最优雅的方案——用查询参数（?slug=xxx）替代路径。这样只需保证 posts.html 一个文件存在，通过问号后的 slug 参数动态查询文章内容即可，彻底摆脱了「一篇文章一个 HTML」的束缚。

这个方案的巧妙之处在于：它只需要一个预构建的入口 HTML 文件，内部通过 JavaScript 读取 URL 中的查询参数，动态向后端请求对应文章的正文数据并渲染。从浏览器角度看，所有文章共享同一个 HTML「容器」，内容的差异化完全由客户端逻辑处理。

连锁反应：评论区锚定与旧链接重定向

方案三虽好，却又引出两个新问题，体现了系统改造中典型的「按下葫芦浮起瓢」。

Giscus 评论区锚定失效

博客使用 Giscus 作为评论系统，它默认通过 pathname（路径名）来锚定每篇文章的评论。一旦所有文章路径都变成统一的 posts，评论区就会全部「串号」。

Giscus 是基于 GitHub Discussions 的开源评论系统，它将博客评论映射为 GitHub 仓库中的 Discussion 帖子。锚定（mapping）机制决定了「哪篇文章对应哪个 Discussion」。Giscus 支持多种映射方式：pathname（按 URL 路径匹配）、URL（按完整 URL 匹配）、title（按页面标题匹配）、og:title（按 Open Graph 标题元标签匹配）、specific term（按自定义关键词匹配）等。Open Graph 协议是 Facebook 在 2010 年推出的元数据标准，通过在 HTML <head> 中添加特定的 <meta> 标签来定义页面的标题、描述、图片等结构化信息，广泛用于社交媒体分享预览。

作者的解法是：在 Giscus 配置中把锚定方式从 pathname 改为 og:title，并将 og:title 的值设为文章旧的路径形式。这样即便 URL 变了，每篇文章依然能通过唯一的 og:title 精准锚定各自的评论区。

旧链接 301 重定向

最后是保证老用户访问旧路径不失效。虽然可以用 Cloudflare Worker 或 Edge 服务端重定向，但由于博客部署在两个平台上，为了统一，作者选择了 Next.js 的重定向机制。

重定向方案选择

最精妙的一步是：把重定向逻辑放进 404.html。因为访问旧路径必然触发 404，此时 Cloudflare 返回自定义的 404 重定向页面，页面内的脚本判断是否为文章旧链接，若是则跳转到新的查询参数地址——整个流程一气呵成。这种做法利用了 Cloudflare Pages 的一个特性：当请求路径没有对应的静态文件时，会返回项目根目录下的 404.html，而这个 HTML 文件可以包含任意 JavaScript 逻辑，相当于获得了一个免费的「兜底路由层」。

总结：静态博客前后端分离的工程权衡

这套方案拆解开来，每一步都围绕一个核心目标：让内容更新与代码部署彻底解耦。

它给我们的启示是：

前后端分离在静态博客场景下同样成立，关键是找对内容与视图的边界；
Cloudflare Worker、自定义 404、查询参数路由等「边缘计算」手段，为纯前端方案提供了极大灵活性；
任何架构改动都会引发连锁反应（RSS、评论、SEO、旧链接），系统性思考比单点解决更重要。

需要注意的是，这套方案对 SEO 不太友好——查询参数形式的 URL 通常不如静态路径利于搜索引擎收录。搜索引擎通常将查询参数视为同一页面的不同「版本」而非独立页面，Google 的爬虫在处理带参数的 URL 时可能出现去重、忽略或延迟索引等行为。相比之下，/post/article-name 这样的「干净 URL」被搜索引擎视为独立、有意义的路径，有利于 PageRank 的分配和语义理解。这是为「解耦优雅」付出的代价，也是每位开发者在选型时需要自行权衡的取舍。

值得一提的是，业界也有其他解决此类问题的方案：Next.js 的 ISR（Incremental Static Regeneration，增量静态再生）允许在不重新构建整站的情况下更新单个页面；Headless CMS（如 Contentful、Strapi）通过 Webhook 触发按需构建；而 Astro 等新兴框架则提供了混合渲染模式，允许同一项目中部分页面 SSG、部分页面 SSR。本文介绍的纯 Worker 方案，更适合不想引入额外服务依赖、追求零成本运维的个人开发者。