直接迁移 vendor 目录不可靠，应仅备份 composer.json 和 composer.lock 并在新环境运行 composer install；因 vendor 含路径硬编码、平台相关构建逻辑及哈希校验，复制易致 Class not found、文件路径错误或安装失败。
直接迁移 vendor 目录不可靠，新服务器上 PHP 版本、扩展、OS 架构或文件权限稍有不同，就可能引发运行时错误或安装失败。真正安全的做法是只备份 composer.json 和 composer.lock，在新环境重装依赖。
为什么不能直接复制 vendor 目录
Composer 安装时会根据当前环境生成路径硬编码（如 autoloader 中的绝对路径）、执行平台相关脚本（如 ext-* 扩展的构建逻辑）、校验二进制包哈希值。常见报错包括：
-
Class not found（autoload 未生效，因路径缓存或生成逻辑不一致） -
Failed to open stream: No such file or directory（vendor/bin脚本头行指向旧 PHP 路径） -
Package is not installed correctly（某些包含 post-install-cmd，跳过则缺失资源或配置）
迁移前必须保留的两个文件
composer.json 和 composer.lock 是唯一可信源。前者声明意图，后者锁定精确版本与哈希。缺 lock 文件会导致新服务器拉取不同 minor/patch 版本，引发兼容性问题。
- 确认
composer.lock已提交到 Git —— 如果没提交，先在旧服务器运行composer update --lock再备份 - 检查
composer.json中的platform配置（如"php": "8.1.0"），确保与新服务器匹配；不匹配需手动调整或加--ignore-platform-reqs（不推荐） - 若项目含私有包（如 GitLab 私仓），确认新服务器已配置对应 auth token：
composer config -g http-basic.gitlab.example.com token username
在新服务器上正确还原依赖
不要用 composer install 以外的方式还原 —— 即便有完整 vendor，也应删掉并重来。
- 确保新服务器已安装匹配版本的 Composer（建议 2.x）：
composer --version，若为 1.x，升级：curl -sS https://getcomposer.org/installer | php && sudo mv composer.phar /usr/local/bin/composer - PHP 扩展需提前装齐（如
mbstring、xml、zip、openssl），否则composer install会中途失败且不提示具体缺哪个 - 运行
composer install --no-dev（生产环境）或composer install（开发环境）；加--optimize-autoloader可提升性能，但首次安装可省略 - 若遇到
memory_limit不足，临时调高：php -d memory_limit=-1 $(which composer) install
额外注意：缓存与权限陷阱
Composer 默认使用全局缓存（~/.composer/cache），迁移到新服务器后缓存为空，首次安装会慢。但别从旧机复制缓存目录——哈希和路径结构可能不兼容。
- 新服务器若用 www-data 用户运行应用，
vendor目录权限需对 Web 用户可读，但不可写（防意外篡改）；建议chown -R $USER:www-data vendor+chmod -R g+r,o+rX vendor - 某些包（如
laravel/framework）会在bootstrap/cache写缓存文件，这些不属于 Composer 管理范围，需单独同步或重建（如运行php artisan config:clear） - 如果你用了
composer global require的命令行工具（如laravel/installer），它们不在项目内，需单独在新服务器重新安装
最易被忽略的一点：有些团队把 vendor 提交进 Git 或用 rsync 同步，自以为省事，结果上线后某天因为一个微小的环境差异（比如 OpenSSL 版本号多了一位）导致某个包的二进制预编译文件加载失败，而错误日志里根本看不出关联。
