回退依赖靠的是干净的 composer.lock 文件而非 composer install 自动撤销；需用 git 恢复目标版本的 lock 文件、删除 vendor 后执行 composer install 才能准确降级。
回退不是靠 composer install 自己“撤销”，而是靠你手里的 composer.lock 文件是否干净、是否对应目标版本——它才是真正的依赖快照。
为什么 composer install 没装旧版？你根本没在用旧 composer.lock
常见现象：git checkout 切到旧 commit 后运行 composer install，vendor 里还是新包，甚至报 Class not found。这不是命令失效，是你当前工作区的 composer.lock 并非目标历史版本。
- 先确认：
git status composer.lock—— 如果显示modified或未暂存，说明它已被改过，不是你要的那个锁文件 - 恢复锁文件：
git checkout HEAD~1 -- composer.lock（或指定具体 commit hash） - 删掉旧 vendor：
rm -rf vendor（Windows 用户请手动删除整个 vendor 目录） - 再执行：
composer install—— 此时才真正按锁文件装，不看composer.json里的 ^ 或 ~ 约束
composer update --lock 不是回退，是重写锁文件
这个命令只会重新生成 composer.lock，但不会清理 vendor/，也不会降级任何包。它只是把当前 composer.json 的约束重新解析一遍，结果很可能还是新版本。
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 别用它来“回退”——它解决的是 lock 文件格式更新或哈希校验失败，不是版本倒退
- 如果你刚执行过
composer update，又想回到上一个 lock 状态，优先用 git 恢复 lock 文件，而不是指望 --lock 参数 - 执行前务必
git add composer.lock提交，否则下次 checkout 就丢锁了
只想降级某一个包？别改 composer.json 再 update
直接改版本号 + composer update vendor/package 看似可控，但会触发全新依赖解析，可能连带升级其他包，偏离预期。
- 更安全的做法：
composer require vendor/package:1.2.3（版本号写死，不用 ^ 或 ~） - 加
--with-all-dependencies防止子依赖冲突时静默跳过：composer require monolog/monolog:^2.9 --with-all-dependencies - 如果报
Your requirements could not be resolved，先跑composer why-not vendor/package:1.2.3查具体哪个包在拦着 - 执行前建议
git status确认无未提交变更，避免降级后无法快速 revert
多人协作时，composer.lock 必须提交，且不能忽略
有人把 composer.lock 加进 .gitignore，以为“反正能重装”，这是最常被忽略的协同雷区。
- 只要项目依赖有明确兼容性要求（比如 PHP 版本、扩展、插件），
composer.lock就必须提交到仓库 - CI/CD 流水线必须基于
composer install（而非update）构建，否则每次构建都可能拿到不同版本 - 团队成员拉代码后，第一件事不是
composer update，而是composer install—— 这才是保证环境一致的起点 - 如果 lock 文件频繁冲突，说明
composer.json约束太松（比如全用^），应收紧关键包版本或引入platform配置锁定 PHP 和扩展版本
最关键的细节永远在 composer.lock 是否干净、是否已提交、是否被正确还原——不是命令记不牢，而是文件状态没理清。
