Composer config -g repo.packagist 命令失效的根本原因是键名错（应为单数repo.packagist）、漏掉type值composer、URL末尾缺/，三者任一出错即静默回退官方源；验证须输出完整JSON或纯URL且含镜像域名，-vvv日志中Downloading地址才为真实请求源。
composer config -g repo.packagist 命令为什么没生效
根本原因就三个：键名写成 repos.packagist（多一个 s）、漏掉中间的 composer 类型值、URL 少了末尾斜杠 /。Composer 2.9.6 不报错也不提示，直接静默 fallback 到 https://packagist.org。
验证是否真写进去了：composer config -g repo.packagist 输出必须是完整 URL 字符串或 JSON 对象（如 {"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}）。如果返回空、null、或者还是官方地址，说明命令压根没成功。
-
repo.packagist是唯一合法键名，packagist.org或repositories.packagist都无效 -
composer是必填 type 值，不是可选参数，命令里必须显式写出 - URL 必须 HTTPS 且以
/结尾：https://mirrors.aliyun.com/composer/✅，https://mirrors.aliyun.com/composer❌（会拼出 404 路径）
如何验证镜像是否真在用
光看 config 输出没用，得看到网络请求打到镜像域名才算数。唯一可靠方式是加 -vvv 看日志。
执行：composer install -vvv 2>&1 | grep "Downloading"，观察输出里的域名。出现 mirrors.aliyun.com 或 mirrors.tuna.tsinghua.edu.cn 才算真正走镜像；如果还是 packagist.org，说明配置被覆盖或根本没生效。
- 项目级
repositories字段会直接覆盖全局镜像，检查composer.json顶层是否有"repositories"键 - 临时绕过所有自定义源测试：
composer install --no-plugins --repository=https://packagist.org -vvv，如果这时反而快了，就是项目配置在作祟 - CI 或宝塔环境常见问题：全局配置写在
/root/.composer/config.json，但实际执行用户是www，得用sudo -u www composer config -g ...单独配
项目级配置比全局更稳，尤其在团队协作时
全局配置容易被权限、用户、Docker 容器环境干扰。项目级配置写进 composer.json，拉代码即生效，行为一致。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
进项目根目录，运行：composer config repo.packagist composer https://mirrors.aliyun.com/composer/（注意不加 -g）。这条命令会自动向 repositories 数组追加 packagist 条目，不破坏已有私有源。
- 如果
composer.json原本是"repositories": {}，命令会转成标准数组并插入 - 如果已有
"repositories": [ ... ]，新条目会追加到末尾，不会清空原有私有仓库 - 改完必须运行
composer update --lock，否则composer.lock还记着旧源地址，后续安装仍可能校验失败
换镜像后还是卡在 Resolving dependencies 或 Loading repositories
镜像只加速下载环节（Downloading、Fetching package），对 Resolving dependencies 和 Loading composer repositories 没作用——这两步是本地依赖求解和元数据解析，和网络源无关。
如果卡在这两步，优先排查：
- 旧缓存残留：
composer clear-cache，再删掉vendor/和composer.lock，重跑composer install --no-cache - 废弃插件拖累：比如
fxp/composer-asset-plugin，它绕过 Composer 镜像机制，单独请求 Bower/NPM 源，国内没镜像，建议升级框架或移除 - PHP zlib 扩展异常：出现
Failed to decode response: zlib_decode(): data error，检查php.ini或重启 PHP
真正容易被忽略的是：composer.lock 文件本身绑定了源地址哈希，换镜像后不重建 lock 文件，就会反复校验失败——这不是镜像问题，是文件不匹配。
