Memcached 默认不支持PHP自定义对象直接缓存，仅支持标量、数组和stdClass；正确做法是手动serialize()/unserialize()包装，并配合白名单防护反序列化风险。
Memcached 默认不支持 PHP 对象直接缓存
PHP 的 Memcached 扩展（非 memcache）默认使用 Memcached::SERIALIZER_PHP 序列化器时，**仅支持标量、数组、stdClass 实例**，遇到自定义类对象会静默失败或返回 false，get() 拿不到值也不报错——这是最常踩的坑。
根本原因是：PHP 对象序列化需明确允许（如实现 Serializable 接口或含 __serialize()/__unserialize()），而 Memcached 默认序列化器不会自动处理魔术方法或私有属性。
- 用
serialize()+unserialize()手动包装是兼容性最强的做法，适用于所有 PHP 版本和任意对象 - 若用
Memcached::setOption(Memcached::OPT_SERIALIZER, Memcached::SERIALIZER_PHP)，仍需确保对象可被serialize()安全处理（比如不含资源、闭包、PDO 实例等） - PHP 8.1+ 若对象含
__serialize()，手动serialize()仍有效，但不要混用两种机制
正确写法：手动 serialize/unserialize 包装
绕过 Memcached 内置序列化逻辑，自己控制序列化过程，最稳妥也最透明。
$mem = new Memcached();
$mem->addServer('127.0.0.1', 11211);
$user = new User();
$user->id = 123;
$user->name = 'Alice';
// ✅ 正确：手动序列化后存入
$key = 'user:123';
$serialized = serialize($user);
$mem->set($key, $serialized, 3600);
// ✅ 正确：取回后手动反序列化
$cached = $mem->get($key);
$obj = $cached ? unserialize($cached) : null;
- 务必检查
$cached是否为false或null，Memcached 失败时不抛异常 - 如果对象含敏感字段（如密码、token），序列化前建议
unset()掉，或改用json_encode()+ DTO 方式替代 - 避免缓存含
Closure、resource、PDO等不可序列化成分的对象，否则serialize()会警告并返回false
兼容 PHP 7.4–8.3 的安全反序列化防护
反序列化是高危操作，尤其当缓存内容可能被污染（如共享 Memcached 实例、未校验 key 来源）时，unserialize() 可能触发恶意 __wakeup() 或 __destruct()。
立即学习“PHP免费学习笔记（深入）”；
- 生产环境必须限制反序列化类白名单，可用
unserialize($data, ['allowed_classes' => ['User', 'Post']])（PHP 7.4+） - 若用 PHP igbinary 序列化（需扩展支持）或 JSON + 显式构造（更安全但丢失类型）
- Memcached 中的 key 建议加项目前缀（如
myapp:user:123），避免跨项目冲突导致误反序列化
性能与内存开销：serialize vs igbinary vs json
三种方式在速度和体积上差异明显，选型要看场景：
-
serialize()：PHP 原生，兼容最好；体积大、解析慢，但无需额外扩展 -
igbinary：需安装igbinary扩展；序列化后体积约小 30%，速度提升 2–5×；Memcached 支持原生启用：$mem->setOption(Memcached::OPT_SERIALIZER, Memcached::SERIALIZER_IGBINARY) -
json_encode()：不能保留对象类型、私有/保护属性、方法；适合 DTO 场景；无反序列化风险，但需手动 new 对象赋值
如果项目已稳定运行且无扩展权限，serialize() + 白名单 unserialize() 是最务实的选择。复杂对象结构、高频缓存读写、且能装扩展时，igbinary 值得投入。
别忘了：Memcached 本身不校验数据完整性，序列化后的字节流损坏会导致 unserialize() 报致命错误——上线前务必在日志中捕获并降级处理。
