只有 -vvv 能暴露真实报错，它输出 curl 请求头、原始响应体、内部调用栈、临时路径及平台扩展缺失提示；-v/-vv 仅显示安装进度，无法定位网络、sat、zlib 等深层问题。
composer install -vvv 是唯一能定位真实报错的开关
加 -v 或 -vv 基本没用，它们只显示“正在安装 xxx”，不暴露网络请求、插件堆栈、SAT 求解卡点或 zlib 解码失败。只有 -vvv 会打印：cURL 完整请求头、原始未解压响应体、RuleWatchGraph.php 内部调用栈、临时文件路径、以及 ext-foobar 这类平台扩展缺失提示。
常见误判场景：
- 日志停在
Resolving dependencies through SAT后无下文？不是网络慢，是逻辑回溯风暴导致内存耗尽 - 看到
zlib_decode(): data error？说明中间代理或 CDN 损坏了压缩流，不是源站问题 -
-vvv不输出？先查config.verbose是否被设为false，或config.platform里写了不存在的扩展（如"ext-redis": "5.0"），Composer 会在初始化阶段直接退出
终端滚动太快？用重定向最稳：composer install -vvv 2>&1 | tee debug.log，之后 grep -i "error\|exception\|failed\|zlib\|SAT" debug.log 快速聚焦。
报错停在 “Script failed” 时怎么看到真实 PHP 错误
Composer 默认吞掉子进程的 stderr，你只看到 Script xxx handling yyy returned with error code 1，却不知道哪行崩了。必须靠 -vvv 把底层命令和完整错误透出来。
关键点：
- 脚本是 PHP 文件？检查开头是否有
#!/usr/bin/env php，Linux/macOS 下还要chmod +x script.php - Windows 上别写
script.php，显式写"php script.php"，否则系统找不到解释器 - 真实错误只在
-vvv下可见：比如Fatal error: Uncaught Error:、ParseError、Class not found都藏在 stderr 里
日志里没出现镜像域名，说明根本没走镜像
运行 composer install -vvv 2>&1 | head -n 10 | grep Downloading，第一行 URL 才是真实请求地址。只看 composer config -g repo.packagist 输出没用——它可能配对了，但被更高优先级配置覆盖。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
高频覆盖源：
- 项目根目录
composer.json中含"repositories"字段：哪怕只是空数组[]，也会彻底屏蔽全局镜像 - CI/CD 环境中，
root用户配的镜像，实际运行的是www用户，得用sudo -u www composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ -
repo.packagist键名写错（比如写成repos.packagist或packagist.org）：Composer 2.0+ 会静默忽略，composer config -g repo.packagist输出为空或报Key not found
报错含 “Permission denied” 或 “Connection refused”，别急着调 Composer 配置
这类错误 90% 和 Composer 本身无关，是系统级问题。
“Permission denied” 多因目录归属污染：
- 报错里带路径，比如
file_put_contents(/path/to/vendor/autoload.php): Permission denied→ 直接ls -ld vendor/ composer.lock - 若属主是
root，而你是普通用户运行，执行sudo chown -R $USER:$USER vendor/ composer.lock，别用chmod 777
“Connection refused” 或 cURL error 7：
- 先
ping packagist.org，返回unknown host就是 DNS 问题，改/etc/resolv.conf加nameserver 8.8.8.8 - 再
curl -v https://mirrors.aliyun.com/composer/，卡在* Connected to是建连失败，卡在* TLS handshake是证书链或中间人代理问题 -
http.timeout参数完全无效——它只管 HTTP 响应头时间，不参与 DNS 解析或 TCP 握手
真正卡住的地方，往往不在报错第一行，而在 -vvv 日志末尾那几行堆栈里；而权限和网络问题，几乎从不发生在 Composer 的 PHP 代码里，而是操作系统那一层。别跳进配置文件反复检查，先抓真实请求和真实属主。
