本文约 4,109 字，预计阅读 11 分钟。文中命令与配置均经过实测，可直接参考执行。
引言：动态站的两个永恒问题
WordPress 是动态的：每次访问都要跑 PHP、查数据库。这带来两个问题：
- 性能：即使优化到位，也比纯静态文件慢；
- 安全：有 PHP 和数据库，就有被攻击的面。
有些站点其实根本不需要动态——企业官网、文档站、作品集、博客，内容几周一更新，没有登录、没有交互。这种站点静态化是最优解：
- 速度：CDN 直接返回 HTML，TTFB < 50ms；
- 安全：没有 PHP 执行环境，攻击者无从下手；
- 成本：可托管到 GitHub Pages、对象存储、Netlify，几乎不花钱；
- 稳定：不怕流量峰值，不怕数据库挂。
原理分析：静态化做了什么
静态化插件的工作原理：
- 爬虫式遍历站点所有 URL（首页、文章、分类、标签、分页）；
- 对每个 URL 发起请求，拿到渲染后的 HTML；
- 把 HTML 和 CSS/JS/图片保存到本地目录；
- 输出一个完整的可部署静态站点。
关键理解：静态化不是”缓存”，是一次性生成快照。生成后站点就是一堆文件，和 WordPress 本身无关了。
静态化后会失效的功能：
| 功能 | 静态化后 | 替代方案 |
|---|---|---|
| WordPress 搜索 | ❌ 失效 | Algolia、Google 自定义搜索、前端 JS 搜索（Fuse.js） |
| 评论 | ❌ 失效 | Disqus、Giscus、Waline |
| 表单 | ❌ 失效 | Formspree、Getform、腾讯问卷 |
| 阅读量计数 | ❌ 失效 | 不计数或第三方统计 |
| 登录/会员 | ❌ 不可行 | 静态化不适合 |
| 电商 | ❌ 不可行 | 静态化不适合 |
| sitemap / RSS | ✅ 可生成 | 插件会一并生成 |
判断标准一句话：有”用户输入并被服务器处理”的功能，就不适合静态化。
保姆级实操
方案一：Simply Static（免费，最流行）
「Simply Static – Generate」设置：
Delivery Method: Local Directory
Local Directory: /var/www/static-output
「Include/Exclude」里检查要包含：
https://mimangfei.com/
https://mimangfei.com/sitemap.xml
https://mimangfei.com/feed/
https://mimangfei.com/wp-content/uploads/
生成后检查：
ls -la /var/www/static-output
# index.html, 2025/03/some-post/index.html, wp-content/...
技巧：生成前把固定链接设为 /%postname%/；用 “Additional URLs” 补上爬虫没发现的路径。
方案二：WP2Static（功能更强，支持多目标）
支持直接部署到 GitHub Pages、Netlify、AWS S3 + CloudFront、阿里云 OSS、腾讯云 COS、FTP/SFTP。
S3 配置示例：
Deployment Method: S3
Bucket: mimangfei-static
Region: us-east-1
Access Key ID: ****
Secret Access Key: ****
CloudFront Distribution ID: E123456（自动刷新用）
方案三：区分”伪静态化”
注意：WP Super Cache、WP Rocket 的”预加载”也生成 HTML 文件，但仍依赖 WordPress 运行环境（PHP 和数据库还在）。这不是真正的静态化，安全和性能收益有限。
真正的静态化是 WordPress 与静态站分离：WordPress 装在内网/不对外暴露的域名上做 CMS，静态站部署在公网。
方案四：Jamstack（headless）
- Faust.js（WP Engine 的 Next.js 框架）
- Next.js + WordPress REST API
- Astro + WordPress
- Gatsby + WordPress
WordPress 只做后台内容管理，前端用 JS 框架渲染，构建时生成静态文件。适合有开发能力的团队。（Frontity 已停止维护，不推荐新项目。）
部署静态站
对象存储（阿里云 OSS）：
# 控制台：Bucket → 基础设置 → 静态页面，首页 index.html，404 页 404.html
ossutil cp -r /var/www/static-output/ oss://mimangfei-static/ --update
Netlify：
npm install -g netlify-cli
netlify deploy --dir=/var/www/static-output --prod
Nginx（最简单）：
server {
listen 80;
server_name mimangfei.com;
root /var/www/static-output;
index index.html;
location / {
try_files $uri $uri/ $uri/index.html /404.html;
}
location ~* \.(css|js|png|jpg|webp|woff2)$ {
expires 365d;
add_header Cache-Control "public, immutable";
}
}
注意：静态化后 URL 通常是 /some-post/（带斜杠），try_files 要写 $uri $uri/ $uri/index.html，否则 404。
自动化：内容更新后重新生成
// 在 WordPress（内网）上加钩子触发构建
add_action( 'publish_post', function( $post_id ) {
wp_remote_post( 'https://你的构建服务/webhook/rebuild', array(
'timeout' => 5,
'blocking' => false,
'body' => json_encode( array( 'post_id' => $post_id ) ),
) );
} );
或用 GitHub Actions 定时触发：
name: Rebuild Static Site
on:
schedule:
- cron: '0 3 * * *'
workflow_dispatch:
jobs:
build:
runs-on: ubuntu-latest
steps:
- name: Trigger WP2Static
run: curl -X POST "${{ secrets.WP_URL }}/wp-json/wp2static/v1/generate"
- name: Deploy
run: |
aws s3 sync ./static-output s3://mimangfei-static --delete
aws cloudfront create-invalidation --distribution-id E123 --paths "/*"
常见踩坑
- 生成不完整：有些 URL 没被爬虫发现。生成后对比：
bash
grep -c "<loc>" /var/www/static-output/sitemap.xml
find /var/www/static-output -name "index.html" | wc -l
- 绝对路径问题：生成的 HTML 里是绝对 URL，部署到别的域名会失效。生成时域名要和部署域名一致。
- 案例：某企业站静态化后联系表单失效，客户投诉三天后才发现。教训：静态化前先列出所有动态功能并逐一确认替代方案。表单可用 Formspree：
“`html
“`
- 404 页面：必须配置文件，否则返回默认丑陋页面，影响体验和 SEO。
- 中文文件名/路径：生成后抽查几个中文 URL 的编码。
- 图片体积：静态化会复制所有图片和缩略图。可先把媒体库搬到对象存储（见WordPress 媒体库迁移到对象存储）再静态化。
- 生成超时：页面多（几千个）时 PHP 会超时。调大
max_execution_time、分批生成。 - 忘了保留 WordPress 本体：静态化后 WordPress（含数据库）必须保留，否则没法继续发布内容，且应部署在不对外暴露的地方。
总结
静态化适合：企业官网、文档站、个人博客、作品集、落地页——内容更新频率低、无交互、追求速度与安全。不适合：有登录会员、电商、论坛、需要站内搜索的站点。落地推荐：Simply Static 或 WP2Static，WordPress 部署在内网做 CMS，静态站部署到对象存储 + CDN 或 Netlify/GitHub Pages，配 CI 自动重新生成。上线前必须逐项确认动态功能的替代方案（搜索、评论、表单）。如果只是想提速不想改架构，Nginx FastCGI 缓存配置是更低成本的选择，两者可配合。
