Composer运行命令没反应？调试模式开启与镜像检测【速查】-composer-PHP中文网

卡在“resolving dependencies”是sat求解器本地暴力回溯版本约束所致，非网络问题；应通过composer update --dry-run -vvv观察回溯路径、--no-dev缩小范围、删require-dev或收紧模糊约束来解决。

composer运行命令没反应？调试模式开启与镜像检测【速查】

卡在 Resolving dependencies 是 SAT 求解器死循环，不是网络问题

看到这行不动，CPU 占用高、内存缓慢上涨，说明 Composer 还没发任何 HTTP 请求，纯属本地暴力回溯版本约束。此时换镜像、调 http.timeout、清缓存全无效。

常见诱因包括："^1.0 || ^2.0" 这类宽泛约束、"dev-main" 引入私有包、多个包 require 同一依赖的不同大版本（如 symfony/console^5 和 ^6 并存）。

先运行 composer update --dry-run -vvv，盯最后几行是否反复出现 Trying: vendor/package 或嵌套路径
临时缓解：加 --no-dev 跳过开发依赖，或删掉 require-dev 里非核心工具（如 phpstan/phpstan）
检查 vendor/composer/autoload_classmap.php 是否超过 2MB —— 过大会拖慢求解器

卡在 Downloading https://… 才是镜像或网络问题

这一行出现后无后续输出，说明请求已发出但没等到响应。process-timeout 在此阶段完全不生效，只有 http.timeout 和镜像本身起作用。

必须手动验证镜像地址是否真实可用：

运行 curl -I https://mirrors.aliyun.com/composer/packages.json，必须返回 HTTP/2 200
若卡在 Resolving host，是 DNS 问题；卡在 TLS handshake，可能是 OpenSSL 版本太老或企业代理证书未导入
阿里云当前稳定地址是 https://mirrors.aliyun.com/composer/（结尾必须有 /），别用 http:// 开头，也别加 /packages.json

镜像配置写了却没生效？优先级和写法都得对

Composer 的源优先级是：项目级 repositories > 环境变量 COMPOSER_REPO_PACKAGIST > 全局配置。只要 composer.json 里有 "repositories" 字段，全局镜像就彻底失效。

Discussion Composer

围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par

下载

验证是否真生效，不能只看 composer config -g --list：

全局实际生效源：composer config -g repositories.packagist.org.url（注意不是 repo.packagist）
项目级实际生效源：composer config repositories（在项目目录下执行），找 "packagist.org": { "type": "composer", "url": "..." }
正确写法（两行缺一不可）：composer config -g repositories.packagist.org.type composer 和 composer config -g repositories.packagist.org.url https://mirrors.aliyun.com/composer/

为什么 -vvv 日志没显示网络请求？缓存和内存限制在干扰

-vvv 本身不强制走网络——Composer 默认复用缓存的 packages.json。想看到真实请求，必须组合 --no-cache 和 -vvv。

另外，COMPOSER_MEMORY_LIMIT=-1 会触发 PHP memory_limit 检查失败，导致进程静默终止，日志被截断。

安全组合命令：COMPOSER_MEMORY_LIMIT=2G composer update --no-cache -vvv 2>&1 | tee debug.log
检查 PHP CLI 内存限制：php -i | grep memory_limit，确保不低于 512M
CI 或 Docker 中注意：php-cli 和 php-apache 的 php.ini 常不一致，CLI 模式需单独确认

真正卡住的地方，往往藏在 -vvv 日志开头几行——比如 Reading ./composer.json 失败说明 JSON 格式错误，比后面几百行冲突更早暴露根因；而 COMPOSER_MEMORY_LIMIT=-1 这种静默中断，最容易被忽略。