unserialize() 一用就出安全问题，因其会执行类中的__wakeup()、__destruct()等魔术方法，攻击者通过控制反序列化字符串中的类名和属性即可触发任意代码执行，如删文件、连数据库等。
unserialize() 为什么一用就出安全问题
因为 unserialize() 不是解析数据，而是执行类定义里的魔术方法（比如 __wakeup()、__destruct()），只要反序列化字符串里控制了类名和属性，就能触发任意代码逻辑。
常见错误现象：线上突然报 PHP Warning: unserialize(): Error at offset，但更危险的是没报错——攻击者悄悄调用了你写好的 __destruct() 去删文件、连数据库、写 shell。
- 永远别对用户可控输入（如 cookie、GET 参数、HTTP 头）直接调用
unserialize() - 如果必须用，先用
json_decode()替代；实在绕不开，至少加白名单校验类名（见下一条） - PHP 7.4+ 可配合
unserialize($data, ['allowed_classes' => ['MySafeClass']])限制可实例化的类
如何安全地校验反序列化输入
靠正则或字符串匹配类名是无效的——攻击者可以伪造类名、嵌套对象、利用 PHP 类自动加载机制绕过。
真正有效的做法是：在反序列化前，用 preg_match() 提前扫描字符串，确认只含预期字符和白名单类名结构；再配合 allowed_classes 参数双重保险。
立即学习“PHP免费学习笔记（深入）”；
- 检查是否含
O:（对象标识）、C:（自定义类）、R:（引用）等危险标记：preg_match('/[OCR]:[0-9]+:/s', $input) -
allowed_classes必须显式传数组，设为false会禁用所有类（但可能破坏业务逻辑） - 注意：
allowed_classes对内置类（如stdClass）无效，它们始终可反序列化
替代方案：json_decode 比 unserialize 更靠谱吗
是的，但不是万能。JSON 格式天然不支持资源、闭包、私有属性、魔术方法，也就断掉了大多数反序列化链的执行路径。
不过要注意兼容性断层：比如你原来存的是 DateTime 对象，json_encode() 后变成字符串，json_decode() 回来只是普通字符串，不会自动变回对象。
- 迁移时需重写序列化逻辑：用
JsonSerializable接口或手动toArray() - 已有数据不能直接 json_decode —— PHP 的
serialize()输出是二进制格式，和 JSON 完全不兼容 - 性能上，
json_decode()通常比unserialize()快 20%~30%，且更少触发 GC 压力
__wakeup 和 __destruct 被触发的隐蔽路径
你以为没调用 unserialize() 就安全？错。很多框架/组件会在你不注意的地方偷偷反序列化：比如 Laravel 的 SessionHandler、ThinkPHP 的缓存驱动、甚至某些日志记录器对异常对象的处理。
最容易被忽略的是「反序列化后未使用的对象」——只要进了内存，__destruct() 就会在脚本结束时自动执行。
- 用
grep -r '__wakeup\|__destruct' vendor/扫描依赖库，重点关注缓存、会话、队列模块 - 开发时禁用
unserialize()：在php.ini加disable_functions = unserialize（仅限测试环境） - 上线前跑一次
php --ri opcache，确认 opcache 没缓存含危险魔术方法的类定义（某些旧版 opcache 会跳过访问控制检查）
真正麻烦的不是怎么写对，而是你根本不知道哪行代码在哪个时刻、以什么方式把用户输入喂给了 unserialize()。
