如何识别Git中已提交的Composer依赖包版本以重建composer文件？

遇到这种没留composer文件但有完整vendor目录的情况，确实挺闹心，但有几个高效的方法可以快速倒推依赖版本，按优先级给你整理：

1. 优先用Composer内置命令提取（最快捷） #

Composer本身就提供了查看已安装依赖的命令，直接在项目根目录（vendor文件夹所在目录）运行：

composer show --installed --format=json

这个命令会输出JSON格式的完整依赖列表，包含每个包的名称、版本、甚至依赖关系。你只需要从中提取packages字段下的name和version，整理成composer.json的require区块即可——格式就是"包名": "版本号"。

如果觉得JSON处理麻烦，也可以用纯文本输出直接生成可复制的代码：

composer show --installed | awk '{print "\""$1"\": \""$2"\","}'

执行后会直接输出类似"monolog/monolog": "2.9.1",的行，把这些行复制到composer.json的require里，最后删掉最后一行多余的逗号就行。要是有开发依赖（比如PHPUnit这类），加上--dev参数就能一并提取：

composer show --installed --dev | awk '{print "\""$1"\": \""$2"\","}'

2. 从Git历史中找回丢失的文件（最准确） #

很多时候前序开发只是误删了composer文件，并没有从Git历史中彻底清除。你可以用Git命令搜索所有历史中的composer相关文件：

git log --all --full-history -- "composer.json" "composer.lock"

如果能找到相关提交记录，直接用git show <提交哈希>:composer.lock查看具体内容，或者恢复整个文件——这绝对是最准确的方式，因为lock文件记录了所有依赖的精确版本。

3. 从vendor包的元文件补全（备选方案） #

如果上面的方法都失效了，还可以直接查看每个vendor包自带的composer.json文件：每个依赖包在vendor/[厂商名]/[包名]/composer.json里都有自己的version字段，以及自身的依赖关系。不过这个方法需要逐个查看，效率较低，适合用来补全个别识别失败的包。

最后验证步骤 #

不管用哪种方法生成了composer.json，记得做两步验证：

• 运行composer validate检查JSON格式是否合法；
• 备份原vendor目录后，运行composer install，对比新生成的vendor和原目录是否一致，确保版本匹配。

内容的提问来源于stack exchange，提问作者spekulatius