PHP中unserialize()报错主因是类未定义或自动加载未就绪；基础类型需确保序列化字符串合法；不可信数据应禁用unserialize()改用JSON；session仅恢复$_SESSION内容，对象需__wakeup()重建状态；缓存取值后须手动反序列化。
PHP 中用 unserialize() 恢复变量时为什么报错？
直接调用 unserialize() 解包数据，最常见的失败不是格式不对，而是类定义缺失或自动加载未就绪。PHP 在反序列化对象时，会尝试实例化原类 —— 如果此时类还没被 include 或没被自动加载器注册，就会抛出 Class not found 错误，甚至静默失败（取决于错误报告级别）。
- 确保反序列化前，所有涉及的类已通过
require或自动加载器可用；__autoload()已废弃，优先用spl_autoload_register() - 如果只是恢复数组、字符串等基础类型，不涉及对象，
unserialize()本身是安全的，但必须确认输入是合法的序列化字符串 —— 被截断、编码损坏、混入空格都会导致返回false - 生产环境慎用
unserialize()处理不可信数据，它存在反序列化漏洞风险；若来源不可控，改用json_decode()+json_encode()更稳妥
用 session_start() 后变量自动恢复，但值不对？
PHP 的 session 并非“自动还原全部变量”，它只在 session_start() 后把 $_SESSION 数组从存储（文件、Redis 等）中反序列化加载进来。你写进 $_SESSION['user'] 的值能回来，但全局变量、局部变量、对象实例不会自动复活。
-
$_SESSION里的内容默认用php_serialize方式存，可通过ini_set('session.serialize_handler', 'php_serialize')显式设置，避免与旧版本兼容问题 - 如果存的是对象，且该对象实现了
__wakeup()，反序列化后会自动调用它 —— 这里常被用来重建数据库连接或重置过期状态，但别在里面做耗时操作 - 注意 session 生命周期：
session.gc_maxlifetime控制有效期，超时后数据被清理，再session_start()就只能拿到空$_SESSION
用 var_export() + eval() 恢复变量，为什么危险又难维护？
var_export() 输出的是可执行 PHP 代码，配合 eval() 确实能“还原”变量，但它绕过了类型约束和作用域检查，属于高危操作。
-
eval()执行任意字符串，一旦持久化内容被篡改（比如注入恶意代码），就会直接执行 —— 这比unserialize()的利用门槛还低 -
var_export()对资源（如mysqli连接）、闭包、含循环引用的对象会报错或输出不完整，根本导不出 - 生成的代码依赖当前运行环境的函数/类可见性，换一个 PHP 版本或扩展配置，
eval()可能直接 parse error
Redis / Memcached 存数组后取出来是字符串？
这些缓存服务只认字符串值，PHP 存进去前必须自己序列化，取出来后也必须手动反序列化 —— 它们不做任何 PHP 特有的类型解析。
立即学习“PHP免费学习笔记（深入）”；
- 推荐统一用
serialize()+unserialize()，兼容性最好；若追求性能和跨语言，改用json_encode()+json_decode()，但注意 JSON 不支持资源、资源句柄、NaN、Inf和私有属性 - 用
json_decode($str, true)强制返回关联数组，否则默认是stdClass对象，容易和预期类型不符 - Redis 的
GET命令返回null表示 key 不存在，不是空字符串 —— 别直接unserialize(null)，会警告；先判断返回值是否为false或null
is_string($data) && $data !== '' 判断，比事后 debug 强十倍。 
