加 --verbose 是最快定位 composer 网络故障的方式，它强制走完整请求链路，卡在哪一环一目了然；composer 默认静默吞掉 dns 失败、tcp 超时、tls 握手失败等底层错误，仅显示“loading composer repositories…”停住不动或模糊报错。
加 --verbose 是最快定位 Composer 网络故障的方式，它强制走完整请求链路，卡在哪一环一目了然。
为什么 composer install 卡住却没报错？
Composer 默认会吞掉底层网络错误：DNS 失败、TCP 连接超时、TLS 握手失败、HTTP 响应异常全被静默跳过。你看到的只是“Loading composer repositories…”停住不动，或突然报 Could not fetch 却不告诉你哪个 URL、哪个包、哪一步失败。
-
--verbose（或-v）不是“输出更多日志”，而是让 Composer 把每一步真实干了什么打出来：解析哪个composer.json、向哪个镜像源发了GET、用了哪个User-Agent、是否重试、重试几次 - 关键线索藏在最后几行：比如
Failed to connect to repo.packagist.org port 443: Connection timed out→ 卡在 TCP 连接；SSL certificate problem: unable to get local issuer certificate→ TLS 层失败 - 别用
--dry-run配合--verbose：它会跳过真实下载，看不到 HTTP 请求细节
怎么区分是 DNS/IPv6 还是源本身慢？
国内用户最常踩的两个隐形坑：DNS 解析失败和 IPv6 fallback 超时，它们都不会报错，只会让 composer install 在 Resolving dependencies 阶段卡几分钟。
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 验证 IPv6 是否干扰：运行
curl -v https://packagist.org 2>&1 | grep "Connected to"，如果看到2a03:2880:这类地址且后续无响应，基本就是 IPv6 先试、超时再切 IPv4 导致的叠加延迟 - 临时绕过：命令前加
CURL_IPRESOLVE=4，例如CURL_IPRESOLVE=4 composer install -v - 测 DNS 和源可用性：用
curl -o /dev/null -s -w "%{http_code} %{time_total}s" --connect-timeout 5 https://mirrors.aliyun.com/composer/packages.json，返回000是 DNS 或连接失败，200但time_total > 2.0就说明这个镜像源不适合当前网络
composer diagnose 为什么不能代替 --verbose？
composer diagnose 只检查“能不能通”，而 --verbose 是“真去连一次”。前者 OK 不代表后者能成功。
-
composer diagnose会 ping 通repo.packagist.org、检查 vendor 目录可写、确认 openssl 扩展已启用——但它不会发起 HTTPS 请求，也不会触发 TLS 握手或下载元数据 - 典型反例：公司内网允许 ICMP（ping），但拦截 443 出口；或本地 CA 证书缺失导致 TLS 握手失败；或镜像源路径已变更（如阿里云从
/composer/改为/php/composer/）——这些diagnose全部检测不到 - 真正要验证“能不能装”，唯一轻量方式就是
composer install -v，它等价于一次最小化的真实安装尝试
网络问题最麻烦的地方不是报错，而是不报错——--verbose 强制暴露真实链路，但输出里混着大量无关信息；重点盯住最后 10 行的 HTTP 状态、CURL 错误码和 URL 路径，比看全文更有效。
