composer update 没报错，后台却直接白屏。Composer 只保证依赖约束能解出来，不保证新版本扩展一定兼容当前 Magento、PHP 和其他插件。这个时候一直清缓存通常没有信息增量，先把真实异常拿出来。

先确认是500、502还是200空页面

curl -I https://shop.example.com/admin-path/
tail -f var/log/exception.log var/log/system.log
journalctl -u php-fpm --since "10 minutes ago"

500 重点看 PHP 异常；502 看 PHP-FPM 是否崩溃或超时；200 但 body 为空，检查 fatal error 是否被输出配置吞掉。生产环境不要打开公开报错页面，日志里按请求时间找。

直接diff更新前后的composer.lock

如果目标只是升级一个支付模块，lock 却变了几十个框架包，问题范围已经失控。列出新增、删除和变更版本，再按异常中的类名回到具体包。

composer show --direct
composer why vendor/package
composer why-not vendor/package target-version
composer validate

Class not found 先查包、autoload 和模块状态；方法签名不兼容或参数类型错误，通常是扩展与框架版本不匹配。不要直接改 vendor 里的方法，应该锁回兼容版本、升级扩展或应用正式 patch。

依赖确认没问题，再重建generated和静态资源

旧 interceptor/proxy 引用了更新前构造函数时，重新编译确实能修。但如果 setup:di:compile 自己报错，就继续修 DI 或依赖，不能删除 generated 后绕过编译上线。

多节点还要滚动重载 PHP-FPM/opcache。代码已经切到新 release，旧 worker 仍执行旧字节码时，会出现某些节点正常、某些节点白屏。

恢复后在干净目录用 lock 文件执行 composer install，再完成编译和基础回归。把这次确切的包版本和修复提交到版本控制，保证下一台机器能重复部署，而不是只在出问题的服务器上手工修好。