composer update 是重装整个依赖树而非升级项目，会忽略 composer.lock 重新解析所有依赖，可能引入不兼容变更；仅在 lock 丢失、测试新版本、修改版本约束或 CI 需最新合法组合时使用。

直接说结论： composer update 不是“升级项目”，而是“重装整个依赖树”——它会忽略 composer.lock，重新解析所有 require 和 require-dev，拉取符合版本约束的最新匹配包，可能引入不兼容变更。

什么时候必须用 composer update

只在以下真实场景中执行：

• 你刚接手一个老项目，composer.lock 丢失或严重过时，且无法从 Git 恢复
• 你明确要测试某依赖（比如 monolog/monolog）的下一个主版本是否兼容，用 composer update monolog/monolog 单独更新
• 你修改了 composer.json 中的版本约束（例如把 "php": "^7.4" 改成 "^8.1"），需要让 Composer 重新计算兼容组合
• CI 环境里跑集成测试前，需确保使用的是当前 composer.json 下能解析出的最新合法依赖组合（但更推荐用 composer install + 提交 lock 文件）

composer update 默认行为和危险点

它不做“增量更新”，而是清空已安装包，再从头安装。常见误操作后果：

Discussion Composer

围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par

下载

• 没加任何参数时，composer update 会更新 所有 包（包括 require-dev），哪怕你只想修一个 bug
• 它无视 composer.lock 的锁定版本，哪怕 lock 文件里记录的是稳定版，update 后可能装上带 BC break 的预发布版（如 v3.0.0-beta2）
• 如果本地 PHP 版本低于某个新包要求的最低版本（比如新 symfony/console 要 PHP 8.1），命令会失败并报错 Your requirements could not be resolved
• 网络波动或 Packagist 临时不可用时，update 可能卡在某个包的 metadata 获取阶段，无超时提示

安全更新的替代做法：优先用 composer install

95% 的日常开发根本不需要 composer update。正确流程是：

• 团队协作时，只提交 composer.json 和 composer.lock，其他人运行 composer install —— 它严格按 lock 文件安装，结果确定、可复现
• 想升级单个包？改 composer.json 里的对应版本号（如 "guzzlehttp/guzzle": "^7.5" → "^7.8"），再运行 composer update guzzlehttp/guzzle
• 检查哪些包有安全更新？用 composer audit（Composer 2.5+）或 composer security-check（旧插件），它们不改依赖，只报风险
• CI/CD 流水线里禁止无参数 composer update，否则每次构建都可能得到不同依赖，破坏构建稳定性

真要用 composer update 时的底线操作

如果非用不可，必须带上约束和开关：

• 加 --with-dependencies 确保子依赖也被重新解析（默认不触发）
• 加 --no-dev 避免更新开发依赖（上线环境部署时必加）
• 加 --dry-run 先看它打算装什么，确认无高危变更再执行
• 加 --prefer-stable 强制跳过 alpha/beta/rc 版本（除非你主动需要）
• 执行前手动备份 vendor/ 和 composer.lock，尤其在生产分支上

最常被忽略的一点：update 后生成的 composer.lock 文件必须提交到 Git。否则下次别人 install 就会回到旧状态，你这次 update 彻底白做。