真正可靠的依赖备份是保留 composer.json 和 composer.lock 文件，二者合计不足100KB，可复现完全一致的 vendor；直接复制 vendor 不可行，因其含自动生成文件、平台相关产物及本地修改；composer show 仅反映当前 vendor 状态，不可用于恢复安装。
Composer 项目依赖不能靠直接复制 vendor 目录来“备份”，真正可靠的方式是导出可复现的依赖快照——也就是生成和维护好 composer.lock，再辅以按需导出纯包名列表。
为什么不能直接打包 vendor 目录
因为 vendor 里混着大量自动生成文件（如 autoload 文件、二进制脚本）、平台相关扩展（如 ext-redis 编译产物），还可能包含未提交的本地修改或 dev-only 工具。直接拷贝过去大概率在另一台机器上 composer install 失败或行为不一致。
-
composer.lock才是真实记录每个包确切版本、哈希值、依赖树的权威文件 - 只要
composer.lock存在，composer install就能还原完全一致的vendor - 删掉
vendor和composer.lock后仅靠composer.json运行composer install，结果可能因版本漂移而不同
导出完整依赖列表（含版本）：用 composer show
适合人工查看、审计或生成文档，不是用于恢复安装，但比 composer.json 更全面（包含递归依赖）。
- 列出所有已安装包（含
require-dev）：composer show --all - 只导出生产环境依赖（不含
require-dev）：composer show --no-dev --all - 导出为简洁表格（不含描述）：
composer show --no-dev --format=plain - 保存到文件：
composer show --no-dev --format=plain > deps.txt
注意：composer show 输出的是当前 vendor 状态，不是 composer.lock 快照；如果没运行过 install 或 update，结果可能为空或不准。
生成可复现安装的最小备份：只保留 composer.json + composer.lock
这才是真正的“依赖备份”。这两份文件加起来不到 100KB，却足以在任意环境重建完全一致的依赖树。
- 确保每次变更依赖后都提交
composer.lock（Git 中不应忽略它） - 删除
vendor后，用composer install（不是update）还原 - 若需跨 PHP 版本或平台部署，检查
composer.lock里的platform配置是否匹配目标环境 - CI/CD 流程中应始终使用
composer install --no-interaction --no-progress，避免意外触发update
按需导出纯包名列表（不含版本）：用 composer show --name-only
适用于构建白名单、安全扫描输入、或与其它工具集成（比如对比两个项目的依赖差异）。
- 生产依赖包名列表：
composer show --no-dev --name-only | sort > packages.txt - 包含
require-dev的全量包名：composer show --all --name-only | sort | uniq - 注意：这种列表无法用于安装，只是标识符集合；不同版本的同名包会去重，丢失关键信息
真正起作用的永远是 composer.lock —— 它小、精确、可验证，而所有“导出列表”操作只是辅助手段。漏掉它，其他任何备份都只是半成品。
