serialize()反序列化失败因含Closure、资源句柄、循环引用或不可序列化对象；建议用is_serializable()检测、实现__sleep/__serialize、避免缓存资源型实例。
为什么 serialize() 有时反序列化失败？
不是所有数组都能安全用 serialize() 存入缓存。常见失败场景包括：含 Closure（匿名函数）、资源句柄（如 fopen() 返回的 resource）、循环引用对象，或某些扩展定义的不可序列化类实例。PHP 会直接报 Serialization of 'Closure' is not allowed 这类错误，而不是静默跳过。
实操建议：
立即学习“PHP免费学习笔记（深入）”；
- 先用
is_serializable()（PHP 8.1+）或自定义函数检测——检查数组中每个值是否为is_object($v) && !method_exists($v, '__serialize')或is_resource($v) - 对含对象的数组，确认类已定义
__sleep()（控制哪些属性参与序列化）或 PHP 8.1+ 的__serialize() - 避免缓存
cURL句柄、PDOStatement、Redis实例等——它们本质是资源，必须提前转换为数组或字符串再缓存
用 json_encode() 替代时要注意什么？
json_encode() 更轻量、跨语言，但会丢数据：键名强制转字符串（0 → "0"），null 变空字符串，浮点数精度丢失，不支持资源和资源型对象，且默认拒绝 NaN/INF。
实操建议：
立即学习“PHP免费学习笔记（深入）”；
- 加
JSON_THROW_ON_ERROR标志捕获编码失败，比如含\u0000*\u0000private_prop的私有属性未被jsonSerialize()处理 - 对含中文的数组，务必加
JSON_UNESCAPED_UNICODE，否则变成\u4f60\u597d - 若原数组有整数键但需保持顺序，
json_encode()没问题；但若依赖===判断键类型（如isset($arr[0])vsisset($arr["0"])），就得坚持用serialize()
缓存前手动扁平化嵌套对象
当数组里混着 Doctrine Entity、Laravel Collection 或自定义模型，直接 serialize() 可能因代理对象、延迟加载属性导致体积暴增或反序列化后状态异常。
实操建议：
立即学习“PHP免费学习笔记（深入）”；
- 调用对象的
toArray()方法（Laravel Eloquent）、jsonSerialize()或getArrayCopy()（ArrayObject）提前转纯数组 - 对 Doctrine Entity，用
Doctrine\Common\Util\Debug::export($entity, 1)查看实际可序列化结构，剔除$entity->__initializer__等代理字段 - 写个递归清理函数，过滤掉以
__开头的属性、callable值、resource类型，再序列化
Redis 缓存时 serialize() 和 json_encode() 性能差异
在 Redis 中存 10KB 数组，serialize() 比 json_encode() 快约 15–20%，但反序列化慢 10% 左右；而 JSON 在网络传输体积小 5–10%，尤其开启 Redis 的 zstd 压缩时更明显。
实操建议：
立即学习“PHP免费学习笔记（深入）”；
- 如果缓存只在 PHP 内部用（如 APCu、file cache），优先
serialize()—— 兼容性好、还原度高 - 如果多语言服务共用 Redis（如 Python 要读这个缓存），必须用
json_encode()，并约定好时间戳用 int、布尔统一小写 - 别在
setex前自己 base64_encode() —— Redis 不需要，反而增加体积和 CPU 开销
var_dump(array_walk_recursive($data, function($v) { echo gettype($v).' '; }));，比事后调试快十倍。 
