composer怎么在服务器部署_composer线上环境配置流程

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 是否误写了生产用类（比如把 AppconsoleCommands* 放进 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/。