WordPress中sitemeta等冗余站点标识的架构原因及使用疑问

作为从WordPress早期就开始折腾多站点的老玩家，太懂你这种困惑了——这些变量、表名看起来重叠度极高，官方文档讲得云里雾里，网上的教程大多只会教你怎么改配置凑合用，根本不说背后的逻辑。我来把这些概念拆得明明白白：

先搞懂核心背景：WordPress多站点的术语历史 #

早期WordPress多站点叫WPMU（WordPress MultiUser），当时的术语和现在有点混乱：

• 「Site」指的是整个多站点网络
• 「Blog」指的是网络里的单个独立站点
  后来WPMU合并到WP核心后，术语没完全统一，导致现在“site”有时候指网络，有时候指单个站点，这也是困惑的根源之一。

逐个解析每个概念的用途&关联 #

1. DOMAIN_CURRENT_SITE（wp-config.php常量） #

这是整个多站点网络的基准锚点，直接定义了你的网络“根站点”的域名和对应ID（默认site_id=1）。比如你的网络主站是example.com，那配置里就是：

define( 'DOMAIN_CURRENT_SITE', 'example.com' );
define( 'SITE_ID_CURRENT_SITE', 1 );

它的核心作用是：

• 网络初始化时告诉WP“这个请求属于哪个网络”（支持多个独立网络的场景，虽然大部分人用不到）
• 定位网络管理后台（/wp-admin/network/）的入口，确保你访问的是当前网络的全局管理界面

2. wp_site数据库表 #

这是存储整个多站点网络元数据的表，每个网络对应一行数据（默认只有一行，site_id=1）。核心字段：

• site_id：网络唯一ID
• domain：网络的基准域名（和DOMAIN_CURRENT_SITE完全对应）
• path：网络的基准路径（子目录模式下是/，子域名模式也是/）
  它相当于整个网络的“身份证”，所有站点（blogs）都通过site_id关联到这个表，确保属于同一个网络。

3. wp_blogs数据库表 #

这是网络里**所有单个站点（原WPMU里的“blog”）**的注册表，每个独立站点对应一行。核心字段：

• blog_id：单个站点的唯一ID（从1开始递增）
• site_id：关联wp_site的网络ID，说明这个站点属于哪个网络
• domain：该站点的访问域名（子域名模式下是sub.example.com，子目录模式下和主域名一致）
• path：该站点的访问路径（子目录模式下是/sub/，子域名模式下是/）
  WP处理请求时，第一步就是通过这个表匹配用户访问的domain+path，找到对应的blog_id，然后切换到该站点的环境。

4. wp_sitemeta数据库表 #

相当于多站点网络的全局配置表，和单站点的wp_options功能类似，但存储的是网络级别的设置：

• 比如网络默认的主题、强制启用的插件、全局上传路径等
• 每条数据通过site_id关联到wp_site，确保是当前网络的全局配置
  而每个单个站点的独立配置（比如站点标题、 permalink 设置）则存在wp_{blog_id}_options表中。

5. home & siteurl（站点级选项） #

这是每个站点（wp_{blog_id}_options表）里的核心配置项：

• siteurl：WordPress核心代码所在的URL（比如你的WP安装在example.com/wp，那siteurl就是这个）
• home：站点前台展示的URL（如果和siteurl一致，就直接访问；如果把前台放在根目录，siteurl是example.com/wp，home是example.com）
  在多站点里，每个子站点都有自己的这两个选项，用来区分不同站点的访问路径和核心文件路径，灵活支持子域名、子目录甚至自定义域名的场景。

背后的处理架构逻辑 #

整个请求的流程大概是这样的：

用户访问 URL → WP 读取 DOMAIN_CURRENT_SITE 确定所属网络 → 查询 wp_blogs 表匹配 domain+path 得到 blog_id → 加载对应 wp_{blog_id}_options 表的 home/siteurl → 结合 wp_sitemeta 的网络全局配置 → 输出站点内容

为什么需要这么多“重复”的概念？ #

1. 历史遗留：为了兼容早期WPMU的用户，保留了原有的表结构和术语，没做颠覆性改动
2. 分层设计：把网络级配置和站点级配置彻底分开，支持一个WP安装运行多个独立网络（虽然大部分人用不到，但架构上保留了这个能力）
3. 灵活性：通过wp_blogs的domain+path、站点级的home/siteurl，可以实现多种站点部署模式（子域名、子目录、自定义域名），覆盖不同的业务需求

关于架构示意图 #

官方没有专门的直观示意图，但你可以根据上面的流程链自己梳理：

[用户请求] → [DOMAIN_CURRENT_SITE → wp_site] → [wp_blogs → 匹配得到blog_id] → [wp_{blog_id}_options → home/siteurl] → [wp_sitemeta → 全局配置] → [输出内容]

确实这些概念太绕了，官方文档也没讲透，网上的教程大多只讲操作不溯源，我也是踩了无数坑才搞明白的。

内容的提问来源于stack exchange，提问作者Davor Josipovic