核心用法
wp-to-static 是一款专为 WordPress 站点静态化迁移设计的自动化工具。用户需提供 SSH 连接信息（主机、端口、用户名、密钥路径）和目标站点 URL，工具即可在远程服务器执行 wget --mirror 抓取渲染后的 HTML，通过 rsync 同步静态资源至本地，经多轮处理后部署至 Cloudflare Pages。
完整流程包含十个严格阶段：环境验证 → SSH 连通性测试 → 定位 WordPress 安装目录 → 服务器端镜像抓取 → 安全 rsync 同步（排除所有 PHP/配置文件）→ 智能资源提取（仅保留 HTML/CSS 实际引用的文件）→ URL 修复与字体自托管 → WordPress 特征清理 → 本地验证 → 安全部署。关键创新在于第 5 步的资源提取算法，通过解析 HTML 的 src//href//srcset 属性和 CSS 的 url()() 引用，将典型 1.5GB+ 的 WordPress 站点精简至约 25MB。
显著优点
极致性能提升：静态站点消除 PHP 运行时和数据库查询，配合 Cloudflare 全球 CDN，实现毫秒级首字节响应。
零攻击面：移除所有服务器端代码（PHP、wp-config、.htaccess），彻底杜绝 SQL 注入、RCE、插件漏洞等传统 WordPress 攻击向量。
零托管成本：Cloudflare Pages 提供免费无限带宽静态托管，适合个人博客、企业官网、文档站点。
安全设计严谨：强制 SSH 主机密钥验证（禁用 StrictHostKeyChecking=no）、ssh-agent 密钥管理、部署前强制清理构建目录、GitHub 私有仓库默认，形成纵深防御。
像素级还原：保留原始站点的视觉和交互效果，仅移除 WordPress 元数据（generator、EditURI、wp-json 等）。
潜在缺点与局限性
动态功能丧失：表单提交、搜索、评论、会员系统等动态功能需替换为第三方服务（如 Formspree、Disqus）或完全移除。
更新流程复杂：内容更新需重新执行完整流程，无法像传统 WordPress 那样即时发布，适合更新频率低的站点。
环境配置门槛：需预先配置 6 个必需环境变量、GitHub CLI 和 Cloudflare Wrangler 认证，对非技术用户不够友好。
服务器依赖风险：首次镜像需在远程服务器执行命令，若服务器不可信或配置不当，存在供应链风险。
边缘场景覆盖不足：重度依赖 JavaScript 的交互功能（如 WooCommerce 购物车）可能无法正确静态化。
适合的目标群体
- 安全敏感型用户：希望彻底消除 WordPress 漏洞风险的企业官网、政府站点
- 成本敏感型用户：个人博客、非营利组织、初创公司，追求零托管费用
- 性能极致追求者：需要全球秒开的高流量内容站点
- 归档备份需求：将历史 WordPress 站点转为永久静态存档
- DevOps 工程师：具备 SSH/CI/CD 经验，能自动化集成至发布流程
使用风险
配置错误风险：环境变量配置不当可能导致连接失败或部署至错误项目，建议首次使用 --dry-run 模式（如未来支持）。
SSH 密钥泄露：若未使用 ssh-agent 而将密钥密码硬编码，或在不安全环境记录命令历史，可能导致凭证泄露。
资源提取遗漏：复杂的懒加载、JavaScript 动态注入资源可能被误判为未引用而删除，需部署前仔细验证。
构建目录残留风险：尽管 Skill 强制在 git 操作前删除 ./build/，若用户手动中断流程或修改代码，仍存在敏感文件误提交可能。
供应商锁定：深度绑定 Cloudflare Pages 和 GitHub，迁移至其他平台需调整部署逻辑。