报错“connection refused”或“curl error 7”是网络连通性问题而非composer配置错误:需先检查dns(ping packagist.org)、tcp连接与tls握手(curl -v),再验证镜像是否正确写入全局配置。

报“Connection refused”或“cURL error 7”:先别动composer config
这不是 Composer 配置错了,是系统根本没连出去。DNS 解析失败、防火墙拦截、代理静默丢包,都会卡在这一步。
- 运行
ping packagist.org—— 如果返回unknown host,说明 DNS 不通,立刻改/etc/resolv.conf(Linux/macOS)或网络适配器设置(Windows),加一行nameserver 8.8.8.8 - 运行
curl -v https://mirrors.aliyun.com/composer/—— 卡在* Connected to是 TCP 层不通;卡在* TLS handshake是证书或 SNI 问题,可临时加CURL_IPRESOLVE=4强制走 IPv4 -
composer config -g repo.packagist输出仍是https://packagist.org?说明镜像根本没写进去,不是“没生效”,是命令写错了(漏composertype、缺末尾/、键名写成repos.packagist)
报“Permission denied”写 vendor/ 或 composer.lock:别急着 chmod
90% 的权限报错不是权限不够,而是目录归属错了——vendor/ 或 composer.lock 被 sudo composer install 污染过,现在属主是 root,而你用普通用户再跑就拒绝写入。
- 看报错路径:
file_put_contents(/path/to/vendor/autoload.php): Permission denied→ 直接执行ls -ld vendor/,如果显示root root,就确认是归属问题 - 修复命令是
sudo chown -R $USER:$USER vendor/ composer.lock(Linux/macOS)或右键属性 → 安全 → 编辑当前用户权限(Windows) - 别用
chmod 777—— 这会让 Composer 后续拒绝写入,它会检查目录权限是否过于宽松
报“Your requirements could not be resolved”:不是依赖冲突
这是 composer install 在严格还原 composer.lock,但你的 PHP 环境不满足锁文件里某包的硬性要求。
工作流任务拆解与模型编排技能。使用场景:(1) 收到复杂工作任务需要拆解为可执行步骤,(2) 需要为不同步骤选择最合适的模型,(3) 需要跟踪工作流进度和模型使用情况,(4) 长时间任务卡住需要问题诊断和解决方案。
- 运行
composer diagnose,重点看PHP version和Extensions行 —— 缺ext-mbstring、ext-xml或 PHP 版本低于锁文件中某个包声明的最低版本(比如monolog/monolog v3.5.0要求PHP >= 8.1,而你是 8.0) - 检查
composer.json顶部是否有"config": {"platform": {"php": "8.2.10"}}—— 如果实际 PHP 是 8.1,它就会假装自己是 8.2.10,导致装完后运行时报错 -
--ignore-platform-reqs只能临时绕过,装出来的包大概率在php artisan或自动加载时崩,不是解法
换镜像后仍卡在 “Loading composer repositories”:缓存和 lock 文件在捣鬼
镜像配置正确 ≠ 立刻生效。Composer 会优先读缓存里的元数据,而 composer.lock 里硬编码了旧源地址,不清理就一直重试失败路径。
- 必须执行
composer clear-cache;Windows 用户还要手动删%LOCALAPPDATA%\Composer\cache - 删掉
vendor/和composer.lock—— 尤其是composer.lock,它记录的是上次成功安装时的 provider URL,换源后不删它,Composer 就拿旧地址去新镜像站找包,必然 404 - 验证真实请求地址:运行
composer install -vvv 2>&1 | head -n 10 | grep Downloading,第一行的 URL 才是你当前真正访问的源,不是composer config输出的那个
真实环境里最容易被跳过的,是 composer.lock 文件本身的存在性检查 —— 它不存在时,composer install 会退化成 update,结果不可控;还有就是项目级 repositories 字段,哪怕只是空数组 [],也会让全局镜像彻底失效。










