发布或 PHP 升级后页面报 Unable to unserialize value，常见原因是新旧节点使用不同序列化器、多个环境共享 Redis DB/前缀，或缓存值写入中断。它通常发生在 cache，而不是 Session；清错 Redis 库会导致用户全部退出。
固定复现条件
记录报错 key 前缀、Redis DB、节点、PHP 版本和发布批次，不输出缓存正文。比较正常与异常节点的 env.php 缓存配置摘要、phpredis/igbinary 扩展和构建版本。
php -v
php -m | grep -Ei 'redis|igbinary|msgpack'
grep -nA30 "'cache'" app/etc/env.php
redis-cli INFO keyspace
redis-cli --scan --pattern 'zc:*' | head
sha256sum composer.lock app/etc/config.php根据证据定位
仅一台节点失败说明运行时或代码不一致；所有节点在同一 key 失败，可能是遗留或损坏值；测试与生产 key 前缀相同则属于环境串用。Session、Cache、FPC 常使用不同 DB，必须先确认连接。
修复与回滚
统一 PHP 扩展和序列化配置，为每个环境设置独立前缀或 Redis DB。确认是可再生 cache 后，只清目标缓存池并观察回填；不要执行无范围 FLUSHALL，也不要直接删除未知 Session key。
验收
连续命中所有节点，页面、后台、Cron 和消费者均无反序列化异常；缓存重新生成后命中率恢复，客户登录状态不受影响。
生产环境操作前的检查
处理“Magento 2 Redis 缓存报 Unable to unserialize value”前，先记录 Magento 版本、部署模式、问题 Store View、复现时间和最近发布。所有 SQL 默认先执行 SELECT；写操作、目录清理、服务重启和配置切换必须确认范围、保留备份并准备回滚。多节点环境还要核对构建版本、app/etc/env.php 配置摘要和实际流量节点。
php bin/magento --version
php bin/magento deploy:mode:show
php bin/magento maintenance:status
php bin/magento indexer:status
php bin/magento cache:status命令应由 Magento 文件所有者在项目根目录执行。不要在生产高峰同时运行全量索引、静态部署和数据修复；涉及客户、支付、税费、库存或订单的变更，应先在脱敏数据副本验证。
建立可比较的排查记录
每次实验只改变一个变量，记录操作前值、命令、开始与结束时间、结果和回滚方式。至少准备一个正常对象和一个异常对象；旧对象恢复而新对象仍能复现，说明根因尚未消除。
| 检查层 | 证据 | 通过标准 |
|---|---|---|
| 入口 | URL、状态码、请求 ID、节点 | 路由与协议一致 |
| 应用 | 异常堆栈、模块、作用域 | 无新异常且可重复 |
| 数据 | 主键、时间、关联行数 | 关系完整无重复副作用 |
| 业务 | 正常、失败与重试路径 | 最终状态一致 |
修复后的观察窗口
上线后至少观察一轮 Cron、队列和索引周期，并在两台节点、无痕浏览器与目标 Store View 重复验证。临时调试日志必须脱敏，确认错误率、响应时间和数据量稳定后及时关闭。
