镜像配置后仍回退到packagist.org是因composer 2.2+默认在镜像返回404/503时自动fallback至官方源以应对同步延迟，属正常设计而非配置失效；需检查镜像更新时间、清除缓存、排除项目级repositories覆盖及验证真实请求url。
为什么镜像配置后还会回退到 packagist.org
不是配置没生效，而是 Composer 在镜像返回 404/503 时自动 fallback 到官方源——这是 2.2+ 版本的默认行为，目的是防同步延迟。你看到 Downloading https://api.packagist.org/... 日志，大概率是镜像里还没同步到你要的包（比如刚发布不到 1 小时），而非配置失效。
常见错误现象包括：Package not found、Could not find package、Resolving dependencies 卡住后突然切到官方源下载 packages.json。这不是 bug，是设计如此。
- 别急着关
"packagist.org": false或删镜像配置——关掉 fallback 会让缺失包直接报错，无法兜底 - 先查镜像页底部的“最后更新时间”，比如
https://mirrors.aliyun.com/composer/页面右下角，确认是否滞后超过 30 分钟 - 用
composer require monolog/monolog --no-install -vvv观察真实请求链：若先命中镜像（mirrors.aliyun.com）再 fallback 到api.packagist.org，说明 fallback 正常工作
项目级 repositories 配置覆盖全局源
即使 composer config -g repo.packagist 显示正确 URL，只要项目根目录 composer.json 里有 "repositories" 字段，它就优先生效——而且不校验是否含 "packagist.org": false，直接跳过 fallback 逻辑。
快速确认方式：composer config repo.packagist（不带 -g），如果输出是阿里云地址，说明被项目级盖掉了。
- 临时验证：进项目目录后执行
composer config --unset repositories，再跑composer require --no-install -vvv看是否回归全局源 - 长期方案：删掉
composer.json中整个"repositories": [...]块，或改写为只保留镜像 + 显式禁用官方源：{"repositories": [{"type":"composer","url":"https://mirrors.aliyun.com/composer/"}],"packagist.org": false} - 注意：复数形式
"repos.packagist"在 Composer 2.0+ 中无效且不报错，只会静默忽略
缓存残留导致元数据仍走旧源
Composer 缓存里存的是 packages.json 快照，包含包列表和下载链接。不清缓存，即使换源成功，它仍按旧元数据发起请求——表现为日志里 URL 是镜像域名，但实际下载失败或重试多次。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
清缓存不是可选步骤，是必做动作。尤其当你从一个镜像切到另一个（如阿里云 → 腾讯云），旧缓存会继续指向原域名。
- 执行
composer clear-cache后，检查缓存目录是否真空：ls -la ~/.composer/cache/（Linux/macOS）或dir %APPDATA%\Composer\Cache\（Windows），应为空或只剩空子目录 - 更彻底方法：
composer config -g cache-dir /tmp/composer-cache-empty再clear-cache，避免旧缓存路径干扰 - 验证是否清干净：运行
composer require monolog/monolog --no-install -vvv，看首次请求是否为新镜像 URL，而非 304 或重定向
全局配置键名或协议写错导致静默失效
composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ 这条命令看似简单，但三个细节错一个就白配：键名必须是单数 repo.packagist（不是 repos.packagist），中间 composer 是 type 值不能省，URL 必须带 https:// 前缀。
错误示例：composer config -g repos.packagist composer mirrors.aliyun.com/composer/ —— 输出可能显示成功，但实际配置无效，composer install 仍走官方源。
- 验证是否真写进去了：
composer config -g repo.packagist，输出应为纯 URL 字符串或 JSON 对象，绝不能是空、null或https://packagist.org - 旧版 Composer（2.2–2.4）用
--unset清配置容易卡在Could not parse version constraint，显式赋值比 unset 更稳 - 如果
which php和composer diag显示 PHP 路径不一致（比如 phpEnv 管理的 PHP 和系统 PHP 混用），那全局配置只对匹配的 PHP 环境生效
最麻烦的不是配错，而是配对了却因缓存、项目级覆盖或 fallback 机制被误判为失效。盯住 -vvv 日志里的真实请求 URL，比任何配置输出都可靠。
