镜像配置不生效主因是三要素缺一不可：键名必须为单数repo.packagist、值必须是{"type":"composer","url":"https://.../"}格式的完整JSON、URL末尾必须带/，任一错误均静默回退至packagist.org。
直接结论：镜像不是“开了就通”，配错字段名、少斜杠、用错结构，Composer 会安静退回 packagist.org，连 warning 都不给——90% 的“file could not be downloaded”本质是镜像没生效，不是被墙。
为什么 composer config -g repo.packagist 总是不生效
这不是命令没运行，而是三个硬性条件缺一不可：
-
repo.packagist是唯一合法键名（注意是repo单数，不是repos或packagist.org） - 值必须是完整 JSON 对象：
{"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}；只写 URL 字符串会被当普通字符串存，不识别为源 -
url必须以/结尾：少这个斜杠，请求路径会拼成/composer/packages.json，直接 404
怎么确认镜像真在用，而不是“我以为它在用”
别信 composer config -g repo.packagist 的输出，要看实际发出去的请求：
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 运行
composer diagnose，找Repo packagist.org:这一行，后面域名必须是你配的镜像地址（比如mirrors.aliyun.com） - 新建空目录，执行
composer init -n && composer require monolog/monolog -vvv，第一行日志里Downloading https://的域名要匹配你的镜像 - 如果仍走
packagist.org，立刻检查项目级配置是否覆盖全局：composer config repo.packagist（不加-g），有输出说明项目自己写了源，优先级更高
composer install 卡在 downloading 时该怎么做
网络中断后，Composer 不会自动重试，缓存也容易损坏，但不用删 vendor 重来：
- 先执行
composer install --no-cache跳过本地缓存，避免读取损坏的临时文件 - 若仍失败，加
-vvv查看具体卡在哪一个 URL，再手动curl -I测试该地址是否可访问 - 国内用户建议提前设超时：
COMPOSER_NETWORK_TIMEOUT=300 composer install --retries=5，比默认 30 秒 + 3 次重试更扛波动
阿里云 / 腾讯云 / 清华源怎么选才不踩坑
不同镜像同步节奏和行为差异明显，选错反而更慢：
- 阿里云镜像同步延迟通常 1–6 小时，适合日常开发；但刚发布的包（如
laravel/pint v1.13.0）可能还没收录，此时composer show -p vendor/package返回空，而官网能打开，基本就是同步未到 - 腾讯云 CDN 覆盖广，某些地区响应更快，适合阿里云偶尔超时的场景；验证时重点看
composer config -g repositories.packagist.org输出是否含mirrors.cloud.tencent.com且无packagist.org字样 - 清华源需手动编辑
composer.json，并在repositories下显式添加"packagist.org": false，否则私有源可能干扰；适合 CI/CD 中要求配置可追踪、不依赖全局环境的项目
最常被忽略的点是：镜像只加速下载，不解决 Resolving dependencies 卡顿。如果你发现 composer update 卡在依赖解析几十秒，基本是 PHP 版本约束太宽或 require-dev 塞了太多工具链——换任何镜像都无效，得收紧约束、拆分 dev 包、锁定版本。
