composer install 从不升级包，因其设计语义是「确定性复原」：只要 composer.lock 存在，就严格按其中记录的精确版本、哈希及平台信息还原依赖，完全忽略 composer.json 的任何变更。

composer install 不能升级任何依赖——它只按 composer.lock 文件还原，连版本号改了都不管。

为什么 composer install 从不升级包

它的设计语义就是「确定性复原」：只要 composer.lock 存在，就跳过所有解析逻辑，直接从缓存或源解压对应哈希的 zip 包。哪怕你把 composer.json 里 "monolog/monolog": "^3.0" 改成 "^4.0"，install 也完全无视。

常见误操作场景：

Discussion Composer

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

下载

• 改完 composer.json 就跑 composer install，结果 vendor 一点没变
• CI 流水线用 install 却发现装的是旧版，因为 composer.lock 没提交或被覆盖
• 本地 install 失败报 Invalid zip file，其实是 lock 里记录的哈希和缓存文件不匹配

想升指定包？必须用 composer update 加包名

真正能控制升级范围的命令是 composer update，但必须显式指定完整包名，否则默认全量重算。

• 只升 guzzlehttp/guzzle：运行 composer update guzzlehttp/guzzle
• 连带升它直接依赖（比如 psr/http-client）：加 --with-dependencies
• 确认改动范围再执行：先加 --dry-run，例如 composer update monolog/monolog --dry-run
• 避免意外升级间接依赖：不加 --with-all-dependencies，这个参数会让 Composer 打破“最小改动”原则

升级后 autoload 或配置失效的典型原因

不是包没装对，而是 PHP 自动加载和框架缓存没同步更新。

• Laravel 项目必须补上：php artisan config:clear 和 php artisan cache:clear
• 自动加载类找不到？运行 composer dump-autoload -o 强制重建优化版映射
• 某些包含 post-install-cmd 脚本（如生成 bin 文件、写配置），update 会触发，但 install --force-reinstall 才会重跑——后者不改变版本，只刷新状态
• 如果用了 config.platform.php 升级 PHP 版本，必须删掉 composer.lock 再 update，否则平台约束不会生效

容易被忽略的锁文件细节

composer.lock 不只是版本快照，它还固化了平台环境、依赖图结构和包哈希——这些都会影响后续 install 的行为。

• 团队协作中，composer.lock 必须提交 Git；漏掉它，每个人 install 出来的依赖树可能完全不同
• PHP 版本变更后，仅改 composer.json 中的 platform 不够，lock 文件里仍存着旧平台下的解析结果
• CI 环境应始终用 composer install，禁用 update；否则不同构建节点可能因网络、缓存差异装出不一致的依赖