composer换源需满足三个硬性条件：repo.packagist必须为单数、type值显式设为composer、url须https且以/结尾；项目级配置优先于全局，且一旦存在repositories字段则全局配置失效。
Composer装依赖卡在 Loading composer repositories 或 Downloading，基本不是网络差，而是镜像源根本没配对——命令写错、缓存没清、URL少斜杠，三者任一出问题都会静默失效。
composer config -g repo.packagist 命令为什么总不生效
这条命令看着简单，但缺一不可的三个硬性条件常被忽略：
-
repo.packagist必须是单数repo，写成repos.packagist或repositories.packagist.org都会写进无效字段，不报错也不生效 - 末尾必须显式带上
composer作为 type 值，省略后 Composer 2.0+ 直接 fallback 到https://packagist.org - URL 必须是 HTTPS 且以
/结尾：https://mirrors.aliyun.com/composer/✅，https://mirrors.aliyun.com/composer❌（拼出/composerpackages.json导致 404）
验证是否真写入：运行 composer config -g repo.packagist，输出必须是完整 JSON 对象，例如 {"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}。空、null、报错、或返回 https://packagist.org，都说明失败。
怎么确认 Composer 实际连的是哪个源
别只信配置命令回显“成功”，要看真实请求行为：
- 查配置：
composer config -g repo.packagist.url或composer config -g repositories.packagist.org，输出必须是你设的镜像域名 - 看诊断：
composer diagnose，找到 “Repo:” 那行，域名必须匹配你配的镜像（如mirrors.aliyun.com） - 抓请求：
composer install -vvv 2>&1 | grep -i "downloading\|reading"，日志里出现的 URL 必须含镜像域名，且路径以/packages.json或/p2/结尾
如果这三处都对，但下载仍慢或失败，大概率是本地 DNS 解析异常、CA 证书过旧，或项目用了已废弃的 fxp/composer-asset-plugin（它不走 Composer 镜像配置）。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
项目级配置比全局更可靠，尤其在 CI 和团队协作中
全局配置在宝塔、Docker 或 CI 流水线中容易因用户权限失效（比如 www 用户读不到 root 的 ~/.composer/config.json），项目级配置可提交 Git，所有人行为一致：
- 进项目根目录，执行：
composer config repo.packagist composer https://mirrors.tuna.tsinghua.edu.cn/composer/（去掉-g） - 该命令会自动在
composer.json顶层写入"repositories"字段，key 固定为"packagist"，不会覆盖已有私有源——前提是原repositories是对象结构（不是数组） - 如果
composer.json已有"repositories": []数组，别手动覆盖，改用命令追加，否则可能删掉私有包源
换源后首次 composer install 若报 hash 校验失败，直接删掉 vendor 和 composer.lock 重来即可。
换源后还卡在 Resolving dependencies？和镜像完全无关
镜像只加速元数据拉取和 ZIP 包下载，不参与依赖解析逻辑：
-
composer update卡在Resolving dependencies几十秒甚至几分钟，基本可以确定是composer.json写法或本地环境导致的 - 常见诱因：
"php": "^7.4 || ^8.0"这类宽泛版本约束、大量未锁定的dev-main包、require-dev里塞了太多工具 - 这类问题在 Composer 2.9.6 中虽有优化，但本质仍是本地 PHP 版本、约束粒度和依赖图复杂度决定的，换镜像毫无作用
真正容易被忽略的是：项目级配置一旦存在 "repositories" 字段（哪怕为空），全局配置就会被完全忽略——这点和键名无关，只和作用域优先级有关。
