composer install 服务器报错主因是环境不一致：PHP版本、扩展缺失、dev依赖未清理、autoloader含dev路径、镜像/签名配置不当、权限错误；须用--no-dev+dump-autoload--no-dev+统一环境+正确权限。
composer install 为什么在服务器上总报错？
因为线上环境默认走 composer install --no-dev，但很多项目没清理掉 require-dev 里的扩展，或本地用了 platform 配置骗过依赖检查，一到服务器就暴露。
- 确认
composer.json的config.platform.php是不是写了本地 PHP 版本（比如"7.4.33"），线上 PHP 版本低就会卡在依赖解析阶段 - 删掉
vendor/和composer.lock后重跑composer install --no-dev --optimize-autoloader，别信本地生成的 lock 文件直接传上去 - 如果用 CI/CD，确保构建机和线上 PHP 版本、扩展（尤其是
mbstring、json、openssl）完全一致，否则composer install会静默失败或中途退出
怎么让 composer 不下载 dev 依赖还保持 autoloader 正常？
关键不是“不装”，而是“装完立刻剔除”——--no-dev 只控制安装时行为，但 autoloader 默认仍包含 autoload-dev 规则，导致线上报 Class not found。
- 运行
composer dump-autoload --no-dev --optimize，这步必须在install之后单独执行，否则vendor/autoload.php里还留着测试类路径 - 检查
composer.json的autoload-dev是否误写了生产用类（比如把App\Console\Commands\*放进 dev autoload），这种写法上线后命令根本加载不了 - 如果用了
psr-4映射，确保生产代码没混在tests/或src/Tests/下——--no-dev不删文件，但 autoloader 不扫这些目录
服务器上 composer install 太慢甚至超时怎么办？
不是网络差，是默认用 packagist.org + 没设镜像 + 每次都验证签名，三者叠加导致卡在 Resolving dependencies 阶段。
- 部署前在服务器执行
composer config -g repo.packagist composer https://packagist.phpcomposer.com（国内用腾讯或阿里镜像），注意加-g全局生效，否则只对当前目录有效 - 禁用签名验证：
composer config -g secure-http false，仅限内网可信环境；否则 Composer 会为每个包发起 HTTPS 证书校验，小内存 VPS 容易 OOM - 加
--prefer-dist --no-progress减少输出和校验开销，尤其在 Jenkins 或 systemd 服务里，避免日志缓冲区撑爆
部署脚本里该不该执行 composer update？
不该。线上必须用 composer install，且 composer.lock 必须由开发人员提交，否则版本漂移无法追溯。
-
composer update会忽略lock文件重算依赖，哪怕只改一行composer.json，也可能升到不兼容的次要版本（比如monolog/monolog ^2.0升到2.10.0引入新方法） - 如果真要更新，流程是：开发机
composer update xxx→ 提交新composer.lock→ 部署时composer install，而不是把update塞进 deploy.sh - CI 构建阶段可加
composer validate --strict检查lock和json是否匹配，比上线后炸掉强
最麻烦的其实是权限——www-data 用户跑 composer install 时，如果 vendor/ 是 root 写的，会卡在解压 tar 包那步，错误信息就一行：failed to open stream: Permission denied，得提前 chown -R www-data:www-data vendor/。
