生产环境禁止执行 composer update，因其会忽略 composer.lock、按 composer.json 重算整棵依赖树，可能引入不兼容变更或解析失败；应严格使用 composer install 确保版本一致，并通过 composer outdated --direct --minor-only 评估升级、配合 --with-dependencies 精准更新。
别在生产环境跑 composer update，它不升级，它重算——而且算得更严、更慢、更易崩。 平滑升级不是靠命令 magic，而是靠提前暴露冲突、锁定可验证状态、用 composer.lock 控制每一台机器装什么。
为什么 composer update 在生产环境必然翻车
它会忽略 composer.lock，按 composer.json 里松散的约束（比如 "^2.0"）重新求解整棵树。结果可能是：monolog/monolog 从 2.10.0 升到 2.12.0，但后者删了你代码里直调的 Logger::setHandlers()；guzzlehttp/guzzle 跳到 7.9.0，而它要求 psr/http-client ≥ 1.0.3，但你的某个 dev 工具锁死了 1.0.1——Composer 2.x 的 SAT 求解器不会妥协，直接报错 Your requirements could not be resolved。
- 所有
require-dev包也会被重算，phpunit/phpunit可能升到 11.x，而你的测试用例还依赖已被删的--colors参数 - 私有包的 dist URL 可能失效，因为新版本没推 tag 或镜像源没同步
- PHP 版本兼容性被绕过：即使你本地是 PHP 8.2，
composer update仍可能装入只支持 8.3 的包（除非显式配config.platform.php）
composer outdated --direct --minor-only 才是升级起点
全量 composer outdated 会淹没你——80 行输出里只有 3 行是你亲手写的 require。加 --direct 过滤掉传递依赖，加 --minor-only（Composer 2.5+ 支持）只看次版本更新，避开主版本跃迁这类高危动作。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 看到
laravel/framework 9.52.5 → 9.53.0 !，立刻停手，运行composer why-not laravel/framework:9.53.0查谁在拦路 - 输出最后一行通常是你的项目名，往上倒着读：某行写着
spatie/laravel-backup v4.0 → requires laravel/framework ^9.0，说明这个包还没适配 9.53.0 - 如果某行末尾带
(conflict with foo/bar >=2.0)，说明foo/bar自己写了conflict字段，Composer 是照章执行，不是 bug
单点升级必须带 --with-dependencies，不是 --with-all-dependencies
想升 laravel/framework？别写 composer update laravel/framework，它只动框架本身，留下 illuminate/support 还卡在 9.x，而新框架要求 10.x，运行时报 Class not found。
- 正确命令是：
composer update laravel/framework --with-dependencies - 它只递归更新该包直系依赖（比如
symfony/http-foundation、guzzlehttp/guzzle），不波及phpunit/phpunit或roave/better-reflection - 不能加引号，不能带
^或~，写成laravel/framework就行 - 如果还报错，说明子依赖链里还有硬冲突，比如
guzzlehttp/guzzle要求psr/http-client ^2.0，而另一个包锁死了1.0.0；此时手动补上：composer update guzzlehttp/guzzle psr/http-client --with-dependencies
镜像配置和平台模拟决定升级是否可控
国内开发者最常踩的坑不是依赖冲突，而是镜像源不兼容或平台配置缺失。Composer 2.x 默认禁用不稳定包，且对 VCS 源支持变弱，repositories 里 type 写成 vcs 会被拒绝。
- 确认镜像源 type 是
composer，不是package或vcs；阿里云、腾讯云镜像已全面支持 Composer 2.x，但旧配置可能残留 - 升级 PHP 前，先在
composer.json里加："config": { "platform": { "php": "8.3" } }，强制 Composer 按目标环境解析依赖 - CI 流水线中禁用
composer update，只允许composer install --no-dev；--no-dev不是性能优化，是安全隔离——避免phpstan或infection这类工具意外升级影响运行时 - 每次
composer update后，立刻执行composer dump-autoload -o，再用php -r "echo class_exists('App\Models\User') ? 'ok' : 'fail';"确认 PSR-4 映射没断
真正容易被忽略的，是那些不报错却埋雷的 Deprecated: 警告——它们不崩，但下个主版本就删。升级后别只跑测试，启动服务，触发几个核心请求，翻日志看有没有 Deprecated: The "xxx" method is deprecated；这些才是下次升级时最先倒下的那块砖。
