composer install 在新服务器失败主因是 composer.lock 中的依赖哈希与平台配置（php版本、扩展、os架构）不匹配；需核验php版本≥要求、补全扩展、清理vendor后执行 composer install --no-dev --optimize-autoloader。
composer install 为什么在新服务器上失败
因为 composer.lock 里记录的是旧环境的依赖哈希和平台配置，新服务器 PHP 版本、扩展、OS 架构不同，composer install 会校验失败或装错版本。
- 先确认新服务器 PHP 版本 ≥
composer.json中"php"字段要求（比如"^8.1"），用php -v核对 - 检查是否缺失关键扩展：比如
mbstring、xml、curl，缺一个就可能卡在vendor/autoload.php加载前 - 如果旧项目用了
platform配置（如"ext-gd": "0"），新服务器没关掉对应扩展，composer install会拒绝执行 - 别直接跑
composer update—— 它会重写composer.lock，导致线上/本地行为不一致
迁移时要不要传 vendor 目录
不要传 vendor。它体积大、含绝对路径、绑定旧 PHP 扩展 ABI，直接复制过去大概率报 Class not found 或 undefined symbol。
- 只传
composer.json和composer.lock（二者必须成对） - 新服务器上清空旧
vendor，运行composer install --no-dev --optimize-autoloader -
--no-dev避免装测试类库（如phpunit），减少攻击面和体积 -
--optimize-autoloader生成静态映射，提升加载速度，尤其适合生产环境
PHP 版本不一致导致 composer install 报错
常见错误是 Your lock file does not contain a compatible set of packages，本质是 composer.lock 里某包的 php 约束和当前 PHP 不匹配。
- 先运行
composer check-platform-reqs，它会列出所有不满足的 PHP 版本或扩展 - 若只是小版本差异（如锁文件要求
^8.0，当前是8.2），可临时加--ignore-platform-req=php强制过，但得确认代码真兼容 - 更稳妥的做法：在旧服务器用
composer show php查实际解析出的 PHP 版本号，再比对新服务器是否 ≥ 该值 - 注意
ext-openssl这类扩展在某些 Docker 镜像里默认关闭，extension=openssl得显式写进php.ini
权限和用户问题引发的 autoload 失败
composer install 成功，但运行时报 Class 'Illuminate\Foundation\Application' not found，往往是 autoloader 权限或用户隔离导致的。
- 确保
vendor/autoload.php可被 Web 用户（如www-data）读取，别用root身份装完就扔那儿 - Linux 下检查
vendor目录的 group 是否包含 Web 用户，必要时chgrp -R www-data vendor+chmod -R g+r vendor - 如果用
opcache，记得重启 PHP-FPM 或调用opcache_reset()，否则旧缓存可能还在找旧路径 - 某些共享主机禁用
symlink，composer install会退化为 copy 模式，但 autoload 仍按 symlink 路径生成 —— 此时要删掉vendor/composer/autoload_*.php重装
最麻烦的不是命令跑不起来，而是命令跑起来了，autoload 却静默失效 —— 这种问题往往要翻 vendor/composer/autoload_static.php 里的路径和实际文件位置是否对得上。
