真正可靠的依赖备份只需保留composer.json和composer.lock文件；直接复制vendor目录必然失败，因其含绝对路径、平台相关编译产物、未执行的post-install-cmd脚本及环境敏感配置。
只备份 composer.json 和 composer.lock，其他都是干扰项。任何试图复制 vendor/ 目录、打包整个 vendor/ 或依赖 composer show 输出来“备份依赖”的做法，都会在新环境或恢复时失败。
为什么直接复制 vendor 目录一定会出问题
因为 vendor/ 里混着大量环境敏感内容：autoload 文件写死了绝对路径，bin/ 脚本第一行 #!/usr/bin/env php 可能被替换成旧服务器的 PHP 路径，扩展类（如 ext-redis）的编译产物与目标机器的 ABI 不兼容，还有 post-install-cmd 脚本生成的资源（如配置文件、缓存）根本不会随目录一起迁移。
常见错误现象包括：
-
Class not found（autoload 加载失败，路径缓存未刷新或生成逻辑不一致） -
Failed to open stream: No such file or directory（vendor/bin/phpunit头行指向已不存在的 PHP 解释器） -
Package is not installed correctly（跳过了post-install-cmd，缺失关键初始化步骤）
备份时必须确认的三件事
可靠备份不是“把文件拷走”，而是确保元数据状态干净、可复现：
- 运行
git status，确认composer.lock是 clean 状态（没被本地修改过） - 检查
composer.json中的"config": {"platform": {...}}是否匹配目标环境（例如"php": "8.1.0"），不匹配会导致包被跳过且无提示 - 若项目含私有包（如 GitLab 私仓），确认
auth.json或全局http-basic配置已备份，否则composer install会在认证环节卡住
恢复时最常踩的坑：删得不干净 + 装得不对
很多人删了 vendor/ 却忘了残留的 autoload 缓存或 bin 脚本，或者误用 composer update 替代 composer install，结果装出完全不同的依赖树。
- 必须执行
rm -rf vendor/（Windows 用rmdir /s vendor），不能只删子目录 - 务必用
composer install --no-dev（生产）或composer install（开发），绝不用composer update - 若报错
Your lock file does not contain a compatible set of packages，说明composer.json和composer.lock已不一致——此时应先git checkout HEAD -- composer.lock，再重试 - 遇到内存不足报错？用
php -d memory_limit=-1 $(which composer) install绕过限制
离线或跨平台迁移时的关键校验点
离线不是“把 vendor 拷过去就行”，而是要保证 Composer 自己能完全脱网工作：
- 目标机器 PHP 版本、必需扩展（
mbstring、xml、zip、openssl）必须和打包环境一致，否则composer install在生成 autoload 阶段就崩溃 - 必须存在且未修改的
composer.lock—— 它是唯一权威依据；没有它，composer install会退化为update并尝试联网 - 若需真正离线，应备份 Composer 全局缓存目录（
composer config --global cache-dir），而非vendor/；恢复时先composer config --global cache-dir /path/to/cache，再install
最容易被忽略的是 platform 配置和全局缓存路径的版本兼容性——两端 Composer 版本不一致（比如一端是 2.2.x，另一端是 2.5.x），即使缓存目录完整，也可能因哈希路径规则变化导致命中失败。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
