唯一可靠路径是Git恢复旧版composer.lock后执行composer install，因手动编辑会破坏content-hash和dist/sha256校验值，导致install报错拒绝执行；update会重解析依赖而非回滚，删vendor后瞎跑命令亦不可控。
回滚到指定 composer.lock 版本，唯一可靠路径是 Git 恢复 + composer install，不是改文件、不是 update、更不是删 vendor 后瞎跑命令。
为什么不能手动编辑 composer.lock？
因为 composer.lock 包含 content-hash 和每个包的 dist/sha256 校验值。手动改其中一行版本号，hash 就对不上，composer install 会直接报错拒绝执行：
Your lock file is not up to date with your composer.json. Run "composer update" to update it.
这不是提示你“该更新”，而是校验失败的硬拦截。哪怕只动一个字符，也会触发。
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- Git 提交过的
composer.lock才可信——没提交过，就等于没备份 - 别依赖
composer.json的版本约束（比如"monolog/monolog": "^2.0"），它只管“允许范围”，不保证装哪个 - 中文镜像（如
https://mirrors.aliyun.com/composer/）必须与目标历史版本兼容；旧包若未同步进镜像，install会卡在“Resolving dependencies”或报Could not find package
git checkout -- composer.lock 的正确写法
这句命令常被写错，导致切错分支或覆盖整个工作区。关键在双横线 -- 和路径精度：
- 查目标 commit：
git log --oneline -- composer.lock，找含旧锁文件的提交哈希（如abc1234） - 只恢复 lock 文件：
git checkout abc1234 -- composer.lock（注意--在中间，不是git checkout -- abc1234） - 确认恢复成功：
git status composer.lock应显示nothing to commit, working tree clean - 如果
composer.lock已被修改但未提交，先git checkout -- composer.lock撤销本地改动，再执行上一步
composer install 与 composer update 的本质区别
这是最容易混淆的操作点：install 是“照单施工”，update 是“重新算料”。回滚必须用前者：
-
composer install：完全忽略composer.json的版本约束，只读composer.lock，精确安装每个包的 hash 对应版本 -
composer update vendor/package：强制重新解析依赖树，可能升级其他包，甚至引入不兼容变更 - 如果
vendor目录损坏但composer.lock完好，直接rm -rf vendor && composer install即可重建 - 绝对不要运行
composer update --lock——它只会重写 lock，不清理 vendor，也不降级任何包
回滚后必须验证的三个点
装完不等于跑得通。尤其当目标版本和当前 PHP 版本、扩展或框架存在兼容性断层时：
- 检查
vendor/autoload.php是否存在且可 require；某些包在旧版中移除了自动加载逻辑 - 运行
composer show vendor/package，确认输出的version字段（如2.9.2.0）与 lock 文件里记录的一致 - 如果有自定义插件或
auth.json，注意 Composer 1.x 和 2.x 对认证字段（如github-oauth）的解析方式不同，老 lock 文件配新 Composer 可能静默失效
