不能直接复制vendor目录迁移，因含路径硬编码、平台相关构建产物及未执行的post-install-cmd脚本；必须仅备份composer.json和composer.lock，在新服务器运行composer install重建依赖。
直接复制 vendor 目录迁移项目，90% 的失败不是因为网络或权限，而是因为 composer install 被跳过或误用——它才是唯一可信赖的“重装”动作，不是辅助手段，是核心步骤。
为什么不能直接拷贝 vendor 目录到新服务器
拷过去看似快，但 vendor 里埋着大量环境强依赖：autoloader 中的绝对路径、vendor/bin 脚本头行硬编码的 PHP 路径、扩展构建产物（如 ext-redis 的 .so 文件）、甚至某些包的 post-install-cmd 脚本根本没执行。常见报错包括：
-
Class not found（autoload 缓存未刷新或路径失效） -
Failed to open stream: No such file or directory（bin 脚本指向旧 PHP 解释器） -
Package is not installed correctly（比如 hirak/prestissimo 插件没注册，因--no-install跳过了插件初始化）
真正安全的做法，是只带 composer.json 和 composer.lock 过去，让 composer install 在目标机上从头重建整个依赖树。
迁移前必须确认的三件事
否则 composer install 会静默失败或中途退出：
-
composer.lock必须存在且已提交到 Git —— 如果缺失，先在源机运行composer update --lock生成它 - 新服务器的 PHP 版本（含小版本，如
8.2.12）和关键扩展（mbstring、openssl、zip、pdo_mysql等）必须匹配composer.json中的platform配置，不匹配时不要加--ignore-platform-reqs，应先调环境 - 私有包认证需提前配置：
composer config -g http-basic.gitlab.example.com token username，否则卡在下载环节
在新环境执行 composer install 的实操要点
别直接敲 composer install 就完事，这几个参数和顺序影响成败：
- 先删掉残留的
vendor和composer.lock（如果旧文件被手动改过），确保干净起步 - 运行
composer install --no-dev --optimize-autoloader（生产环境）或composer install（开发环境） - 若内存不足报错，用
php -d memory_limit=-1 $(which composer) install绕过限制 - 验证 autoload 是否生效：
php -r "require 'vendor/autoload.php'; echo class_exists('Monolog\Logger') ? 'OK' : 'FAIL';"
注意：Composer 2.x 是底线要求，1.x 已停止维护，升级命令是 curl -sS https://getcomposer.org/installer | php && sudo mv composer.phar /usr/local/bin/composer。
自动化迁移常踩的坑：post-install-cmd 不是万能钥匙
很多人在 composer.json 里配 "post-install-cmd": ["php artisan migrate --force"] 想一步到位，但实际中极易翻车：
- 该脚本每次
composer install都触发，本地开发时可能反复清空测试数据 - 数据库配置（如
.env）若未就位，迁移直接失败，且错误信息常被 Composer 日志吞掉 - 某些迁移工具（如 Doctrine Migrations）首次运行前必须执行
vendor/bin/doctrine-migrations migrations:sync-metadata-storage，否则报No metadata storage table，这不是 DB 连接问题，是迁移系统自身没初始化
真正可控的做法，是把迁移拆成独立步骤：先 composer install，再显式跑 php artisan migrate 或 php bin/console doctrine:migrations:migrate，并确保该命令在部署流程中只执行一次。
