composer镜像配置失效的四大原因：键名必须为repo.packagist、type值必须显式写composer、url必须以/结尾、必须加-g参数；项目级repositories或环境变量composer_repo_packagist会覆盖全局配置；元数据缓存导致同步延迟，需用--refresh或手动清理；宝塔/docker/ci中因用户权限或上下文不一致易失效。
镜像配置没生效，90% 的 Composer 更新失败都卡在这一步。不是网络差、不是包不存在，而是你写的配置根本没被读到，Composer 静默 fallback 到 packagist.org，然后卡在 Loading composer repositories 或 Downloading 里不动。
composer config -g repo.packagist 命令为什么总不生效
这条命令不是“输完就生效”，它必须同时满足四个硬性条件，缺一就会写进无效字段，后续所有操作都走官方源：
-
repo.packagist是唯一合法键名——不能是repos.packagist（多 s）、repositories.packagist（新版也不认）、更不能是packagist.org - 第三个参数必须显式写
composer，这是type值，不是可选说明；漏掉它，Composer 2.0+ 直接忽略整条配置 - URL 必须以
/结尾：https://mirrors.aliyun.com/composer/✅，https://mirrors.aliyun.com/composer❌（拼出/composerpackages.json导致 404） - 必须带
-g参数，否则只改当前项目composer.json，换目录就失效
验证方式只有一种：运行 composer config -g repo.packagist，输出必须是完整 URL 字符串或标准 JSON 对象（含 "type": "composer" 和该 URL）。返回 null、空值、https://packagist.org，说明配置失败。
明明配了镜像，-vvv 日志里还在请求 packagist.org
Composer 有明确优先级：项目级 repositories > 环境变量 COMPOSER_REPO_PACKAGIST > 全局 repo.packagist。只要项目根目录的 composer.json 里存在 "repositories" 字段（哪怕只是空数组 []），全局配置就被跳过。
- 检查项目级是否覆盖：
composer config repositories（在项目目录下执行），看输出里packagist.org的url值是不是你设的镜像地址 - 检查环境变量：
echo $COMPOSER_REPO_PACKAGIST，它比所有 config 都高，会直接覆盖 - 如果
composer.json里已有"repositories": []，别手动删，用composer config --unset repositories清除后再重设
最准的验证不是看命令输出，而是跑一次 composer install -vvv | grep "packages.json"，确认最后一行 GET 请求的域名是不是你的镜像站。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
镜像同步延迟导致 update 找不到新版本
阿里云、清华镜像通常 5–30 分钟同步新包。你以为镜像已更新，但 composer update 还是 “Nothing to install or update”，是因为 Composer 默认复用本地缓存的 packages.json（15 分钟内不过期），根本不去镜像站拉最新元数据。
- Composer ≥ 2.5：用
composer update --refresh，它只丢弃packages.json和provider-*.json缓存，不碰 ZIP 包，轻量且精准 - Composer ≤ 2.4：手动删缓存对应路径，比如
rm -rf $(composer config --global cache-dir)/repo/https---mirrors-aliyun-com-composer - 别信
composer clear-cache——它清的是 ZIP 和 provider 缓存，对元数据缓存无效
验证镜像是否真同步了你要的包，直接查接口：curl -s https://mirrors.aliyun.com/composer/p2/vendor/package.json | jq -r '.packages."vendor/package" | keys[]' | sort | tail -3，对比官方源输出即可。
宝塔、Docker、CI 中镜像配置失效的常见原因
全局配置在这些环境里特别容易失效，因为用户权限或执行上下文不一致：
- 宝塔中，网站 PHP CLI 用户（如
www）读不到root的~/.composer/config.json，建议改用项目级配置：composer config repo.packagist composer https://mirrors.aliyun.com/composer/（不加-g），它会自动写入composer.json的repositories字段，可提交 Git - Docker 构建时，
composer config -g写进了临时容器的/root/.composer，但运行时用户是www-data，根本读不到；应把镜像配置写进composer.json或用COMPOSER_REPO_PACKAGIST环境变量注入 - CI 流水线中，有些脚本会在
composer install前自动注入私有仓库配置，覆盖你设的镜像；运行composer show -p查看实际生效的源列表
真正容易被忽略的是：镜像只代理 dist（ZIP 包），不代理 source（Git clone）。如果某个包启用了双模式，composer install 仍会直连 GitHub，这部分无法通过换镜像加速——得看 composer.lock 里 "source" 字段的 URL 才知道。
