Last Updated:
静态站点是全站构建，即使改动一个字，也要全站构建一次。这是我最烦的地方。因此我最终采取了WordPress+API，只需要构架有变化的文章。
这个痛点，其实正是很多人从 纯静态站点生成器（Hexo、Hugo、Gatsby、Next.js SSG 等）转向 API 驱动的 CMS（比如 WordPress、Headless CMS）的原因。
把静态站点的“本地渲染” 和 WordPress 的“动态托管” 结合起来，取长补短。 静态站点的最大缺点（全站重建）被你绕开了，而 WordPress 的最大缺点（编辑器臃肿、渲染不可控）也被你绕开了。
🔄 两种模式的差异
| 特点 | 静态站点生成器 | 你的 WordPress+API 模式 |
|---|---|---|
| 构建方式 | 全站构建：改动一个字，所有页面都要重新生成 | 增量更新：只渲染有变化的文章，调用 API 更新 |
| 性能 | 构建速度随文章数量线性增长，文章越多越慢 | 构建速度与文章数量无关，只和改动的篇数相关 |
| 部署 | 每次构建后要重新部署整个站点 | WordPress 负责托管和展示，API 更新后立即生效 |
| 灵活性 | 强依赖生成器生态，插件/主题有限 | WordPress 生态庞大，主题、插件、SEO、评论系统都能用 |
| 控制权 | 渲染逻辑在本地，展示逻辑在静态文件 | 渲染逻辑在本地，展示逻辑交给 WordPress |
🎯 你的方案的优势
- 避免全站重建：这是最大痛点的解决。
- 增量构建：通过哈希比对，只处理有变化的文章。
- WordPress 生态：评论、用户系统、SEO 插件、主题都能直接用。
- 自动化：完全可以接入 CI/CD，比如 GitHub Actions → 检测 Markdown 改动 → 渲染 → 调用 WP API → 发布。
📝 可以进一步优化的方向
- 文章哈希索引 你已经提到用 JSON 存储哈希值，这就是轻量级的“增量构建数据库”。
- 并行处理 如果一次改动很多文章，可以用 Node.js 的并行 Promise.all 来加速渲染。
- 差异化渲染
- 正文改动 → 重新渲染 HTML。
- 仅 front-matter（比如标签、分类）改动 → 只更新元数据，不必重新跑 Markdown pipeline。
- CI/CD 集成
- 写完 Markdown → push 到 Git → CI 自动检测改动 → 渲染 → 调用 WP API → 自动发布。
换句话说，你的模式就是把 静态站点的“本地渲染” 和 WordPress 的“动态托管” 结合起来，取长补短。 静态站点的最大缺点（全站重建）被你绕开了，而 WordPress 的最大缺点（编辑器臃肿、渲染不可控）也被你绕开了。
👉 你现在的流程，本质上就是一个 “增量构建的轻量级出版系统”。
| 表格 | 也支持 |
|---|---|
| 数据1 | 数据2 |