ThinkPHP缓存驱动存储格式迁移_升级后的缓存数据兼容处理-ThinkPHP-PHP中文网

缓存数据反序列化失败的根源是tp6+默认用serialize()而tp5.x用json_encode()，导致旧json缓存被新驱动误读为null或乱码；解决方法是在自定义驱动中重写get()/doread()，先尝试json解析再fallback到unserialize，并兼容无签名文件、redis双key及第三方非标缓存。

thinkphp缓存驱动存储格式迁移_升级后的缓存数据兼容处理

缓存数据反序列化失败：升级后 `Cache::get()` 返回 null 或乱码

ThinkPHP 6.0+ 默认改用 serialize() 替代 json_encode() 存储缓存值，老版本（如 TP5.1）写入的 JSON 格式缓存，在新驱动下无法自动识别和反序列化。现象是读取旧缓存时返回 null，或解包出字符串但内容为原始 JSON 文本（比如 "{\"name\":\"admin\"}" 而非数组）。

解决思路不是“统一格式”，而是让新驱动能“向后看”：在反序列化前先尝试 JSON 解析。

重写缓存驱动的 get() 方法，在调用父类逻辑后，对返回值做二次判断：若结果为字符串且以 { 或 [ 开头，尝试 json_decode($value, true)
不要直接修改框架源码；应在自定义驱动中继承 think\cache\driver\File（或其他对应驱动），覆盖 doRead() 或 get()
注意：TP6.1+ 的 TagSet 缓存键结构有变，老缓存中的 tag 文件可能被忽略，需同步迁移 tag 数据或清空 tag 缓存

File 驱动缓存文件结构不兼容：升级后 `runtime/cache/` 下文件读不出来

TP5.x 的 File 驱动把缓存内容直接写成纯文本（JSON 或 serialize 后的字符串），而 TP6+ 默认启用 data_serialize 配置，并在文件头写入 8 字节签名（\x00\x00\x00\x00\x00\x00\x00\x01），用于标识序列化方式。旧文件无此签名，导致 doRead() 直接跳过解析。

关键不是“改文件”，而是“改读法”——让驱动对无签名文件降级处理。

在自定义 File 驱动的 doRead() 中，先用 fread($fp, 8) 读头；若不等于签名，则将文件指针重置到开头，按原始字符串方式读取并尝试 unserialize() 或 json_decode()
避免全局开启 data_serialize = false：这会让所有新写入也退回到 JSON，丧失对资源对象、闭包等的支持
路径上注意：TP6 默认缓存子目录深度为 2（xx/yy/xxx.php），而 TP5 是扁平结构；迁移脚本需按 hash 重分布旧文件，否则命中率归零

Redis 驱动 key 前缀与序列化混用：`cache:xxx` 里的数据变成乱码

TP5.1 Redis 驱动默认用 setex 写入纯字符串（JSON），TP6+ 则默认用 set + serialize()，且 key 自动加 think: 前缀。结果就是：同一业务 key（如 user:123）在 Redis 里实际存了两份，一份是 cache:user:123（TP5），一份是 think:user:123（TP6），且内容编码不同。

PHP

编写健壮的PHP代码，规避类型转换陷阱、数组怪癖及常见安全漏洞。

下载

不能靠删旧 key 解决——线上可能有混合读写，必须让新驱动能读旧 key。

在 Redis 驱动配置中设 'prefix' => 'cache:'，与旧版一致；同时关闭 'serialize' => false，强制走 JSON 流程
更稳妥的做法是双写过渡：升级期间，新代码同时写 think: 和 cache: 两套 key，读取时优先读 think:，未命中再查 cache:
Redis 的 ttl 值不会因序列化方式改变而丢失，但 PHPRedis 扩展版本低于 5.3.4 时，serialize 写入的二进制数据可能被截断，务必检查扩展版本

自定义驱动中如何安全判断数据格式

别依赖文件后缀或 key 名称猜格式，真正可靠的只有内容本身。TP6 的 serialize() 输出一定以 O:、a:、s: 等字符开头，而 JSON 一定是 {、[、" 或数字开头。

一个轻量判断函数比 try-catch 更高效：

private function detectAndDecode($raw)
{
    if (is_string($raw) && strlen($raw) > 2) {
        switch ($raw[0]) {
            case 'a': case 'O': case 's': case 'i': case 'd': case 'b':
                return @unserialize($raw);
            case '{': case '[':
                return json_decode($raw, true);
            default:
                return $raw;
        }
    }
    return $raw;
}

这个逻辑要嵌进你重写的 doRead() 或 get() 里，而不是放在业务层。每次缓存读取都走一遍，成本极低，但能兜住绝大多数混合场景。

最麻烦的其实是第三方 SDK 写入的缓存（比如微信 SDK 自己用 file_put_contents 写的），它们既没签名也不遵循框架约定，只能靠人工识别特征字段+正则匹配来救急。这种数据建议升级窗口期手动导出清洗，别指望自动兼容。