composer卡在“loading composer repositories”是因packagist.org在国内不可达，必须配置正确镜像：键名repo.packagist、type值composer、url为https且末尾带斜杠，推荐阿里云镜像https://mirrors.aliyun.com/composer/。
不配镜像，composer install 卡在 Loading composer repositories with package information 是常态，不是你网络差，是 packagist.org 在国内基本不可达——DNS慢、TLS握手失败、CDN缺失，三者叠加导致首字节延迟超 30 秒甚至直接 503。必须配，而且得配对。
composer config -g repo.packagist 命令为什么总不生效
90% 的失败不是网络问题，是命令写错三个硬性条件，且 Composer 会静默忽略错误，不报错也不提示。
-
repo.packagist是唯一合法键名：不能多一个s（repos.packagist❌），也不能少repo.（packagist❌） -
composer是 type 值，必须显式写出：省略后 Composer 2.0+ 直接 fallback 到官方源，不警告 - URL 必须是 HTTPS + 末尾带斜杠：
https://mirrors.aliyun.com/composer/✅，http://...或https://mirrors.aliyun.com/composer（缺 /）❌，后者会导致请求/composerpackages.json404
验证是否写入成功，只看这一条命令输出：composer config -g repo.packagist。输出应为完整 JSON 对象或至少是 URL 字符串；如果返回空、null 或报 Key does not exist，说明没写进去，立刻重敲。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
项目级镜像配置比全局更可靠
全局配置看着省事，但在 CI/CD、宝塔、Docker 或团队协作中极易失效——-g 写的是当前用户家目录下的 ~/.composer/config.json，而 GitHub Actions 用 runner 用户，宝塔用 www 用户，它们根本读不到你的配置。
- 进项目根目录（含
composer.json），执行：composer config repo.packagist composer https://mirrors.aliyun.com/composer/（去掉-g） - 该命令会自动在
composer.json顶层插入"repositories"字段，key 固定为"packagist"，不会覆盖已有私有源 - 如果项目已有
"repositories"数组（比如加了私有包源），别手动编辑 JSON —— 用命令追加，否则可能误删其他源 - 改完必须删掉
vendor/和composer.lock，再跑composer install（不是update）
怎么确认镜像真正在用
composer config -g repo.packagist 只显示“设了什么”，不反映“实际发了什么请求”。真正验证，得看真实 HTTP 请求地址：
- 执行：
composer show -v | head -n 5 - 观察日志里出现的
Downloading https://...地址： - 含
packagist.org→ 镜像未生效或被项目配置覆盖 - 含
aliyun.com/tencent.com→ 镜像正常 - 含
phpcomposer.com或laravel-china.org→ 地址已过期，2026 年多数已下线或跳转失败
注意：composer update 卡在 Resolving dependencies 阶段几十秒？那和镜像完全无关——镜像只加速下载，不解决依赖解析慢的问题。这时候要查 composer.json 里的 PHP 版本约束是否太宽、dev 包是否未锁定、require-dev 是否塞了太多工具。
