composer update 不是升级而是重算整棵依赖树，会按 composer.json 约束重新拉取所有满足条件的最新包，不区分补丁、功能或破坏性变更，可能引发兼容性问题。
直接跑 composer update 不是更新，是重算整棵依赖树——它可能把 symfony/http-foundation 从 6.4.0 升到 6.4.3，但顺手把 psr/cache 从 3.0.0 换成 3.0.1，而后者在 PHP 8.2 下触发了扩展行为变更，接口开始静默超时。
为什么 composer update 不等于“升级”
它丢弃 composer.lock，按 composer.json 里写的约束（比如 "^6.0"）重新拉取所有满足条件的最新包，不区分补丁、功能还是破坏性变更。CI 能过、本地能跑，不代表线上没问题。
- 常见错误现象：
Class not found、Undefined constant、日志字段名突变、HTTP 客户端默认超时从 30s 缩到 5s - 它连
require-dev里的phpunit/phpunit也一起升，新版可能已移除--colors参数，CI 脚本直接退出 - 如果
config.platform.php设为"8.1.0"，但你本地是 PHP 8.2，Composer 仍按平台配置选包，装完才发现ext-gd渲染逻辑已改
composer outdated 才是你该先敲的命令
它不改任何文件，只告诉你哪些包有新版本、是否含主版本跃迁、有没有标 [security]。
- 加
--direct：只看composer.json显式声明的包，过滤掉子依赖噪音 - 加
--patch-only（Composer 2.5+）：聚焦1.2.3 → 1.2.4这类安全修复，避开次版本风险 - 看到带
!的行（如laravel/framework 9.52 → 10.38 !），别急着update，先跑composer why-not laravel/framework:10.*查谁在拦路 - 安全漏洞不靠
outdated发现，得用composer audit或集成 CI 扫描
只升一个包，但子依赖卡在旧版？用 --with-dependencies
composer update monolog/monolog 默认只更新 monolog/monolog 本身，它依赖的 psr/log 或 symfony/polyfill-php80 仍按 composer.lock 里旧 SHA 安装。
- 显式带上
--with-dependencies：更新该包 + 它**直接声明**的依赖（如"psr/log": "^1.1"） - 用
--with-all-dependencies：递归更新整个依赖子图，包括间接依赖（如psr/log的依赖 php 扩展要求） - 注意：如果其他包硬锁了同一依赖的旧版（比如
laravel/framework锁symfony/event-dispatcher ^5.4），--with-all-dependencies会直接报冲突，而非跳过 - 执行前务必
git add composer.lock && git commit -m "save lock before bulk update"，否则出问题没法回滚
升级后类找不到？大概率是 autoload 没刷新
90% 的 Class not found 不是包没装对，而是自动加载映射没重建。
- 运行
composer dump-autoload -o生成优化后的静态映射（开发环境也建议加-o） - 如果项目用了自定义 PSR-4 命名空间，检查
composer.json的autoload段是否被升级脚本意外覆盖或缩进错乱 - 执行
composer validate --strict快速检测composer.lock是否合法；若失败，别手修，直接删掉composer.lock和vendor/，再跑一次composer install
真正麻烦的不是命令怎么写，而是 composer.lock 里某条记录被手动编辑过、某个 replace 规则和新包冲突、或者 platform 配置和实际 PHP 版本差了小数点后一位——这些细节不会报错，只会让更新结果偏离预期。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
