答案：卡在“loading composer repositories”是因无法连通元数据源，主因dns污染或tls握手失败；须先用curl测试连通性，再严格配置镜像（repo.packagist、type composer、url末尾带/），并注意用户权限与ipv4强制设置。
卡在Loading composer repositories是DNS或TLS问题
这一步根本没开始解析依赖，纯粹是连不上元数据源。报错里出现 Could not fetch https://packagist.org/packages.json 或日志停在 Loading composer repositories，基本可以排除 Composer 本身或 PHP 版本问题。
先别急着换镜像，用 curl -I https://packagist.org/packages.json 测试——如果返回 SSL connect error 或超时，说明是 TLS 握手失败或 DNS 污染；如果返回 301 或直接卡住，大概率是网络策略拦截或 IPv6 干扰。
- 强制走 IPv4：
CURL_IPRESOLVE=4 composer install（Linux/macOS）或set CURL_IPRESOLVE=4（Windows CMD） - 禁用 IPv6（临时）：
COMPOSER_NO_IPV6=1 composer install - 验证 DNS 是否正常：
nslookup packagist.org，若失败，改/etc/resolv.conf加nameserver 8.8.8.8
镜像配置写错三处就等于没配
很多用户执行了 composer config -g repo.packagist https://mirrors.aliyun.com/composer/ 就以为搞定了，结果日志里还是出现 packagist.org。原因几乎全是这三处写错了：
- 键名必须是
repo.packagist（单数repo，不是repos或repositories.packagist） - 中间必须显式写
composer作为 type 值：composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ - URL 必须以
/结尾，少一个斜杠会拼成/composerpackages.json，直接 404
配完立刻验证：composer config -g repo.packagist 输出必须是 {"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}，否则静默失效。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
宝塔、Docker、CI 里镜像不生效，其实是用户权限问题
你在终端用 root 配好了镜像，但宝塔面板跑 composer install 时用的是 www 用户，它读不到 /root/.composer/config.json。Docker 容器里默认是 www-data 或非 root 用户，也一样。
验证当前执行用户：whoami 或查部署日志里的 UID=xxx，再用 id -un xxx 查用户名。确认后重配：
- 宝塔中：
sudo -u www composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ - Docker 中：在 Dockerfile 里用
USER www-data后再执行 config 命令，或直接写进~/.composer/config.json（确保路径属主正确） - 更稳妥的方案是项目级配置：
composer config repo.packagist composer https://mirrors.tuna.tsinghua.edu.cn/composer/（不加-g），它会写进composer.json的repositories字段，随代码走，不依赖用户环境
卡在Resolving dependencies和网络完全无关
这一步 PHP 正在暴力回溯所有可能的版本组合，耗的是 CPU 和内存，不是带宽。日志里反复出现 Trying... 或长时间无输出，说明 Composer 在“猜”哪个版本能同时满足所有 require 和 require-dev。
- 检查
composer.json是否写了宽泛约束，比如"^1.0 || ^2.0"或引入了dev-main这类不稳定分支 - 删掉
"platform": {"php": "7.4"}这类硬编码（尤其 Webman 项目常见），它会让 Composer 强制降级找旧包 - 临时加大内存：
php -d memory_limit=-1 composer install（默认 1.5GB 常不够） - 跳过平台检查快速验证：
composer install --ignore-platform-reqs，如果秒过，说明就是环境不匹配导致的“假卡”
真正难解的依赖冲突不会卡住，而是直接报错；卡住的，八成是约束爆炸 + 内存不足，或者某个私有包源不可达却没设 fallback。
