Composer install 不会降级已安装包，因其严格按 composer.lock 复现依赖状态；降级需用 require 指定版本或 update 配合修改 composer.json，手动改 lock 文件不可靠且易出错。
为什么 composer install 不会降级已安装的包？
Composer 默认只升不降：它读取 composer.lock 中记录的精确版本，install 命令严格复现该状态，哪怕 composer.json 里写的版本约束更宽泛（比如 "monolog/monolog": "^2.0"），也不会主动把已锁在 3.0 的包拉回 2.x。
换句话说，降级不是“默认行为”，而是需要你明确表达意图并打破 lock 文件的权威性。
用 composer require 强制指定旧版本
这是最直接、最可控的降级方式——相当于告诉 Composer：“我现在就要这个具体版本，不管之前锁的是啥”。Composer 会自动更新 composer.json 和 composer.lock，并重装依赖。
- 降级单个包：
composer require monolog/monolog:2.9.2 - 降级并限制版本范围（避免意外升级）：
composer require monolog/monolog:^2.9 - 如果包已存在，加
--no-update仅改composer.json，再手动composer update monolog/monolog
注意：如果旧版本与当前其他依赖冲突（比如某包要求 php >=8.1，而你想降级的包只支持到 PHP 7.4），Composer 会报错并中止，不会静默跳过。
用 composer update 配合版本约束降级
当你想批量降级或按语义化规则收缩版本范围时，先改 composer.json，再执行 update 更合适。例如：
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 把
"guzzlehttp/guzzle": "^7.5"改成"guzzlehttp/guzzle": "^6.5"，再运行composer update guzzlehttp/guzzle - 想确保所有子依赖也回退到兼容旧主包的版本，加
--with-all-dependencies：composer update monolog/monolog --with-all-dependencies
⚠️ 风险点：如果 lock 文件里还存着旧版子依赖的记录，而新约束又允许更高版本，update 可能反而升级——所以务必确认 composer.json 的约束足够紧，且必要时先删掉 composer.lock 再跑 update（慎用，会影响协作一致性）。
手动编辑 composer.lock 是下策
虽然你能直接改 composer.lock 里的 version 和 dist/sha256，但 Composer 不认可这种“绕过校验”的操作。下次任意 install 或 update 都会把它覆盖掉，甚至报 Root package '<code>vendor/name' cannot be found in lock file 这类校验失败错误。
真要这么做，必须同步修改 composer.json 对应行，并用 composer install --no-scripts --no-plugins 强制以 lock 为准重装——但这极易引发依赖树断裂，只建议在调试极端兼容问题时临时使用。
真正容易被忽略的是：降级后没跑测试就提交了 lock 文件。很多兼容性问题（比如 API 删除、返回类型变更）只在运行时暴露，光看安装成功没用。
