Memcached需正确配置PHP扩展、object-cache.php路径及WP_CACHE_KEY_SALT才能生效；仅部署服务端无效，必须启用memcached扩展、上传object-cache.php至wp-content目录、多站需设唯一salt并验证命中率。
Memcached 能显著减少 WordPress 等 PHP 应用对数据库的重复查询，但**只装服务不配对象缓存，等于白装**。关键在 object-cache.php 是否正确落地、是否被 WordPress 主动加载，以及 PHP 扩展名是否为 memcached（不是 memcache）。
确认 PHP 已启用 memcached 扩展（不是 memcache）
宝塔里“软件商店 → Memcached”插件只是部署服务端，真正让 PHP 能调用它的，是对应 PHP 版本的 memcached 扩展。常见错误是：装了服务，却忘了进「PHP 设置 → 安装扩展」里勾选 memcached。
- 进入「软件管理 → 找到你网站用的 PHP 版本（如 PHP 8.1）→ 设置 → 安装扩展」
- 找到
memcached（注意结尾带d），点击安装；若显示「卸载」说明已启用 - 安装后必须重启 PHP 进程，否则扩展不生效
- 验证方式：点该 PHP 版本右侧的「phpinfo」→ 搜索
memcached support，显示enabled才算成功
上传 object-cache.php 到 wp-content 目录（非 plugins）
WordPress 不会自动加载插件目录下的缓存逻辑，它只认 /wp-content/object-cache.php 这个特定路径的文件。放错位置是“装了没效果”的最常见原因。
- 从 GitHub 下载官方兼容版：wordpress-pecl-memcached-object-cache，解压得到
object-cache.php - 用宝塔文件管理器或 FTP，将该文件直接上传至网站根目录下的
/wp-content/（不是/wp-content/plugins/） - 确保文件权限为 644，且所属用户与网站运行用户一致（通常是
www） - 无需激活插件，WordPress 启动时会自动检测并加载该文件
检查命中率与连接状态（别只看“已安装”）
装完不代表在工作。真正的指标是缓存命中率（hit_rate）和连接状态，而不是面板上“服务运行中”几个字。
- 登录宝塔 → 软件管理 → 找到蓝色 M 图标的 Memcached → 点「设置」→ 查看「负载状态」里的
curr_items、get_hits、get_misses；命中率 =get_hits / (get_hits + get_misses)，低于 80% 就得排查 - 临时加一行诊断代码到
wp-config.php最上方（仅调试用）：define('WP_DEBUG', true); error_log(print_r(wp_cache_get_stats(), true), 3, '/tmp/memcache-debug.log');查看日志是否返回数组，空数组说明未连上 - 如果
wp_cache_get_stats()报错或返回 false，大概率是$MEMCACHE_SERVERS配置缺失，需手动在object-cache.php顶部补上：$memcached_servers = array('default' => array('127.0.0.1:11211'));
多站点共用 Memcached 时的 key 冲突问题
同一台服务器跑多个 WordPress 站点，若都用默认配置，缓存 key 会互相覆盖——A 站的文章数据可能被 B 站读走，导致内容错乱或 500 错误。
- 必须在每个站点的
wp-config.php中定义唯一前缀：define('WP_CACHE_KEY_SALT', 'site-a-');（把site-a-换成你站点的标识） - 该定义必须放在
require_once(ABSPATH . 'wp-settings.php');之前，否则无效 - 改完要清空 Memcached：在宝塔 Memcached 设置页点「重载配置」或「重启服务」
- 不设 salt 的后果不是“没效果”，而是“效果诡异”——比如后台编辑文章后前台显示旧内容，查半天发现是缓存污染
最易被忽略的是 WP_CACHE_KEY_SALT 和 object-cache.php 的路径位置。前者不加，多站必乱；后者放错目录，整个对象缓存链路就断在第一步。别信“安装完成”的提示框，要看 get_hits 和 wp_cache_get() 返回值是否真实有效。
