答案是90%因环境不一致：先查PHP CLI版本（php -v）、关键扩展（php -m | grep）、镜像源是否生效（composer config -g repo.packagist）、vendor目录归属（ls -ld vendor），四点定位远比重装Composer高效。
服务器上 composer install 报错，90% 是环境不一致导致的，不是代码或网络随机故障——先确认 PHP CLI 版本、扩展、镜像源、目录归属这四点，比重装 Composer 有效十倍。
PHP 版本和扩展不匹配
本地跑得通，服务器报 Your requirements could not be resolved，大概率是 PHP CLI 版本低于依赖要求。Laravel 11 要求 PHP ≥ 8.2，但很多服务器默认还是 PHP 7.4 或 8.0，php -v 看的是 Web 环境（如 Apache 加载的 php.ini），而 Composer 运行在 CLI 下，必须用 php -v 和 php -m 在终端里实测。
- 运行
php -v确认 CLI 实际版本，别信phpinfo()页面 - 运行
php -m | grep -E "mbstring|xml|zip|curl|openssl"检查关键扩展是否加载；缺ext-dom会导致failed to extract，缺ext-zip会静默失败 - Ubuntu/Debian 下装扩展：比如 PHP 8.2 就执行
sudo apt-get install php8.2-mbstring php8.2-xml php8.2-zip php8.2-curl - CentOS/RHEL 注意源：用
dnf module list php查可用流，再dnf install php-dom php-xml php-zip
镜像源没生效或缓存残留
报 Connection refused、Curl error 7 或卡在 Loading composer repositories，说明 Composer 还在直连 packagist.org，根本没走你配的镜像。
- 执行
composer config -g repo.packagist，输出必须是完整 JSON，形如{"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}；空、null、或仍是官方地址，说明配置无效 - 项目根目录下若有
"repositories": []（哪怕空数组），全局镜像直接失效；临时清掉：composer config --unset repositories - 换源后必须执行
composer clear-cache，否则旧 provider 地址仍被复用 - 验证真实请求地址：
composer install -vvv 2>&1 | grep -i "host\|mirrors"，第一行出现的域名才是实际访问目标
vendor/ 或 composer.lock 权限被 root 污染
报 file_put_contents(/path/to/vendor/autoload.php): Permission denied，不是权限数字不够，而是目录属主是 root，而你正以普通用户（如 www）运行命令。
- 定位报错路径后，立刻执行
ls -ld /path/to/vendor和ls -l /path/to/composer.lock - 如果属主是
root，修复命令为：sudo chown -R $USER:$USER /path/to/vendor /path/to/composer.lock - 宝塔或 Docker 环境尤其注意：你在终端用
root配了全局镜像，但实际运行的是www用户，得用sudo -u www composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ - 别用
chmod 777，它会让后续部署或 CI 流水线拒绝执行
platform 配置与实际环境冲突
composer.json 里写了 "config": {"platform": {"php": "8.1"}}，但服务器实际是 PHP 8.2，Composer 会强制按 8.1 解析兼容性，导致误判“无满足版本”。
- 检查
composer.json顶部是否有platform字段，尤其是硬写死的php版本 - 运行
composer why-not php:8.2（把 8.2 换成你服务器真实版本），它会直接指出哪个包在阻塞安装 - 临时绕过可用
composer install --ignore-platform-reqs，但它只是跳过校验，不会解决运行时ParseError或Class not found - 若项目需多环境部署，建议删掉
platform，改用 CI 流水线中指定 PHP 版本做约束
真正容易被忽略的是：服务器 CLI 环境和 Web 环境完全独立，php.ini、扩展、甚至 PATH 都可能不同；一次 php -v 和一次 composer diagnose 就能筛掉 80% 的问题，比反复删 vendor 快得多。
