给 WordPress 换主题，大概是建站这件事里最容易上瘾、也最容易翻车的环节。演示站上处处精致，装到自己服务器上，改两行字就开始出问题，再过两天连哪里动过都想不起来。本站从九月中旬上线起，一直跑 AeroCoreFree 这套父主题加子主题的组合，中间升级过、重装过、也拆过几次自己埋的雷。这篇文章把一个多月里挑主题、改主题、踩配置坑的经验整理出来，不谈理论，只谈真踩到的东西。
挑主题，看的是代码不是演示页
主题市场里九成的判断依据都写在宣传页上：布局多灵活、配色多高级、适配多少插件。这些当然要看，但真正决定你之后一年省不省心的，是三件宣传页上不写的事。第一件是更新节奏，看最近一次更新距离今天多久、更新日志是在真修问题还是只改版本号——一个停止维护的主题，意味着接下来的每一次 WordPress 大版本升级你都在裸奔。第二件是 SEO 字段的实现方式，数据存在哪个键里、走什么通道写入，这直接决定你以后能不能用接口和第三方工具发文章，后面会讲它是怎么坑人的。第三件是有没有配套子主题，或者至少文档里说清楚扩展接口长什么样；一个只许你在后台改改颜色的主题，用不了半年就会让你想动手术。
改任何东西之前，先把子主题建起来
子主题的道理很多文章都讲过：父主题一更新，你直接改在父主题里的文件全部被覆盖，改得越多丢得越干净。WordPress 官方文档对子主题的定位很清楚——所有定制收敛到子主题里，父主题随便升级。但文档不会告诉你的是，子主题不是万能覆盖。本站实测，这套父主题的 home.php 和 header.php 放进子主题同名文件是无效的，前台跑的仍然是父主题那份；在动手改模板之前，值得先拿一个无关紧要的改动试探一次，确认哪些文件真的吃得动，免得改了半天以为生效了。
真正常用而且畅通的定制入口，反倒是主题预留的组件包和自定义页面：放进子主题的 packages 和 pages 目录就会被自动扫描加载，不需要注册，只要给自己的东西统一加一个前缀，避免和主题自带组件撞名。这里有一个细节值得记住——自定义页面的 id 参与模板 slug 的生成，改了 id 就等于换了模板，已经用旧模板发布的页面要回后台重新选一次，否则那几页会直接掉回默认版式。
正文塞不进脚本，是过滤不是故障
想在文章正文里做一个点击展开的面板、一个倒计时，第一反应是把一段脚本直接写进正文。这条路在 WordPress 上是走不通的：正文保存时会过一遍 wp_kses_post() 白名单过滤，脚本标签和 div 的 id 属性都会被剥掉，而且整个过程不报错——你保存成功，预览也正常，只是交互不工作。知道机制之后反而好办，正经出路就两条：主题自带的短代码，或者后台预留的「插入代码」注入位。本站这套主题有十七个短代码可以穿过发布管线，折叠面板、登录可见、口令可见这些常见交互都有现成的，先把短代码翻一遍再动手，通常能省掉一次失败的注入。
最阴险的是静默失效
配置坑里最要命的一类不是报错，是静默。本站这套主题把文章的 SEO 字段——标题、描述、关键词——打包成一段编码后的 JSON，存在一个自定义 meta 键里，而且没有把这几个键注册进 REST API。后果是：用 REST 接口或者任何基于 REST 的发布工具发文章，SEO 三件套和自定义封面会被无声无息地丢掉，接口照常返回成功，文章照常上线，只是搜索引擎看到的标题和描述全是默认值。等你从搜索结果页里发现不对劲，可能已经过去一个星期。这就是前面说挑主题要查「SEO 字段怎么存」的原因：它决定了你未来的发布工具链有没有接口可走。解法要么是发关键文章时回传统编辑器手工填，要么像本站一样自己写一个直接调底层写库函数的发布接口，绕开 REST 的白名单。
第二个静默坑是「插入代码」。多数主题后台都有这个功能，本站这套给了头部 CSS、头部 JS、页脚 JS 三个框，两个特性叠在一起很危险。一是整段替换：你往框里贴新代码保存，框里原有的内容会被一起冲掉，没有任何提示——本站的首页隐藏规则就这么丢过一次，之后所有长期生效的基础样式都改放子主题的 css 目录，跟着代码走，框里只放经常要换的东西。二是标签嗅探：框里任何位置出现了脚本或样式标签的字面量，包括写在注释里的，主题就不再替你补外层标签、原样输出，整段注入会直接失效。往框里放代码之前，先把内容通读一遍，确认没有标签字面量混在注释里。
第三个静默坑在组件包的缓存上。这套主题给前端组件资源做缓存时，缓存键只算页面布局的哈希，不算组件包本身。于是会出现一种很迷惑的状态：往子主题里重传组件包之后，组件照常渲染出来，但它自带的样式文件没有加载，页面看着「差不多对」，其实用的是旧样式。判断这种情况不要看渲染结果，要看资源清单里样式文件有没有请求；手动补救也简单，去后台把布局重新保存一次，缓存键就换了。新版主题加了目录指纹自愈，但旧版本上这个坑还会再咬人。
改了没生效，先回头查保存
这套主题的首页是服务端渲染，站点也没有页面缓存，理论上后台的改动应该即时生效。实际遇到「改了没生效」，十有八九出在两处。一处是后台设置根本没保存成功，幻灯片这类布局数据存在系统的选项表里，服务端渲染直接读它，没保存就是没变化。另一处是后台「界面自定义」里某一块显示「不支持」，这个标记的含义是当前页面引用了注册表里没有的组件，或者组件的可用页面列表里不含当前页——有一次子主题重装时漏传了 packages 和 pages 两个目录，后台就整排「不支持」，组件全空，用完整的子主题包覆盖回来，标记立刻消失。所以排查顺序应当是先查保存、再查组件注册，最后才怀疑缓存和代码。
主题这个东西，用久了会发现它更像租来的房子：结构是房东的，你随时可能面对升级改造，真正的主动权全在装修层。把所有改动收敛进子主题，父主题随便升；把「插入代码」框当便签而不是档案柜；每接入一个新功能，先想清楚它的数据存在哪、走哪条通道、什么时候会静默失效。这三个习惯，比任何具体的改造技巧都保值。
一、一手信息
- 本文全部结论来自本站自 2026 年 9 月中旬起的实际运行与排障记录；同机的 PHP 层排查经过另见服务器 PHP 为什么慢：一次 open_basedir 排查。
二、官方文档
- 子主题（Child Themes）— WordPress Developer Resources：https://developer.wordpress.org/themes/advanced-topics/child-themes/
- wp_kses_post() 函数参考 — WordPress Developer Resources：https://developer.wordpress.org/reference/functions/wp_kses_post/
本文为主题与插件的实操记录，具体行为以所用主题当前版本为准。
相关阅读
原创声明：本文由 618A 情报站整理撰写，基于公开信息与实测记录，转载请注明出处并保留原文链接。