不能全自动还原原始 composer.json，因为 vendor 只存代码不存元信息；但可用 composer show -i 查已装包及版本，结合 autoload_*.php 逆向提取 autoload 配置，再人工补约束、区分 require/require-dev 并验证自动加载生效。
composer.json 丢了，但 vendor 还在，能直接还原吗
不能全自动还原原始 composer.json，因为 vendor 只存代码，不存依赖版本约束、autoload 配置、scripts、require-dev 等元信息。但可以反推核心依赖关系，重建一个可用的最小 composer.json。
用 composer show -i 查出已安装包和精确版本
这是最可靠的第一步：vendor 里的包名和版本号都完整保留，composer show -i 会列出所有已安装包及其锁定版本（即 composer.lock 里记录的版本）。前提是项目根目录下还有 composer.lock 文件。
- 如果
composer.lock也丢了，只能靠vendor/autoload.php和命名空间猜包名，或手动检查vendor/下目录名（如vendor/monolog/monolog→"monolog/monolog"） -
composer show -i输出的是实际安装版本，不是^2.0这类约束，所以还原后得人工补上合理约束（比如把"symfony/console": "6.4.10"改成"symfony/console": "^6.4"） - 注意区分
require和require-dev：composer show -i不分环境，需结合历史记忆或vendor/bin/phpunit这类工具路径判断哪些是开发依赖
vendor/autoload.php 里藏了 autoload 配置线索
vendor/autoload.php 本身不写配置，但它加载的 vendor/composer/autoload_*.php 文件里有真实映射。这些文件是 composer install 时根据原始 composer.json 的 autoload 段生成的，可逆向提取关键信息。
- 打开
vendor/composer/autoload_static.php（或autoload_classmap.php），搜索'psr-4' =>或'classmap' =>，能看到类似'App\' => array($vendorDir . '/myapp/src')的条目 → 对应原始"App\": "src/" - 如果看到
'files' => array($vendorDir . '/some/package/functions.php')，说明原composer.json里有"files"自动加载项 - 别直接复制这些路径到新
composer.json：路径含$vendorDir是生成后的结果，你要填的是相对项目根的路径，比如"src/"而不是vendor/myapp/src
生成基础 composer.json 后必须验证 autoload 和 require 匹配
手写完 composer.json，光 composer install 成功不够，要确保自动加载真正生效，否则运行时找不到类。
- 执行
composer dump-autoload -o，然后用composer show --path monolog/monolog确认路径正确；再php -r "var_dump(class_exists('MonologLogger'));"测试类是否可加载 - 如果项目用了自定义命名空间（如
MyApp），在src/下放一个测试类，用php -r "var_dump(class_exists('MyAppTest'));"验证 autoload 是否生效 - 常见坑：
autoload里写了"psr-4": {"App\": "app/"}，但实际代码在src/，或忘记加末尾反斜杠导致命名空间解析失败
最关键的不是还原出一模一样的文件，而是让 composer install 后的依赖结构、自动加载、脚本执行都回到原来状态。vendor 是事实来源，但所有约束、路径、开发/生产区分，都得靠人去对齐——机器只能告诉你“装了什么”，没法回答“为什么装这个版本”或“这个包该不该进 require-dev”。
