composer install 未安装旧版本的根本原因是本地 composer.lock 文件已被覆盖，需用 git checkout 恢复历史版本 lock 文件、清空 vendor 后重装；降级单包须用 composer require vendor/package:version --with-all-dependencies 并验证 composer show 输出。
composer install 为什么没装旧版本？先确认你在用哪个 lock 文件
执行 composer install 后 vendor 里还是新包，甚至报 Class not found，根本原因不是命令失效，而是你本地的 composer.lock 文件早已被覆盖——它根本不是你要回滚的那个历史版本。
运行 git status composer.lock：如果显示 modified 或 not staged，说明它已被改写过。若该旧版 lock 已提交，直接恢复：git checkout HEAD~1 -- composer.lock（或用具体 commit hash）；然后彻底清空 vendor/（rm -rf vendor，Windows 用户请手动删除）；最后再跑 composer install——此时它才真正只读 lock、不碰 composer.json 的约束。
别用 composer update --lock：它只是重写 lock，不会清理 vendor，也不会回退任何代码。
只想降级某一个包？用 composer require vendor/package:version --with-all-dependencies
手动改 composer.json 里的版本号再跑 composer update 是无效的。Composer update 默认只升不降，只要当前版本满足约束（比如 "monolog/monolog": "^2.0" 下装了 2.3.0），它就跳过安装。
- 先查目标版本是否存在：
composer show -a monolog/monolog，确认v1.27.0在列表中 - 执行强制降级：
composer require monolog/monolog:1.27.0 --with-all-dependencies - 不加
--with-all-dependencies容易静默失败——报错却不说明哪一层子依赖在拦着你 - 验证是否生效：
composer show monolog/monolog输出的version字段必须是1.27.0.0（Composer 自动补零，1.27和1.27.0解析行为不同）
降级失败？先跑 composer why-not vendor/package:version 定位冲突源头
执行 composer require monolog/monolog:1.27.0 --with-all-dependencies 报 Your requirements could not be resolved，这不是网络问题，是依赖图里存在明确封杀该版本的约束。
composer why-not monolog/monolog:1.27.0 必须带完整版本标识，漏掉 : 或版本号会报 Package not found。输出要从下往上读：最后一行是你 composer.json 的根声明，往上每行都是某个已安装包写的约束。常见陷阱是看到 laravel/sanctum 出现在链里就忽略，其实它可能悄悄锁死了上限。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
若输出为空，说明该版本不在当前 Packagist 通道——比如你设了 "minimum-stability": "stable"，但目标版本是 dev 分支。
PHP 版本太低导致解析失败？别指望 Composer 自动降级适配
报错 Your PHP version 7.4.33 does not satisfy that requirement，说明当前 PHP CLI 版本低于 composer.json 中声明的最低要求（如 "php": ">=8.1"）。Composer 不会自动降级包来迁就旧 PHP。
先运行 php -v 确认 CLI 真实版本（注意 Web SAPI 可能不同，composer 走的是 CLI）；若开发环境确实无法升级 PHP，可临时伪造 platform（仅限本地开发）：
composer config platform.php 7.4.33
但要注意：这仅影响依赖解析阶段，不改变实际运行时行为，上线前必须还原或真实升级。
真正复杂的地方在于，why-not 链路里混着 direct 和 transitive 依赖，而某些包的 replace 声明（比如 psr/log 被多个实现包声明替换）会让冲突路径更隐蔽——得结合 composer show --tree 手动展开一层层看。
