WordPress 区块主题 vs 经典主题：一次说实话的对比

打开你的主题文件夹。如果里面有一个 templates 目录、目录里躺着 index.html，根目录还有一个 theme.json，那就是区块主题。如果里面是 index.php 以及 header.php、footer.php 这类文件，后台侧边栏显示的是“外观 → 自定义”，那就是经典主题。

就这一个结构上的差别，决定了谁能改站点上的什么、这些改动存在哪里，以及 WordPress 插件生态里的哪一半能正常工作。

30 秒判断法

判断依据	经典主题	区块主题
根模板文件	index.php	templates/index.html
页头与页脚	header.php、footer.php	parts/header.html、parts/footer.html
全局配置	functions.php	theme.json（functions.php 可选保留）
后台菜单	外观 → 自定义	外观 → 编辑器
改动保存在哪	磁盘上的文件	数据库，以 wp_template 文章形式存储
小工具页面	有	没有

WordPress 判断的依据就是有没有 templates/index.html。一个带了 theme.json 但保留 PHP 模板的主题，仍然被当作经典主题——这种中间状态很常见，也有专门的说法，下面会讲。

如果你有命令行权限，一条命令就能定论：

wp eval 'var_dump( wp_is_block_theme() );'

接手别人做的站点时，WP-CLI 是最快的判断方式，尤其是当某个页面构建器把常规后台菜单藏起来的时候。

对改站点的人来说，变了什么

在经典主题里，页头、页脚、侧边栏、配色和 Logo 都藏在自定义器后面，而且你只能用到主题作者当初决定做出来的那些控件。如果作者没给页脚版权文字注册控件，那就是没有。要么去改 PHP 文件，要么忍着。

在区块主题里，站点编辑器把整个页面都摊开了。页头、页脚、文章列表、404 页面、搜索结果的排版——全都是区块，全都能被一个从没见过 PHP 的人改动。这是真正的核心卖点，而且分量确实很重。

代价是：这些东西也全都能被一个从没见过 PHP 的人改坏。客户可以凌晨两点把页头里的站点标题删掉，而磁盘上没有任何版本记录可供恢复——只有站点编辑器自己的修订记录。你当然可以用区块锁定、限制谁能进编辑器来做约束，但这是需要你主动记得去做的额外工作。

还有两个不大但在实际中很硌人的损失：区块主题没有小工具页面（小工具区域被模板部件和区块取代了），经典菜单则被导航区块取代，它把菜单项存成了一种独立的内容类型，而不是放在大家熟悉的“菜单”页面里。

对开发者来说，变了什么

经典主题走的是 PHP 模板层级。WordPress 沿着一条已知的链条解析请求——single-{post-type}.php，然后 single.php，然后 singular.php，最后 index.php——你的文件被执行，调用 get_header()，跑主循环，输出你能逐个字符掌控的标记。

<?php get_header(); ?>
<main class="site-main">
  <?php while ( have_posts() ) : the_post(); ?>
    <h1><?php the_title(); ?></h1>
    <?php the_content(); ?>
  <?php endwhile; ?>
</main>
<?php get_footer(); ?>

区块主题用的是同样的层级命名，只是扩展名换成 .html，而文件内容是区块标记——把区块分隔符写在注释里的 HTML——并且没有模板标签：

<!-- wp:template-part {"slug":"header","tagName":"header"} /-->

<!-- wp:group {"tagName":"main"} -->
<main class="wp-block-group">
  <!-- wp:post-title {"level":1} /-->
  <!-- wp:post-content /-->
</main>
<!-- /wp:group -->

<!-- wp:template-part {"slug":"footer","tagName":"footer"} /-->

开发者会立刻撞上三个后果：

get_header() 和 get_footer() 根本不会执行。 任何挂在这两个动作上的代码，不管在插件里还是在老的子主题里，都会悄无声息地什么也不干。wp_head 和 wp_footer 依然会触发，所以大部分脚本样式入队还能活，但页头专属的钩子活不了。

数据库赢过你的文件。 只要有人在站点编辑器里保存过某个模板，WordPress 就会把那个版本存成一条 wp_template 记录，并且拿它来输出，而不是你的文件。你可以改一下午 HTML 文件，前台纹丝不动。清除该模板的定制，文件版本才会回来。这是“我的区块主题坏了”这类反馈里最常见的一种，而它并不是 Bug。

样式搬进了 theme.json。 配色、间距刻度、排版、每种区块的默认值，都不再是 CSS，而是以数据形式声明，由 WordPress 生成 CSS。这更干净，一致性也强得多——直到你需要一个 schema 表达不了的东西，那时候你还是得写 CSS，还得跟生成出来的规则拼优先级。

{
  "version": 3,
  "settings": {
    "color": {
      "palette": [
        { "slug": "brand", "color": "#1a1a1a", "name": "Brand" }
      ]
    }
  }
}

对照你所用的 WordPress 版本核对一下 version 的取值——这套 schema 改过不止一次，从老教程里抄来的版本号会让你的设置被悄悄忽略。

顺带一提，functions.php 并没有消失。区块主题照样用它来入队资源、注册 add_image_size、注册自定义文章类型，以及其他一切需要 PHP 的事情。只是你在里面写的模板逻辑少多了。

你实际得到什么，又实际失去什么

转向区块主题，你得到： 对整个页面的编辑器级控制、由 theme.json 强制统一的设计规范、更少需要维护的文件，以及编辑器和前台之间远比经典主题一致得多的样式表现。

转向区块主题，你失去： 对输出标记的直接掌控、直截了当的钩子式定制、对一切假定存在 PHP 模板的东西的兼容性，以及“站点外观都在版本控制里”这份踏实感。

最后一条值得强调。在经典主题里，git log 能告诉你改了什么。在区块主题里，站点外观中相当一部分躺在数据库里，而你的部署流水线根本不往那儿看。

什么时候经典主题依然是正确答案

• 站点由页面构建器驱动。 Elementor、Divi、Beaver Builder 之类的工具自己接管了模板这件事。在下面再垫一个区块主题，等于多了一套什么也没做的模板系统。
• 标记必须一模一样。 定制组件库、严格的无障碍标记、特殊的结构化数据要求——区块能输出什么是有限的，硬掰它的成本比直接写 PHP 更高。
• 插件重度依赖模板覆盖。 会员、在线课程、目录站，以及一些较老的商城扩展，经常要靠 PHP 模板覆盖。现在很多已经有了区块方案，但还有很多没有。
• 站点已经做完了，而且跑得好好的。 一个积累了五年定制的主题，没有通往区块主题的升级路径，只有重做。“这是更新的做法”不构成一条商业理由。
• 除了你没人会去改它。 站点编辑器最主要的价值是把控制权交给不懂代码的人。如果压根没有这样的人，你就是在为一个没人使用的好处付代价。

中间那条混合路线

经典主题也可以加一个 theme.json，从而用上全局样式系统、颜色和间距预设，以及一致的编辑器样式——同时保留自己的 PHP 模板和自定义器。WordPress 不会因此把它算作区块主题，站点编辑器依然不可用，但你只花一小部分工夫就拿到了设计系统的大部分好处。

对一个基本能用的现有站点来说，这通常是最该先走的一步。加上 theme.json，定义好调色板和间距，删掉被它取代的 CSS，然后再看看你还想不想要剩下那些。