必须用composer install：多人协作、ci/cd构建、生产部署时，它严格按composer.lock还原精确版本和哈希值，确保可复现；update会重解依赖导致版本漂移和线上崩溃。

依赖管理的核心不是“装什么”，而是“谁在什么时候、以什么精度决定装哪个版本”——composer install 和 composer update 的行为差异，直接决定了项目是否可复现、是否可协作、是否会在上线时突然崩掉。

什么时候必须用 composer install，而不是 composer update

只要涉及多人协作、CI/CD 构建、生产环境部署，composer install 是唯一安全选项。它完全忽略 composer.json 里的版本“愿望”，只按 composer.lock 中记录的精确版本和哈希值还原依赖树。

• composer update 会重新运行 SAT 求解器，尝试找最新兼容组合——哪怕只改一行 composer.json，也可能把 guzzlehttp/guzzle 从 7.4.5 升到 7.9.0，而后者可能悄悄弃用了你正在用的 HandlerStack::push() 方法
• CI 流水线里漏写 --no-dev？composer install 仍会装 phpunit/phpunit，不仅浪费时间，还可能因 sebastian/exporter 版本锁死，间接卡住 symfony/console 更新
• 本地 composer.lock 没提交？Git 拉下来的人执行 composer install 时，会 fallback 到 composer.json 解析——此时没人能保证装出来的是同一套东西

require 和 require-dev 划分错误的典型后果

错放一个包，轻则多装 30MB 无用代码，重则引发隐性冲突。关键判断标准只有一条：这个包的类或功能，是否在 PHP 进程启动后、请求处理中被实际调用？

• 进 require：所有运行时必需的，比如 doctrine/dbal（迁移命令要执行）、monolog/monolog（日志写入）、laravel/framework（路由和容器）
• 进 require-dev：仅开发期使用的，比如 phpunit/phpunit（测试执行）、roave/security-advisories（安装时做冲突拦截，本身不提供任何类）、laravel/pint（代码格式化）
• 危险中间地带：symfony/var-dumper 看似调试用，但如果你在生产环境用 dd() 或 dump()，它就是运行时依赖；否则就该进 require-dev

解决冲突时，为什么 composer why-not 比删 vendor 有用十倍

报错信息里写的 don't install guzzlehttp/guzzle:8.0.0 不是结论，只是症状。真正要找的是“谁在拦路”。composer why-not 输出的是阻塞链，从底往上读才对：

Discussion Composer

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

下载

• 最后一行是你自己写的 "guzzlehttp/guzzle": "^7.0"（根约束）
• 倒数第二行可能是 some/package v2.1.0 requires guzzlehttp/guzzle ^6.0（间接依赖）
• 再往上可能是 another/tool v1.5.0 requires some/package ^2.0（更深一层）
• 如果输出为空？先检查 require-dev ——很多冲突来自 mockery/mockery 锁着老版 sebastian/exporter，进而拖死整个 symfony 生态

别信 composer.json 里写的“我想装啥”，用 composer show --tree | grep "guzzlehttp/guzzle" 看 lock 文件里真实拉进来的到底是哪个版本、由谁引入。

升级单个包时，--with-dependencies 不是可选项，是必须项

执行 composer update monolog/monolog 默认只更新 monolog/monolog 自身，不碰它的子依赖。但新版本 monolog/monolog:^3.0 可能要求 psr/log:^3.0，而旧 lock 文件里还锁着 psr/log:^1.0——结果就是命令成功退出，但运行时报 Class not found: Psr\Log\LoggerInterface。

• 正确做法：composer update monolog/monolog --with-dependencies，让 Composer 主动升级其直系依赖
• 降级跨主版本（如从 ^8.0 切回 7.4.5），必须在 composer.json 里写死 "guzzlehttp/guzzle": "7.4.5"，不能只写 "^7.0"，否则求解器可能选 7.9.0 而非你想要的修复版
• 执行后立刻 git diff composer.lock，确认改动范围可控——如果看到几十个包被修改，说明没加 --with-dependencies 或约束太松

最常被忽略的一点：锁文件里记录的 platform 配置（如 PHP 版本）必须和 composer.json 中 config.platform.php 一致，否则 composer install 在不同 PHP 环境下可能解析出完全不同的一套依赖。