必须在宝塔对应网站所用PHP版本的“安装扩展”中勾选memcached（非memcache），并验证phpinfo()显示“memcached support => enabled”及服务端netstat确认11211端口监听，否则Class 'Memcached' not found或连接失败。
确认 PHP 扩展是否装对了版本
宝塔里“软件商店”中那个蓝色 Memcached 图标组件只是个壳，它不等于 PHP 能用 new Memcached()。真正起作用的是对应 PHP 版本的扩展——必须进「PHP 设置 → 安装扩展」里单独勾选 memcached（注意拼写，不是 memcache）。
常见错误是：网站用的是 php7.4，但只在 php7.2 里装了扩展；或者装了 memcache（旧版、已淘汰），结果代码报 Class 'Memcached' not found。
- 查当前网站实际 PHP 版本：宝塔 → 网站 → 点击域名 → 「PHP 版本」栏显示的才是真实版本
- 进该版本的「设置 → 安装扩展」，找
memcached（带 d 结尾），勾选安装并重启 PHP - 验证是否生效：新建一个
info.php，内容为<?php phpinfo(); ?>，浏览器访问，搜索memcached，看到 “memcached support => enabled” 和 “libmemcached version” 才算成功
检查 memcached 服务端有没有真跑起来
memcached -v 报 command not found，说明服务端二进制根本没装，光装 PHP 扩展毫无意义。
宝塔不会自动帮你装服务端，得手动执行命令：
立即学习“PHP免费学习笔记（深入）”；
- CentOS/RedHat 系：运行
yum install -y memcached - Ubuntu/Debian 系：运行
apt install -y memcached - 装完立刻检查监听状态：
netstat -tuln | grep :11211，有输出才表示服务已启动并监听本地端口 - 如果没输出，手动启一下：
systemctl start memcached && systemctl enable memcached
别信面板上“Memcached 已安装”的提示——那只是图标亮了，不代表服务在跑。
连接失败或命中率为 0 的典型原因
PHP 扩展和服务端都 OK，但 WordPress 缓存还是不走 Memcached，大概率卡在这几个地方：
- WordPress 没启用
object-cache.php：必须把插件提供的object-cache.php（不是.zip或plugin目录）直接丢进/wp-content/根目录，不是/wp-content/plugins/ - PHP 代码里没显式连对地址：默认是
127.0.0.1:11211，但如果改过配置（比如绑了0.0.0.0或换了端口），就得写全：$m = new Memcached(); $m->addServer('127.0.0.1', 11211); - 键名非法触发序列化失败：自己拼的键如
"user_{$id}"中$id是数组或null，PHP 自动序列化后 Memcached 拒收，日志里会报SERVER_ERROR bad data chunk；只传字符串或 JSON，避免直接塞数组
验证是否真在用、以及为什么命中率长期为 0
面板里「软件商店 → Memcached → 负载状态」显示 hit=0，不一定是没装好，更可能是没被访问触发缓存逻辑。
真实验证步骤：
- 先确保网站有真实访问（比如自己多刷几次前台页面），空流量下自然没命中
- 看服务端日志：
tail -f /var/log/memcached.log；若无日志，编辑/etc/sysconfig/memcached，把OPTIONS改成"-vv"再systemctl restart memcached - 用命令行直连测试：
echo "stats" | nc 127.0.0.1 11211 | grep "curr_items\|cmd_get\|get_hits"，有数字增长说明服务在收请求 - WordPress 插件页或后台查看缓存状态（如 Memcached Is Your Friend 插件自带仪表盘），比面板里的统计更准
最常被忽略的一点：多个 PHP 版本共存时，扩展只装在一个版本里，而网站绑错了版本——这种“看起来全对，实则完全不走”的情况，排查起来最耗时间。
