一、背景与目的

在多 WordPress 站点共用服务器的环境中（例如宝塔或自建多站点结构），Redis Object Cache 的 drop-in 文件 object-cache.php 往往需要在每个站点中保持一致。

典型问题包括：

• 站点数量多，手动复制效率低且容易出错
• 插件升级或缓存策略调整时，需要统一更新
• 只需要 drop-in 生效，并不希望引入复杂的插件激活、WP-CLI 或配置修改逻辑
• 新建站点后忘记配置缓存，导致性能表现不一致
• 无法快速确认哪些站点已经启用了对象缓存

因此，本次的目标非常明确：

在不改动 wp-config.php、不使用 WP-CLI、不涉及插件管理的前提下，批量为所有 WordPress 站点部署统一的 object-cache.php 文件。

---

二、当前需求的精确定义（第一性原理）

将需求拆解为最小集合：

1. 源文件唯一

   • /www/wwwroot/test-wp-template/object-cache.php

2. 目标站点判定规则

   • 位于 /www/wwwroot/*
   • 必须存在 wp-config.php
   • 必须存在 wp-content 目录

3. 部署行为

   • 复制到

     /www/wwwroot/站点名/wp-content/object-cache.php
     

   • 覆盖同名文件（以模板为准）

4. 权限规范

   • 权限：755
   • 属主：www:www

不涉及、不依赖、不假设：

• WP-CLI
• 插件是否激活
• wp-config.php 内容
• Redis 是否运行

---

三、object-cache.php 是什么？到底起什么作用？

这是整个方案中最关键、也最容易被误解的部分。

1️⃣ WordPress 的对象缓存是什么？

WordPress 在运行过程中，会频繁产生以下数据：

• get_option()
• get_post() / WP_Query
• 用户权限、角色
• 主题、插件配置

默认情况下，这些数据：

• 每个请求都会重新计算
• 每次都会访问数据库

对象缓存的作用就是：

在一次请求内，甚至跨请求，将这些“已经算过的结果”缓存起来，避免重复计算和数据库访问。

---

2️⃣ 为什么是 object-cache.php，而不是插件？

因为 WordPress 有一个特殊机制：Drop-in

• wp-content/object-cache.php
• 这是一个内核级钩子文件
• WordPress 在非常早期加载它
• 优先级高于普通插件

只要这个文件存在：

wp-content/object-cache.php

WordPress 就会：

• 使用它提供的缓存实现
• 完全替换默认的 WP_Object_Cache

这也是为什么：

object-cache.php 是“是否真正启用 Redis/Object Cache”的决定性文件。

---

3️⃣ 它通常做了什么？

一个典型的 Redis object-cache.php 会：

• 重写 wp_cache_get() / set() / delete()
• 将缓存键写入 Redis
• 控制缓存前缀、防止多站点冲突
• 支持 selective flush（只清某站点缓存）

插件只是“管理工具”，真正执行缓存的是这个文件。

---

四、最终脚本的实现逻辑

1️⃣ 入口校验（防止误操作）

• 启动前检查模板文件是否存在
• 模板缺失 → 直接退出

这是批量脚本中最重要的安全闸口。

---

2️⃣ 遍历站点根目录

for site_dir in "/www/wwwroot"/* ; do

• 只处理目录
• 不假设所有目录都是站点

---

3️⃣ 判断是否为 WordPress 站点

if [ ! -f "$site_dir/wp-config.php" ]; then
    continue
fi

这是 WordPress 最稳定、最低误判率的判定方式。

---

4️⃣ 定位 wp-content 并复制 drop-in

cp -a "$TEMPLATE_CACHE_FILE" "$site_dir/wp-content/object-cache.php"

• 使用 -a 保留文件结构
• 直接覆盖，确保一致性

---

5️⃣ 设置权限与属主

chmod 755 object-cache.php
chown www:www object-cache.php

这样做的意义：

• PHP-FPM（www）可正常读取
• 不给写权限，避免被插件或 Web 覆盖
• 权限模型清晰、可控

---

五、最终脚本（完整版）

#!/bin/bash
# bulk_copy_object_cache.sh
# 功能：从模板站点复制 object-cache.php 至所有 WP 站点，并设置权限。

TEMPLATE_CACHE_FILE="/www/wwwroot/test-wp-template/object-cache.php"
SITES_ROOT="/www/wwwroot"
TARGET_OWNER="www"
TARGET_GROUP="www"
TARGET_MODE=755

if [ ! -f "$TEMPLATE_CACHE_FILE" ]; then
    echo "ERROR: 模板文件不存在: $TEMPLATE_CACHE_FILE"
    exit 1
fi

echo "开始批量部署 object-cache.php ..."

for site_dir in "$SITES_ROOT"/* ; do
    if [ ! -d "$site_dir" ]; then continue; fi

    if [ ! -f "$site_dir/wp-config.php" ]; then
        echo "[SKIP] $site_dir"
        continue
    fi

    if [ ! -d "$site_dir/wp-content" ]; then
        echo "[WARN] $site_dir 缺少 wp-content"
        continue
    fi

    cp -a "$TEMPLATE_CACHE_FILE" "$site_dir/wp-content/object-cache.php"
    chmod $TARGET_MODE "$site_dir/wp-content/object-cache.php"
    chown $TARGET_OWNER:$TARGET_GROUP "$site_dir/wp-content/object-cache.php"

    echo "[OK] $(basename "$site_dir")"
done

echo "完成。"

---

六、最终脚本的价值总结

通过这个脚本，实现了：

• 对象缓存配置的“基础设施化”
• 消除人工配置的不确定性
• 新站点可快速纳入统一缓存体系
• 为后续 Redis、性能调优打下干净基础

一句话总结：

插件是控制面，object-cache.php 是数据面；
批量部署 object-cache.php，才是真正把对象缓存落地。

---

补充：
批量添加Redis的方法：
https://blog.csdn.net/lds1942816258/article/details/150958415
清理服务器所有wp站点的Redis缓存：
https://blog.csdn.net/lds1942816258/article/details/156021449
清理服务器单个或多个wp站点的Redis缓存：
https://blog.csdn.net/lds1942816258/article/details/156025932