根本原因是国内直连 packagist.org 受 DNS 污染、TLS 握手延迟或中间设备干扰导致连接 hang 住；应切换为 https://packagist.cn 镜像并调高 process-timeout 至 1800，同时禁用 secure-http（调试用）并关闭 repository discovery。
Composer install/update 时卡在 Reading composer.json 或 Resolving packages 超时
根本原因不是网络慢，而是 Composer 默认通过 HTTPS 访问 packagist.org（全球主源），而国内直连常因 DNS 污染、TLS 握手延迟或中间设备干扰导致连接 hang 住——表现为无报错、无进度、长时间无响应，Ctrl+C 后才看到超时提示。
实操建议：
- 先确认是否真卡住：运行
composer install -v（加-v显示详细日志），观察最后停留在哪一步；若停在Downloading https://repo.packagist.org/packages.json，基本可锁定是源问题 - 临时绕过：执行
composer config -g repo.packagist composer https://packagist.phpcomposer.com（已失效）——注意该镜像早已下线，别再试 - 当前有效方案：切换为
https://packagist.cn（清华 TUNA 维护的官方镜像），命令为：composer config -g repo.packagist composer https://packagist.cn
- 如项目级配置优先于全局，进项目目录后改用
composer config repo.packagist composer https://packagist.cn（去掉-g）
执行 composer update 报错 cURL error 28: Operation timed out
这是 cURL 层面的硬超时，Composer 默认只给每个 HTTP 请求 300 秒（5 分钟），但国内首次拉取完整包索引（packages.json，约 10MB+）可能因 TLS 握手重试、TCP 重传失败而耗尽时间。
实操建议：
- 调高超时阈值：运行
composer config -g process-timeout 1800（单位秒，设为 30 分钟） - 同时禁用 HTTPS 验证（仅限调试）：
composer config -g secure-http false，避免因证书链校验失败卡住（不推荐长期开启） - 若仍失败，检查本地 DNS 是否污染：执行
nslookup repo.packagist.org，看返回 IP 是否属于 Cloudflare（如104.16.24.35等）；若返回异常 IP，需手动修改系统 hosts 或换 DNS（如114.114.114.114）
为什么换源后 composer require 仍慢或失败
换源只影响元数据（packages.json）下载，但实际 ZIP 包仍从原作者 GitHub/GitLab 页面下载——如果包依赖的是 GitHub 上的 dev-master 分支，Composer 会尝试 git clone，此时又回到直连 GitHub 的问题。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
实操建议：
- 对 GitHub 源头慢：设置 Git 协议代理，例如
git config --global url."https://github.com/".insteadOf git@github.com:，强制走 HTTPS - 更彻底方案：启用 GitHub 镜像加速，如使用
ghproxy.com，将包地址中的github.com替换为github.com.ghproxy.com；但需注意 Composer 不自动识别，得靠repositories手动覆盖 - 在
composer.json中显式声明 GitHub 镜像仓库（慎用）："repositories": [ { "type": "composer", "url": "https://packagist.cn" }, { "type": "package", "package": { "name": "vendor/package", "version": "dev-main", "dist": { "url": "https://github.com.ghproxy.com/vendor/package/archive/refs/heads/main.zip", "type": "zip" } } } ]
CI/CD 环境中持续超时，但本地正常
CI 环境（如 GitHub Actions、GitLab CI）通常无 DNS 缓存、无代理、且出口 IP 可能被 Packagist 限流，导致比本地更易触发超时。
实操建议：
- 在 CI 脚本开头加预热步骤：
curl -I -s https://packagist.cn/packages.json -o /dev/null，提前触发 DNS 解析和 TCP 连接池建立 - GitHub Actions 推荐用
php-actions/composerAction，它内置了镜像源和超时重试逻辑 - GitLab CI 可在
.gitlab-ci.yml中设置缓存：cache: key: ${CI_COMMIT_REF_SLUG} paths: - vendor/ - ~/.composer/cache/，避免每次重装依赖 - 若用自建 runner，检查其所在 VPC 是否启用了 SNAT 或设置了安全组限制出向 HTTPS 流量
最易被忽略的一点：Composer 2.2+ 默认启用 https://packagist.org 的「repository discovery」机制，即使你配了镜像，它仍会尝试访问原始源做健康检查。关掉它：composer config -g repos.packagist.org false，才能让镜像真正生效。
