redis缓存默认用serialize()易因closure/pdo崩溃，应改用json序列化并清空旧缓存；file驱动存对象慢可抽字段、改json或升级igbinary。
Redis驱动默认用serialize()，但容易因Closure/PDO崩溃
ThinkPHP Redis缓存默认走PHP原生serialize() + base64_encode()流程，能完整保留对象状态（含private属性、__sleep/__wakeup），但一旦数据里混入Closure、PDO、资源句柄或未实现JsonSerializable的自定义对象，就会直接抛出Serialization of 'Closure' is not allowed，接口白屏、逻辑中断。
常见踩坑点：
- 把
Db::name('user')->select()返回的Collection对象直接塞进Cache::set()——它内部持有了查询器和连接实例 - 缓存中存了
Request或Response对象，它们包含Swoole协程上下文或文件句柄 - 没做前置检测，上线后某次请求突然触发序列化失败，错误日志里只看到“PHP Fatal error”，找不到源头
强制Redis用JSON序列化：改配置+清空旧缓存
最稳妥的方案是让Redis缓存改用json序列化，避开所有不可序列化类型。它不支持资源和闭包，但会静默转为null或跳过，不会崩。
操作步骤：
- 在
config/cache.php的stores.redis配置里加一行：'serialize' => 'json' - 或者统一用
.env管理：REDIS_SERIALIZE=json，并在配置中读取：'serialize' => env('REDIS_SERIALIZE', 'php') -
必须执行
redis-cli -a yourpass FLUSHDB或手动删掉所有think:开头的key——否则老的serialize()数据会被json_decode()当成乱码，get()返回null
注意：json模式下取回的是stdClass或数组，原始对象方法丢失。如果业务强依赖对象行为（比如调用$user->getName()），得在取回后手动new对象并赋值。
File驱动存对象太慢？别硬扛，换序列化策略或结构
File驱动用serialize()写文件，对象一多就体积暴涨、读取变卡——因为字符串里塞满了类名、命名空间、属性键名等冗余信息。
优化方向不是“怎么压缩序列化结果”，而是：
- 缓存前先
array_only($data, ['id', 'name', 'email'])抽关键字段，丢掉集合对象、关联模型、原始SQL语句 - 改用
json序列化（File驱动也支持'serialize' => 'json'配置），体积小、可读性强、无兼容风险 - 真要存完整对象，且必须用File驱动，考虑升级到
igbinary扩展（需服务器安装），比serialize()体积小30%、速度快2倍，但仅限PHP环境
别在set()前手动json_encode()再传给Cache——框架会再套一层serialize()，导致双重编码，get()出来是字符串而非数组。
反序列化失败时，先看类是否存在、再查驱动配置
unserialize()失败不报错、只返回false或null，常见原因不是数据损坏，而是类定义缺失或驱动配置被覆盖。
排查顺序：
- 确认
php.ini里unserialize_callback_func没被设为''（禁用后类不存在时静默失败） - 检查
config/cache.php中stores.redis.serialize是否还是'php'，有没有被中间件或运行时配置悄悄改掉 - ThinkPHP 6.1+ Redis驱动会给缓存值加前缀
s:标识类型，老版本缓存升级后无法识别——必须清空，不能靠兼容层硬扛 - 用
redis-cli连上去GET think:your_key，看返回值是不是base64字符串（serialize）还是纯JSON（json），对不上就说明序列化/反序列化链路断了
跨环境部署时，最容易忽略的是Redis服务端没开AOF/RDB持久化，或缓存过期时间设得太短，导致你以为是反序列化问题，其实是数据根本没存住。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
