直接运行composer update等于开盲盒，因其会丢弃composer.lock并按composer.json松散约束重算整个依赖树，可能导致主版本跃迁、接口变更及require-dev工具意外升级，引发静默故障。
为什么直接composer update等于开盲盒
它不升级，它重算——丢掉composer.lock，按composer.json里松散的版本约束（比如"^8.0"）重新解析整棵依赖树。结果可能是：phpunit/phpunit从10.5跳到11.0（--colors参数被删），symfony/http-kernel悄悄升到7.0（HttpKernel::handle()签名变了），而你的CI脚本和日志收集器还在调旧接口。更糟的是，它连require-dev里的工具也一锅端，根本不管这些是否参与运行时。
composer outdated --direct --minor-only才是升级起点
别扫全量列表，先聚焦你亲手写的那几行require。加--direct过滤掉传递依赖噪音，加--minor-only（Composer 2.5+）只看次版本更新（如2.9.0 → 2.10.1），避开主版本跃迁这类高危动作。看到带!标记的行（如guzzlehttp/guzzle 7.4.5 → 7.5.0 !），立刻停手，运行composer why-not guzzlehttp/guzzle:7.5.0查谁在拦路——大概率是某个require-dev包锁死了旧版。
单点升级必须带--with-dependencies，不是--with-all-dependencies
想升laravel/framework？别写composer update laravel/framework，它只动框架本身，留下一堆子依赖卡在旧版（比如illuminate/support还是9.x，而新framework要求10.x），运行时报Class not found。正确命令是：composer update laravel/framework --with-dependencies。它只递归更新该包直系依赖，不波及无关模块。但注意：它不会跨主版本，想升monolog/monolog到3.x，必须先手动把composer.json里"^2.0"改成"^3.0"。
验证不是跑测试就完事，要盯三处静默失效点
升级后光跑phpunit不够，很多问题藏在自动加载、缓存和HTTP头里：
- 立刻执行
composer dump-autoload -o，再用php -r "echo class_exists('App\Models\User') ? 'ok' : 'fail';"确认PSR-4映射没断 - 清空框架缓存：
php artisan config:clear && php artisan cache:clear（Laravel）或对应命令，避免旧配置掩盖问题 - 抓一个真实HTTP响应，检查
Status、X-Powered-By、Content-Security-Policy头是否突变——某些框架升级后默认开启CSP或强制HTTPS重定向，前端会报301循环或CORS失败
最易被忽略的是Deprecated:警告：它们不报错，但下个主版本就删。启动服务后快速触发几个核心请求，翻storage/logs/laravel.log或var/log/dev.log，比等上线后报警强十倍。
