composer update 默认重算整个依赖图、忽略 composer.lock、按 composer.json 约束安装最新兼容版本，是“重新协商”而非安全更新，生产环境误用会引入运行时不确定性。
直接说结论：composer update 默认会重算整个依赖图、忽略 composer.lock、按 composer.json 中的版本约束安装最新兼容版本——这不是“更新”，是“重新协商”，生产环境误用等于主动引入不确定性。
为什么 composer update 后行为突变？
它不读 composer.lock，而是重新解析所有约束（比如 "guzzlehttp/guzzle": "^7.2"），然后从 Packagist 拉取当前满足条件的最新版（可能是 7.9.0 → 7.9.1）。哪怕只是补丁升级，也可能触发底层行为变更：
- HTTP 客户端默认超时从 30s 缩短为 5s
- 日志格式字段名从
context改成extra - 单元测试中
expectExceptionMessage()匹配逻辑收紧
这些变化不会报错，但会在运行时静默生效。CI 通过、本地能跑，上线后才暴露。
composer update 必须带包名或明确范围
不加参数的 composer update 是运维事故高发操作。真实维护中只允许以下三种写法：
- 只升一个包：
composer update monolog/monolog（不加--with-dependencies，Composer 2.2+ 已移除该选项） - 升一组相关包：
composer update laravel/framework illuminate/support illuminate/http - 升开发依赖专用命令：
composer update --dev phpunit/phpunit nunomaduro/collision
禁止出现 composer update --no-dev 这类模糊指令——它仍会更新所有 require-dev 下的包，包括你没列出来的。
升级前必须看 composer outdated --direct
这个命令不改任何文件，只告诉你哪些显式声明的依赖有新版可升，且暴露三类关键风险：
- 安全更新：标有
[security]的行，如guzzlehttp/guzzle 7.8.1 → 7.8.2 [security] - 主版本跳变：如
symfony/console 5.4.39 → 6.4.0，说明约束已允许升 6.x，但你未必准备好 - 约束失效：某包在
composer.json里写了"^2.0"，但outdated不显示它——大概率被replace或require-dev干扰了依赖图
注意：如果 outdated 输出为空，先检查是否启用了 "minimum-stability": "stable" 和 "prefer-stable": true，它们会过滤掉所有预发布版本，导致“有新包也看不见”。
升级后 vendor/autoload.php 失效？别急着删 vendor
90% 的“类找不到”不是包没装对，是自动加载映射没重建。执行：
composer dump-autoload -o
即可生成优化后的静态映射。如果项目用了自定义 PSR-4 命名空间，顺手检查下 composer.json 的 autoload 段是否被意外覆盖或缩进错乱——升级过程不会动它，但手动编辑时容易手抖。
真正麻烦的是 composer.lock 被改写后没人 review。它记录的不只是版本号，还有每个包的 commit hash、PHP 扩展要求、平台配置。一次没看清 diff 的提交，可能让下周的 CI 构建在 PHP 8.3 环境下直接失败。
