composer卡死需先运行-vvv看最后几行：停在resolving dependencies是求解器问题，非网络；停在downloading是http层问题；停在executing command是子进程卡死；停在generating autoload files是文件系统问题。
Composer 卡死不是“没反应”，而是卡在某个具体环节——不看 -vvv 输出，盲目换镜像、清缓存或调超时，大概率白忙。
看最后几行输出，锁定卡点类型
运行 composer install -vvv 或 composer update -vvv，紧盯终端最后 3–5 行：
- 停在
Resolving dependencies：不是网络问题，是 SAT 求解器在暴力回溯，可能因版本约束太宽（如"^1.0 || ^2.0"）、私有包dev-main引入循环，或 PHP 内存不足；此时http.timeout完全无效 - 停在
Downloading https://...：HTTP 层卡住，重点查镜像可用性、TLS 握手、代理或 DNS；可手动curl -I https://mirrors.aliyun.com/composer/packages.json验证 - 停在
Executing command (CWD: ...)：子进程（如git clone、unzip）卡死，process-timeout才起作用，http.timeout不管用 - 停在
Generating autoload files后无响应：文件系统层问题，常见于 WSL2 下 symlink 解析慢、APCu 未启用 CLI 模式、或vendor/权限异常
确认镜像是否真生效且可用
国内用户最常踩的坑是：配了镜像，但 URL 已失效或路径错位。别信 composer config -g repo.packagist 的输出，要亲手验证：
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 阿里云镜像当前稳定地址是
https://mirrors.aliyun.com/composer/（不是mirrors.aliyun.com/composer/packages.json） - 腾讯云推荐用
https://packagist.proxy.tencent.com/（非mirrors.cloud.tencent.com子域） - 清华源已弃用 HTTP，HTTPS 地址为
https://packagist.phpcomposer.com，但需注意该镜像近期偶发不可用，建议备选阿里云 - 切完必须执行
composer clear-cache，否则旧缓存仍会尝试访问失效地址
内存和超时参数必须加对位置
两个关键配置常被写错位置，导致完全无效：
-
http.timeout控单次 HTTP 请求，单位秒，设为600较稳妥：composer config -g http.timeout 600 -
process-timeout控整个命令生命周期（含脚本执行），设为1200或更高：composer config -g process-timeout 1200 - PHP 内存限制必须用
php -d memory_limit=2G composer install，写成composer -d memory_limit=2G install是无效的 - CI 环境中尤其要注意：GitHub Actions 默认 PHP 内存常为 128M，GitLab CI 可能更低，不加
-d就容易卡在Resolving dependencies
绕过干扰项，快速验证真实瓶颈
有些选项不是“优化”，而是临时排除干扰的诊断开关：
- 加
--no-dev：跳过require-dev，大幅降低依赖图复杂度，常能绕过 SAT 死锁 - 加
--ignore-platform-reqs：跳过 PHP 版本、扩展检查，排除 WSL/Docker 中因ext-zip缺失导致的假死 - 加
--no-scripts --no-plugins：禁用所有钩子脚本，避免某条post-install-cmd卡住整条链 - 用
composer update --dry-run -v替代直接 update，它不改任何文件，但会完整走一遍求解流程，并在末尾明确指出冲突源头
真正难排查的卡死，往往藏在“看不见”的地方：WSL2 时间不同步导致 TLS 握手失败、auth.json 里 GitHub Token 过期却不报错、或 composer.lock 里某个包被硬编码为 SSH 地址却没配好 SSH key。这些不会出现在 -vvv 日志主干里，得靠 curl -v、ssh -T git@github.com、或翻 composer.lock 手动比对 URL 协议才能揪出来。
