应仅在明确目标且评估风险后执行 composer update；常见场景包括验证 bug 修复、应对 CVE、升级 PHP 大版本或主动重构组件；它重算依赖而非简单更新，CI/CD 中必须用 install 保证可重现。
Composer 不会在你敲完命令后“立刻更新”所有包——它只在明确触发时重算依赖图，且默认行为是破坏性的。盲目执行 composer update 是生产事故高发动作。
什么时候该跑 composer update？
不是“有新版本就该升”，而是“有明确目标且已评估风险时才动”。常见合理场景包括：
- 本地开发中，想验证某个包的新版是否解决你遇到的 bug（先
composer outdated确认存在候选版本） - 安全扫描报告某依赖含 CVE，且你已确认修复版本兼容当前代码（查
composer show vendor/package看当前版本，再比对 CVE 修复公告） - 升级 PHP 大版本前，需批量调整依赖以满足新版运行时要求（如从 PHP 8.0 → 8.2，
monolog/monolog可能需升到 v3+） - 项目重构阶段，主动替换底层组件（如把
guzzlehttp/guzzle换成symfony/http-client），需同步清理旧依赖
注意：composer update 默认丢弃 composer.lock 并重算整棵树——它不保留历史决策，也不做兼容性兜底。
composer update 和 composer install 的本质区别
这两个命令根本不是“更新 vs 安装”的关系，而是“重算 vs 复现”：
-
composer install：只读composer.lock，按里面记录的 exact version + SHA256 下载包，跳过远程元数据拉取，保证构建可重现 -
composer update：忽略composer.lock，重新解析composer.json中所有require和require-dev的版本约束（如"^2.8"），向 Packagist 请求最新匹配版本，再递归解依赖
CI/CD 流水线里必须用 composer install；如果误写成 update，每次构建可能拉到不同子版本，导致环境漂移。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
为什么 composer update 后没报错，但线上出问题？
因为很多变更不会触发语法错误或异常，而是在运行时静默改变行为：
- 日志库升级后
Logger::error($msg, $context)参数顺序被调换，你代码里传参方式没改，结果$context被当成了$msg - HTTP 客户端默认超时从 30s 缩短为 5s，你没显式设 timeout，某些慢接口直接失败
- 某个 polyfill 包更新后，悄悄启用 PHP 8.1+ 特性，但在 PHP 8.0 环境下触发 fatal error
这些都不是 Composer 的 bug，而是语义化版本（SemVer）允许的“非破坏性变更”——但对你的业务逻辑就是破坏性的。所以 composer update 后必须跑完整回归测试，不能只看 phpunit 是否通过。
想升一个包，又怕牵连其他依赖？用对参数
默认 composer update monolog/monolog 只更新该包本身，它的子依赖（比如 psr/log）仍按 composer.lock 里的旧版本装，容易埋下兼容隐患：
- 加
--with-dependencies：更新目标包 + 它在composer.json中**直接声明**的依赖（如"psr/log": "^1.1"） - 加
--with-all-dependencies：递归更新整个子图，包括间接依赖（如psr/log所依赖的php扩展要求） - 但注意：若其他包硬锁了同一依赖的旧版（如
laravel/framework锁symfony/event-dispatcher ^5.4），--with-all-dependencies会直接报冲突，不会跳过
真正安全的做法是：先 composer outdated monolog/monolog 查可选版本，再手动编辑 composer.json 改约束，最后 composer update --lock（仅更新 lock 文件）或 composer install 验证。
最常被忽略的一点：你看到的 composer.lock 里每个包的 time 字段，是该版本在 Packagist 上的发布时间，不是你本地更新的时间。想确认“这个包到底哪天装进来的”，得去 vendor/ 目录看文件修改时间——别信 lock 文件里的 time。
