加 -vvv 才能看到真实失败点，因为 composer 默认静默输出会过滤 dns 失败、ssl 超时、http 跳转异常、json 解析错误等底层问题，不加则无法定位卡在下载还是缓存读取阶段。
直接看 composer install -vvv 输出，别信默认静默输出——90% 的“卡住”或“没报错”其实是日志被吞了。
为什么加 -vvv 才能看到真实失败点
Composer 默认只显示进度条和最终结论，像 DNS 解析失败、SSL 握手超时、HTTP 302 跳转异常、包元数据解析错误这些底层问题全被过滤掉。不加 -vvv，你根本不知道它卡在 Downloading https://mirrors.aliyun.com/composer/p2/monolog/monolog.json 还是 Reading /root/.composer/cache/repo/https---packagist.org/packages.json。
常见现象：composer install 停在 Loading composer repositories 或 Installing dependencies 几分钟不动，终端既无报错也无进度；或者只报 Could not fetch，但没说哪个 URL、哪个包、哪一行 JSON 解析失败。
- 第一行
Downloading日志里的 URL 就是真实请求地址，不是composer config里配的镜像地址——后者可能被项目级repositories覆盖或 fallback 掉 - 用
composer install -vvv 2>&1 | head -n 10 | grep Downloading快速定位首条网络请求，确认是否走对镜像 - 若日志里压根没出现
Downloading，说明失败发生在更早阶段：比如composer.json语法错误、PHP 扩展缺失（ext-json未启用）、或vendor/权限导致无法写入 autoload.php
报错里带 file_put_contents 或 Permission denied 怎么快速定位
这类错误不是权限不够，而是“主人错了”——目录属主是 root，当前用户却没权限改写。Composer 不会告诉你具体哪个路径出问题，但报错行里一定含绝对路径。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
例如：file_put_contents(/var/www/project/vendor/autoload.php): Permission denied → 问题就在 vendor/ 目录。
- 立刻执行
ls -ld vendor/ composer.lock $(composer config --global home)，看属主是不是root - 如果是，用
sudo chown -R $USER:$USER vendor/ composer.lock（Linux/macOS）或takeown /f vendor /r（Windows）修复归属 - 别用
chmod 777暴力解决——这会让 Composer 后续拒绝写入，且存在安全风险 - 特别注意
~/.composer/cache和COMPOSER_HOME环境变量指向的路径，CI 环境中常因sudo导致缓存目录属主错乱
Connection refused 或 cURL error 7 到底该查什么
这不是 Composer 配置问题，是系统连不通目标服务器。php -m | grep curl 能看到 curl 扩展就说明 PHP 层 OK，问题在操作系统网络栈。
- 先跑
ping packagist.org：返回unknown host就是 DNS 失败，立刻换8.8.8.8或114.114.114.114 - 再跑
curl -I https://mirrors.aliyun.com/composer/packages.json：返回HTTP/2 200才算通；若卡在* Connected to或* TLS handshake，说明防火墙、代理或 IPv6 路由有问题 - 强制走 IPv4：Linux/macOS 下临时加
CURL_IPRESOLVE=4 composer install -vvv，Windows 用set CURL_IPRESOLVE=4再运行 - 企业内网若用了中间人代理（如某安全网关），
curl -v会暴露 SSL 证书链异常，此时需联系运维确认代理策略
Could not find package xxx 的真实原因不是包不存在
这个报错几乎全是稳定性约束或源配置问题。Packagist 默认只索引 stable 版本，而你要装的是 dev-main、beta 或私有 Git 仓库里的包。
- 检查
composer.json里有没有"minimum-stability": "dev"，没有就加，或临时加--stability=dev - 如果是私有包，确认
repositories字段是否正确声明了 VCS 类型和 URL，例如：{"type": "vcs", "url": "https://git.example.com/my/package.git"} - 项目根目录若有空
"repositories": []，会彻底屏蔽全局镜像，删掉或改成"repositories": [{"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}] - 别信搜索引擎结果——有些包虽在 GitHub 存在，但作者没提交到 Packagist，必须手动加
vcs源才能用
最易被忽略的点：报错日志里混着 stdout 和 stderr，而 Composer 的关键错误（比如 SSL cert verify failed）只打在 stderr；但部分调试信息又在 stdout。捕获失败必须同时重定向两者，否则你会漏掉唯一线索。
