必须重装 vendor 而非复制，因 Composer 是依赖解析器；迁移应执行 composer install（按 lock 文件精确复刻），而非 update（可能引发兼容问题）；前提需满足 PHP 版本、扩展、lock 文件三者一致。
直接复制 vendor 文件夹到新环境，99% 会出问题——Composer 不是“打包工具”，它是依赖解析器，必须重装。
为什么 composer install 比 composer update 更适合迁移
迁移目标是复刻原环境，不是升级或变更依赖。原项目有 composer.lock，说明版本已锁定。
-
composer install严格按composer.lock安装，保证 PHP 版本、扩展、依赖树完全一致 -
composer.update会忽略lock文件，重新解析composer.json，可能拉取新版包，触发兼容性断裂（比如某包 v3 不支持 PHP 8.1） - 如果新环境 PHP 版本更低，
install会报错并中止；update可能静默降级，埋下运行时异常
迁移前必须检查的三项环境前提
Composer 不报错 ≠ 依赖能跑起来。很多问题在 install 阶段不暴露，直到运行时报 Class not found 或 extension missing。
- PHP 版本号必须 ≥
composer.json中"php": "^8.0"等声明的最低版本（用php -v确认） - 关键扩展不能缺失：比如 Laravel 项目要
mbstring、openssl、pdo_mysql；Symfony 可能需要xml；用php -m核对 -
composer.lock文件必须存在且未被修改（Git 提交记录里它应和原项目一致；若只有composer.json，说明原环境从未锁过版本，风险极高）
vendor/ 能不能跳过重装？什么情况下可以硬拷贝
绝大多数情况不能。硬拷贝 vendor 唯一安全的前提是：新旧环境完全同构——相同操作系统、相同 PHP 版本、相同架构（x86_64 / ARM）、相同扩展编译参数（尤其涉及 ext-redis、ext-gd 这类 C 扩展）。
- Windows 下拷贝 Linux 的
vendor必然失败（符号链接、路径分隔符、扩展 .so/.dll 不兼容） - PHP 8.2 编译的
opcache字节码无法被 PHP 8.1 加载，导致require报错 - 哪怕只是 Docker 镜像 tag 不同（如
php:8.1-clivsphp:8.1.25-cli），某些扩展 ABI 也可能微变 - 真要省时间：用
composer install --no-dev跳过开发依赖，比硬拷贝更可靠
常见失败现象与对应解法
报错信息里藏着线索，别急着搜“怎么解决”，先看它卡在哪一层。
- 报
Could not parse version constraint ^2.0.0：Composer 版本太老（composer --version），升级到 2.x：curl -sS https://getcomposer.org/installer | php && sudo mv composer.phar /usr/local/bin/composer - 报
Failed to download vendor/package (2.1.0)：网络问题或 Packagist 镜像失效，临时切回官方源：composer config -g repo.packagist composer https://packagist.org - 报
ext-zip not loaded：不是 Composer 缺扩展，是zip扩展没启用，查php.ini是否有extension=zip，然后重启 PHP 进程 - 报
Class 'Illuminate\Foundation\Application' not found：autoload没生效，删掉vendor/autoload.php和vendor/composer/autoload_*.php，再install重建
最常被忽略的是 composer.lock 文件的完整性——它不像 package-lock.json 那样带哈希校验，但它的 content-hash 字段会随 composer.json 变动而变。如果这个字段和原项目不一致，install 就不会按你预期的版本装。
