WP模板静态化的实际难点，在于生态耦合深。 重点不是代码复杂度，而是要处理动态函数、小工具、短代码、分页URL、多语言等问题。

推荐优先考虑三类成熟方案：插件导出、本地构建、主题层静态化。相比之下，“CI4全站静态导出重构”并不是标准路径。

WP模板静态化这件事，本质上和CI4没有直接依赖关系。两者分属不同技术栈。

WordPress（PHP+MySQL）是内容管理系统，CodeIgniter 4（CI4）则是轻量级PHP框架。本身既不会生成WP主题，也不负责处理WP模板。

所谓“CI4全站静态导出重构”，并不是一条标准实施路径，也没有原生集成方案。

如果看到这种说法，通常是指用CI4单独写一套自定义静态生成器，去抓取、渲染，再导出WordPress站点的HTML。

说白了，这属于绕开WP内核的“外部快照式静态化”。能做，但实施成本高，后续维护也麻烦。

因此，这种方式一般只会在少数特殊场景里小范围尝试，比如离线归档、合规隔离部署。

WP模板静态化的实际难度在哪？

不是代码层面复杂，而是生态耦合深：

• 主题中大量bloginfo()、the_title()、wp_na v_menu()等动态函数，需逐文件识别、替换或预计算；
• 侧边栏小工具、短代码、自定义字段（ACF）、REST API调用等内容无法直接转为静态，必须提前固化输出结果；
• 分页、标签云、分类归档页含动态URL逻辑，静态化后需确保链接结构一致且所有分页/归档页完整生成；
• 多语言（如WPML）、用户登录态、购物车等交互功能，在纯静态下天然不可用，需明确舍弃或用JS补全。

真正可行的静态化路径（无需CI4）

推荐三类成熟方案。 可根据站点规模和可控性选择：

插件导出型

适合中小站点，≤5000篇文章。

• 用 Really Static 或 WP2Static 直接在WP后台触发爬取，生成完整HTML文件包。
• 支持自定义Crawl Increment、修复分页缺失（配合WP-PageNa vi）、导出到本地或S3/FTP。
• 操作门槛低，但依赖服务器PHP配置，需调高max_execution_time和memory_limit。

本地构建型

适合万级内容或高定制需求。

• 在本地装WAMP/XAMPP或Docker环境，导入WP数据库。
• 用Simply Static或自建Node脚本（如wordpress-static-generator）驱动headless爬取。
• 可精确控制URL规则、跳过特定页面、注入CDN前缀，规避线上超时风险。

主题层静态化

仅限展示型站点。

• 不导出整站，而是在主题中将固定内容（如首页Banner、公司介绍、服务列表）从functions.php或header.php中剥离，改用纯HTML+CSS硬编码；
• 动态部分（如最新文章）用AJAX异步加载，主体页面保持静态。
• 这样可以兼顾速度与部分更新能力。

为什么不要自己用CI4重做静态导出？

CI4没有内置WP解析能力。要真正跑通，你还需要补齐一整套能力：

• 模拟WP完整请求生命周期（rewrite规则、query vars、template hierarchy）；
• 手动加载WP核心、主题函数、插件钩子，否则get_posts()或the_content()根本无法执行；
• 处理WP的nonce、cookie、session等安全机制，否则后台登录页、评论提交页会失效；
• 持续同步WP数据库变更——每次文章更新，都得重新触发CI4爬取，反而增加运维负担。

本质上，这是用一套框架去模拟另一套框架。既失去WP的易管理性，也没获得CI4的轻量优势。

这属于典型的“高投入、低收益”重构。

结论

静态化目标明确就好：要的是更快加载、更低资源占用、更高安全性。

选对工具，比换架构更重要。