答案是元数据缓存滞留：composer默认复用15分钟内未过期的本地packages.json缓存，不发起远程校验；需用composer update --refresh（≥2.5）强制刷新元数据，或手动删除对应repo缓存子目录。
composer update 说“Nothing to install or update”但明明有新版本
这是最典型的元数据缓存滞留现象：Composer 默认复用本地 packages.json 缓存（TTL 15 分钟），哪怕镜像站已同步 monolog/monolog v3.6.0，它也不会发请求，直接按旧列表算出“无更新”。composer clear-cache 对此无效——它清的是 ZIP 包和部分 provider 缓存，但 packages.json 会立刻重建并继续复用旧快照。
正确做法是：
- 先确认 Composer 版本 ≥ 2.5：
composer --version；如果不是，得手动删缓存子目录 - 运行
composer update --refresh，它只丢弃packages.json和provider-*.json，不碰已下载的 ZIP，轻量且精准 - 执行后立刻再跑
composer update vendor/package-name，新版本就能被识别
项目里改了镜像配置却没生效
项目级 repositories 字段会完全屏蔽全局镜像设置，这是最隐蔽的失效原因。很多人复制模板时留着已停更的 https://packagist.phpcomposer.com，结果 composer install 静默 fallback 到官方源，而别人走的是阿里云镜像——同一份 composer.lock 在不同机器上装出不同行为。
验证与修复步骤：
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 查全局配置：
composer config -g repo.packagist，输出应为完整 URL（如https://mirrors.aliyun.com/composer/） - 查真正生效的源：
composer config --list | grep repositories.packagist.url；如果为空，说明被项目级composer.json中的"repositories"劫持 - 打开项目根目录
composer.json，搜索repositories；若有，删掉或改成当前有效镜像地址 - 临时验证：
composer config --unset repositories（不加-g），再试composer update
composer show -a 返回的版本列表不准
composer show -a vendor/package 输出的 versions 行，就是 Composer 当前“看到”的全部 tag 和分支——但它看到的，取决于三件事：生效的镜像源、本地缓存是否过期、该镜像源本身是否已同步到你要的版本。开发分支（如 dev-main）尤其容易踩坑，因为主流中文镜像默认只同步 stable tag，跳过 dev- 分支和 @beta 版本。
快速诊断：
- 强制跳过缓存查网络：
composer show -a vendor/package --no-cache；如果这时能列出新版本，就坐实是缓存问题 - 检查镜像同步状态：
curl -I https://mirrors.aliyun.com/composer/packages.json，必须返回 HTTP 200 且Last-Modified时间合理 - 临时绕过镜像元数据：
composer require vendor/package:dev-main --prefer-source，直接克隆 Git（仅调试用） - 稳妥方案：
composer config --unset repositories切回官方源，再试require
PHP 版本错位导致镜像元数据解析失败
报错 “Your PHP version (7.4.33) does not satisfy that requirement” 但 php -v 显示 8.2？这不是镜像问题，而是 Composer 实际调用的 PHP 解释器路径和你终端里看到的不一致。镜像源只管下载快慢，不参与版本判断。
关键检查点：
- 运行
which php和composer diagnose，对比两者的 “PHP binary” 路径是否一致 - 如果不一致，说明 Composer 没走你期望的 PHP —— 别改镜像，先修
PATH或显式指定解释器，例如：/opt/homebrew/bin/php82 /usr/local/bin/composer install - 检查
config.platform.php是否伪造了平台版本；它会让 Composer 在解析时假装是某个 PHP 版本，但不会改变 runtime 行为，极易引发ParseError - 多 PHP 版本共存时，全局镜像配置在 CI 中可能完全失效，因为
config.platform.php不校验真实环境是否真装了对应版本
repositories 字段的优先级覆盖和 config.platform.php 的“伪兼容”陷阱——它们不报错，但会让依赖解析结果与真实运行环境持续错位。
