上线Composer报错八成非代码问题，需优先排查composer install：检查composer.lock是否存在及提交历史、vendor目录权限是否匹配运行用户、PHP版本与扩展是否与require一致、镜像源是否可用并清除缓存。
上线时报错，八成不是代码问题，而是 Composer 在目标环境里根本没跑通 install/update —— 先别改业务逻辑，盯住 composer install 这一步的输出，它暴露的是环境、配置、权限或元数据层面的真实断点。
报 “No composer.lock file present” 或直接中断执行
这说明部署脚本没把 composer.lock 文件一起传上去，或者 CI/CD 流水线里误加了 .gitignore 规则（比如某团队曾把 composer.lock 加进全局 ignore 列表）。composer install 严格依赖该文件，没有它就拒绝工作，不会 fallback 到解析 composer.json。
- 确认部署包中存在
composer.lock：解压后运行ls -l composer.lock - 检查 Git 提交历史：
git log --oneline -- composer.lock，看是否近期被意外删掉 - CI 中若用
git clone --depth=1，确保没跳过该文件；某些老旧部署脚本会手动rm composer.lock再composer update，这是高危操作，应禁用
报 “Permission denied” 写 vendor/ 或生成 autoload 文件
典型现象是容器内或生产服务器上，vendor/ 目录属主为 root，但应用以非 root 用户（如 www-data）运行。常见于本地用 sudo composer install 后打包上传，或 Dockerfile 中未指定用户。
- 查归属：
ls -ld vendor/，若显示root root，立刻修复：sudo chown -R www-data:www-data vendor/（按实际运行用户调整） - Docker 部署时，在
composer install后加USER www-data，避免后续进程无权读取vendor/ - 别用
chmod 777硬怼——解决不了属主错位，还可能触发安全扫描告警
报 “Your requirements could not be resolved” 且只在上线环境出现
本地能装，线上报依赖冲突，大概率是 PHP 版本或扩展不一致。Composer 解析时会校验 "php" 约束和 ext-xxx 扩展要求，而 Web 服务用的 PHP 和 CLI 用的可能是两个配置。
- 上线机器上运行：
php -v和php -m | grep -E "mbstring|openssl|curl|json"，确认与composer.json中"require"字段声明的版本范围匹配 - 检查
php.ini路径：php --ini，确认 CLI 加载的是预期配置，而非某个被注释掉的旧文件 - 若用
"config": {"platform": {"php": "8.1.0"}}锁定平台版本，需确保线上 PHP 真是 8.1.x，否则 Composer 会按“假装运行在 8.1”来解析，结果装出不兼容的包
卡在 “Loading composer repositories” 或 “Could not fetch packages.json”
上线环境通常没配镜像源，直连 packagist.org 失败。这不是超时或重试能解决的，是 DNS、TLS 或路由层面被阻断。
- 进容器或服务器，手动测试：
curl -I https://mirrors.aliyun.com/composer/packages.json，返回200才算通 - 若失败，先切镜像：
composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/（注意新版键名是repo.packagist，不是repos.packagist） - 切完必须清缓存：
composer clear-cache，否则旧失败记录残留，重试仍走不通路径
真正麻烦的不是单个报错，而是多个条件叠加：比如镜像配置写错导致元数据拉不到，Composer 又因权限问题无法写入缓存目录，最终报出一个看似是依赖冲突的假象。排查时得从网络 → 权限 → PHP 平台约束 → 依赖逻辑，一层层剥开，别被最后一行红字带偏。
