把动态博客彻底静态化，零成本部署到 Cloudflare Pages

动态 CMS（比如 WordPress）的每一次访问都要经过 PHP 和数据库。流量一大，或者遇到 CC 攻击，CPU 先被耗尽；程序和插件的漏洞，又给了攻击者更多下手的机会。最近一次站点被攻击到服务器 IP 被黑洞、SSH 都连不上，我索性换了思路：把内容生产和对外展示彻底拆开，对外只提供静态文件。

下面是这套“静态化 + Cloudflare Pages”方案的完整复盘。

为什么选择纯静态

攻击面小：没有数据库、没有服务端脚本，对外只有 HTML、CSS、JS 和图片，常见的注入和提权手段无处发力。
速度快：页面直接由 CDN 边缘节点返回，首字节时间很短，也不用担心高并发把源机器压垮。
运维轻：不用再管 PHP 版本、数据库备份和插件升级，托管平台负责可用性。
成本低：Cloudflare Pages 提供免费额度，个人站点通常足够。

整体架构

编辑者 ──> 私有的 WordPress（仅白名单可访问）
                 │  静态导出
                 ▼
          静态文件 / ZIP
                 │  上传或 CI 推送
                 ▼
        Cloudflare Pages ──> 访客

核心思想是：WordPress 只负责写文章，不再面向公网，访客看到的永远是导出后的静态结果。

第一步：准备一个“只给自己用”的内容源站

准备一台 2 核 4G 左右的服务器，安装宝塔（aaPanel）等面板，用一个不对外宣传的二级域名搭起 WordPress。
在 Nginx 或云安全组中只放行你自己的 IP访问后台和站点。
之后照常写文章、排版，甚至可以借助 AI 工具辅助创作。

这台机器配置不用高，因为它基本没有公网访问压力。

第二步：用插件导出全站静态文件

在源站安装 Simply Static 或 WP2Static，以 Simply Static 为例：

后台安装并启用插件；
将 Delivery Method（交付方式） 设为 Local Directory 或 ZIP Archive；
把目标地址（Destination URL）设为你正式对外的域名，这样导出的链接才是正确的；
点击 Generate Static Files，插件会爬取全站链接，把文章页、图片、CSS、JS 打包成纯静态结构。

注意：评论、搜索、会员、表单等需要服务端处理的功能在静态站上会失效。评论可以换成 Waline、Twikoo、Giscus 之类的第三方前端方案，搜索可以用 Pagefind 等纯前端索引替代。

第三步：部署到 Cloudflare Pages

登录 Cloudflare 控制台，进入 Workers & Pages；
选择 创建应用程序 → Pages → 上传资产（Upload assets）；
填写项目名，把导出的目录或 ZIP 拖进去；
等待几十秒，会得到一个免费的 *.pages.dev 地址；
在 Custom domains 中绑定正式域名。

进阶：让发布流程自动化

每次发文都手动“导出 + 上传”会很烦。可以把链路串起来：

文章发布 → Webhook 触发 → 自动化工具（如 n8n）执行静态导出 → 调用 Cloudflare API 或 Git 推送 → Pages 自动构建部署

走到这一步就能实现“写完即上线”的无人值守。

如果你本来就没有历史包袱，也完全可以放弃 WordPress，直接使用 Nuxt、Astro、Hugo 等静态站点生成器，用 Markdown 写文章、Git 管理内容，部署方式同样是推送到 Pages。

常见问题

免费版有流量限制吗？ 静态资源请求目前没有明显的流量上限，但单个部署有文件数量和单文件体积的限制，具体数值以 Cloudflare 官方文档为准。个人博客一般不会碰到。

不想额外买服务器，可以吗？ 可以。直接在本机搭 WordPress（或用 Docker），本地导出后上传即可。

必须用 WordPress 吗？ 不必须。任何能产出静态 HTML 的工具都行，选择取决于你的内容类型和使用习惯。

这套方案最大的缺点是什么？没有服务端交互能力。 会员、付费阅读、原生评论等都做不了，需要这些功能的站点不适合纯静态化。

访问速度如何？ Cloudflare 在海外表现很好；如果你的主要读者在中国大陆，需要评估线路，必要时选用对大陆更友好的 CDN 或托管方案。

小结

静态化的本质是用构建时的计算换取运行时的安全与速度。只要你的站点以阅读为主，把内容源站藏在后面、对外只托管静态文件，就能同时得到更低的成本和更强的抗压能力。