从 PHP 模板到全站编辑：深度解析经典传统主题与现代区块主题的核心架构与演进

在现代 Web 内容管理系统（尤其是以 WordPress 为代表的 CMS 生态）的发展史上，从传统的 PHP 模板体系迈向全站编辑（Full Site Editing, 简称 FSE）与区块主题（Block Themes），不仅是一次编辑界面的革新，更是底层架构、设计系统与渲染生命周期的一次深刻范式转移。

对于开发者与站长而言，深入理解传统主题与区块主题的底层异同，是构建高性能、易扩展、低维护成本站点的必备功底。本文将从架构模型、目录组织、样式体系、渲染机制、性能损耗以及架构选型等维度进行全面剖析。

一、 架构范式转移：从代码逻辑到声明式数据

要理解传统主题与区块主题的区别，首先需要理解两者的核心哲学差异：

传统主题（Classic Themes）：以 PHP 脚本与模板标签 为核心。页面结构由 PHP 服务端动态拼接并执行，样式与配置分散在 functions.php、定制器和多个 CSS 文件中。

区块主题（Block Themes）：以 HTML 注释语法（Block Grammar）与 JSON 声明式配置 为核心。页面结构被原子化为结构化的区块树，样式与全局设置由单一的 theme.json 统管，实现了从数据到界面的声明式映射。

二、 核心目录与文件结构对比

两者的文件组织存在本质区别。传统主题依赖 PHP 模板层级（Template Hierarchy），而区块主题则将模板全部转化为 HTML 文件：

1. 传统主题的典型目录结构

my-classic-theme/
├── style.css           # 主题元数据声明与全局样式
├── functions.php       # 主题钩子、功能注册与资源入队
├── header.php          # 头部公共模板
├── footer.php          # 底部公共模板
├── sidebar.php         # 侧边栏小工具区域
├── index.php           # 默认主循环回退模板
├── single.php          # 文章详情页模板
├── page.php            # 独立页面模板
└── archive.php         # 归档页模板

2. 现代区块主题的标准目录结构

my-block-theme/
├── style.css           # 仅用于主题信息声明及少量补充 CSS
├── theme.json          # 【核心】全局样式、调色板、排版及区块设置的单一事实来源
├── functions.php       # （可选）仅用于注册高级区块绑定或第三方逻辑
├── templates/          # 纯 HTML 模板文件夹
│   ├── index.html      # 主循环模板
│   ├── single.html     # 文章详情模板
│   ├── page.html       # 独立页面模板
│   └── 404.html        # 404 错误页
└── parts/              # 模板部件（Template Parts）
    ├── header.html     # 模块化页头部件
    └── footer.html     # 模块化页脚部件

在传统主题中，页面拼装通常依赖 get_header()、get_sidebar() 和 get_footer() 等 PHP 辅助函数；而在区块主题中，parts/header.html 直接作为一个区块部件被 templates/index.html 声明引用：

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

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

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

三、 样式管理体系：CSS 混沌 vs theme.json 规范化

1. 传统主题的样式困境

在传统主题中，样式的来源往往高度分散：

• style.css 中充斥着复杂的层叠选择器与 !important；
• 主题定制器（Customizer API）通过动态内联 CSS 注入用户选择的颜色；
• 不同插件自带各自的 CSS 文件，极易导致选择器冲突与资源臃肿。

2. 区块主题的单一事实来源（Single Source of Truth）

区块主题引入了 theme.json 标准规范。开发者只需声明设计令牌（Design Tokens），系统会自动生成 CSS 自定义属性（Variables）并注入前后台：

{
  "$schema": "https://schemas.wp.org/trunk/theme.json",
  "version": 3,
  "settings": {
    "color": {
      "palette": [
        { "name": "Brand Blue", "slug": "brand-blue", "color": "#2563EB" },
        { "name": "Deep Slate", "slug": "deep-slate", "color": "#0F172A" }
      ]
    },
    "typography": {
      "fontFamilies": [
        { "name": "Inter", "slug": "inter", "fontFamily": ""Inter", sans-serif" }
      ]
    },
    "layout": {
      "contentSize": "800px",
      "wideSize": "1200px"
    }
  },
  "styles": {
    "elements": {
      "link": {
        "color": { "text": "var(--wp--preset--color--brand-blue)" }
      }
    }
  }
}

这种模式保证了前台展示、后台编辑器、模板设计器的视觉完全同构，彻底终结了“后台编辑与前台预览视觉割裂”的痛点。

四、 编辑与定制维度的深度对比

五、 性能与加载效率分析

在性能层面，区块主题展现出了非常显著的现代工程优势：

• 细粒度按需加载（Conditional Block Assets Loading）：传统主题往往在全局加载所有组件的样式；而区块主题只有在页面中检测到对应区块（如表格、按钮、画廊）时，才会动态引入该区块专属的微量样式，首屏 CSS 体积大幅削减。
• 无冗余 DOM 输出：传统主题为了适配小工具区域和侧边栏，常常嵌套多层无意义的 <div class="widget-wrap"> 容器；区块主题则输出干净语义化的 HTML 标签。
• 高效服务端解析与缓存：由于 HTML 模板不包含复杂的嵌入式 PHP 查询逻辑，区块解析器可以更高效地对区块树进行结构化预处理与缓存。

六、 架构选型策略：我们该如何抉择？

适用传统主题或混合模式（Hybrid Themes）的场景：

1. 重度依赖遗留插件体系：如果站点依赖大量尚未完全适配 FSE 的老牌复杂电商、多商户或论坛插件，传统主题具备更高的向后兼容性。
2. 复杂的动态服务端过滤：需要大量基于 PHP 钩子（Hooks）进行多维度复杂鉴权、动态数据注入的企业级专有系统。

坚定拥抱区块主题的场景：

1. 内容与营销驱动型站点：运营人员需要极高的页面搭建自由度，无需研发人员频繁介入切图排版。
2. 设计系统（Design System）驱动的新建项目：通过 theme.json 严格管控色彩规范、间距阶梯与字体规格，维护成本极低。
3. 极致的 Core Web Vitals 性能追求：需要轻量化首屏、快速渲染与现代化移动端体验。

七、 结语

从传统主题到区块主题的演进，本质上是 Web CMS 从“开发者垄断模板代码”向“基于设计系统的可视化装配”迈进的必然过程。掌握 theme.json 与全站编辑架构，不仅能极大提升开发与交付效率，更能为现代站点带来更优越的性能与生命力。