composer install 不升级任何包，它只按 lock 文件还原依赖树；所谓“升级”需先修改 composer.json 或 composer.lock，再执行 install 才生效。
composer install 不升级任何包，它只按 lock 文件还原依赖树——所谓“升级”，本质是先改 composer.json 或 lock 文件，再让它执行安装。
为什么运行 composer install 后依赖版本没变
这是 composer install 的设计本意：它完全忽略 composer.json 中的版本约束，只读取 composer.lock 里记录的精确版本号和哈希值，然后从 Packagist 或镜像源下载对应 zip 包或 clone 对应 commit。哪怕你把 composer.json 里的 "monolog/monolog": "^2.0" 改成 "^3.0"，只要不运行 composer update 或手动改 composer.lock，install 就永远装旧版。
- CI/CD 流水线必须用
install，否则每次构建都可能拉到不同版本，破坏可重现性 - 本地开发中改了
composer.json却没生效？大概率是忘了跑composer update或漏提交composer.lock - 如果
composer.lock被删了，install会报错：“No composer.lock file present” —— 它不会自动生成，必须靠update重建
composer install 如何“间接升级”依赖
真正让 install 装上新版本的唯一方式，是让 composer.lock 先变。这通常有三种路径：
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 运行
composer update vendor/package-name，更新指定包并重写 lock 文件，再install就会装新版本 - 手动编辑
composer.lock（不推荐）：改其中"packages"或"packages-dev"下某包的"version"和"source"字段，但极易出错且无法校验依赖一致性 - 团队协作中别人提交了更新后的
composer.lock，你git pull后直接composer install，就完成了“升级”——这是最安全、最常用的向后兼容升级方式
PHP 版本变更后 composer install 失败怎么办
当系统 PHP 从 8.1 升到 8.2，而 composer.lock 里仍记着只兼容 8.1 的包版本时，install 会失败，报类似 "Your requirements could not be resolved" 的错误。这不是 lock 文件损坏，而是 Composer 在安装前做了平台兼容性检查。
- 先确认
composer.json的"platform"段是否已更新，例如："php": "8.2" - 运行
composer update --lock：它不改composer.json，只根据当前 PHP 环境重新解析 lock 文件，剔除不兼容版本 - 不要用
--ignore-platform-reqs硬装——它绕过检查，可能导致运行时 fatal error，尤其在用了match表达式或enum的包里 - 升级后务必验证：运行
composer show php确认实际加载的 PHP 版本，再检查关键类是否能 autoload
Composer 2.5+ 对 install 的兼容性影响
Composer 2.5+ 不改变 install 的行为逻辑，但它强化了配置校验——如果 composer.json 里残留 minimum-stability 或 prefer-stable，install 根本不会启动，直接报 Invalid composer.json 错误。
- 错误不是发生在安装阶段，而是在读取配置的第一时间，所以加任何参数（如
--no-plugins）都无效 - 必须用
composer validate --no-check-all扫出问题字段，手动删除；vendor-dir和bin-dir若含${HOME}这类变量，也会被拒绝 - 老项目从 Composer 1.x 升上来，常见坑是脚手架模板带过时字段，建议用
grep -n "minimum-stability\|prefer-stable" composer.json快速定位
真正决定升级结果的，从来不是 install 命令本身，而是它背后那个被信任的 composer.lock 文件——它的内容是否准确、是否与当前环境匹配、是否经过团队共识，比命令怎么敲重要得多。
