执行 composer update 后项目崩溃，主因是依赖更新暴露了代码兼容性问题、composer.lock 缺失导致环境不一致、PHP/扩展不满足新依赖要求，或自动加载缓存未刷新。
执行 composer update 后项目崩溃，通常不是 Composer 本身出错，而是它触发了依赖关系的变更，暴露出代码中隐含的兼容性问题或配置疏漏。核心原因在于：更新拉取了新版包，而你的代码、配置或环境尚未适配这些变化。
依赖版本大幅跃迁，破坏向后兼容性
Composer 默认会升级到符合 composer.json 中版本约束的最新可用版本（如 "^8.0" 可能升到 8.5，甚至 9.0 如果锁文件被删或用了 --with-dependencies）。很多主流包（如 Laravel、Symfony、Doctrine）在大版本间会移除废弃方法、更改接口、调整默认行为。
- 例如：Laravel 10 移除了
Illuminate\Support\Facades\Hash::make()的旧参数签名，若代码里还传第三个参数，运行时直接报错 - Symfony 6+ 强制要求 PHP 8.1+，若服务器仍用 PHP 7.4，
composer update成功但php artisan直接无法启动 - 建议：升级前先查目标包的 CHANGELOG 或 Upgrade Guide；生产环境永远用
composer install（基于composer.lock），而非update
composer.lock 被意外忽略或删除
composer.lock 是保障团队和线上环境依赖一致的“契约”。如果它不存在、未提交到 Git，或 CI/CD 流程中误用了 update 而非 install，就会导致不同机器安装不同版本。
- 常见场景：本地开发没提交
lock文件，上线时自动执行composer install—— 但因为没有 lock，Composer 回退为等效于update，装了新版 - 验证方式：对比崩溃环境与正常环境的
vendor/composer/installed.json，看关键包版本是否一致 - 建议：把
composer.lock加入版本控制；CI 脚本明确写composer install --no-dev（不带--ignore-platform-reqs）
平台配置（PHP/扩展）不满足新依赖要求
新版包常提升最低 PHP 版本、强制启用某些扩展（如 ext-intl、ext-opcache），或依赖新语法（如 PHP 8.0 的联合类型）。Composer 安装时可能跳过检查（尤其加了 --ignore-platform-reqs），但运行时立刻失败。
- 典型报错：
Fatal error: Uncaught Error: Call to undefined function mb_strlen()（缺ext-mbstring） - 或
ParseError: syntax error, unexpected token "?", expecting "{"（用了空合并运算符但 PHP 版本太低） - 建议：在
composer.json的"platform"字段声明你实际使用的 PHP 和扩展版本，让 Composer 提前拦截不兼容安装
自动加载冲突或缓存未刷新
更新后类名、命名空间或文件路径可能变动（如包重构目录结构），而 Composer 的 autoloader 缓存（vendor/autoload.php）或 OPcache 仍指向旧映射。
- 现象：类找不到（
Class not found），即使文件明明存在 - 解决步骤：删掉
vendor/autoload.php，运行composer dump-autoload -o重建优化自动加载；重启 Web 服务器或 CLI 环境以清空 OPcache - 进阶排查：用
composer show vendor/package确认实际安装版本；用composer why-not vendor/package:version查谁阻止了某个版本安装
不复杂但容易忽略：一次 update 像按下多米诺骨牌，真正崩的是长期积压的兼容性债务。养成锁文件即部署、升级必查日志、本地复现再上线的习惯，比事后调试快得多。
