直接结论：不是换镜像，而是强制刷新元数据缓存，并确认当前生效源是否被项目配置覆盖；项目级repositories会完全屏蔽全局镜像，需用composer config --list | grep repositories.packagist.url验证实际地址，再执行composer update --refresh（≥2.5）强制重载最新packages.json。
直接结论：不是换镜像，而是强制刷新元数据缓存，并确认当前生效源是否被项目配置覆盖。
怎么确认当前真正生效的镜像源
很多人以为改了全局配置就生效了，结果 composer update 还是拉不到新版本，根本原因是项目级 composer.json 里的 repositories 字段会**完全屏蔽**全局设置。
- 运行
composer config --list | grep repositories.packagist.url，输出才是 Composer 实际请求的地址；如果为空，说明没配上或被覆盖 - 打开项目根目录的
composer.json，搜索"repositories"—— 若存在且 URL 是过期的（比如https://packagist.phpcomposer.com），就会静默 fallback 到官方源 - 临时验证：执行
composer config --unset repositories（不加-g），再试composer update，看是否恢复正常
为什么 composer update 显示 “Nothing to install or update” 却有新版本
这不是网络问题，是 Composer 默认复用本地缓存的 packages.json，15 分钟内不过期。哪怕镜像站已同步 monolog/monolog v3.6.0，你本地仍按旧元数据算，压根不发请求。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 现象：Packagist 页面和镜像站页面都显示新版存在，但命令行无反应
- 验证方式：运行
curl -I https://mirrors.aliyun.com/composer/packages.json，看Last-Modified时间是否比你上次更新早 -
composer clear-cache没用——它删 ZIP 包和部分 JSON，但下次update会立刻重建并复用旧packages.json
强制刷新元数据缓存的正确操作
composer update --refresh（Composer ≥ 2.5）是专为解决元数据延迟设计的操作：它只丢弃缓存的 packages.json 和 provider-*.json，从当前生效镜像源重新下载最新元数据，不碰已下载的包，快且精准。
- 先确认版本：
composer --version，低于 2.5 的需手动删缓存子目录：rm -rf $(composer config --global cache-dir)/repo/https---mirrors-aliyun-com-composer - 确保镜像已正确配置：
composer config -g repo.packagist.url应输出类似https://mirrors.aliyun.com/composer/ - 执行后立刻再跑
composer update vendor/package-name，新版本就能被识别出来 - 调试时可加
--no-cache -v，终端会打印真实请求 URL，确认是否命中你配的镜像
CI/CD 中避免构建漂移的关键写法
GitHub Actions、GitLab CI 等环境默认不继承本地配置，每次都是干净环境。只写 composer install 就等于裸奔，极易因元数据不一致导致 vendor 目录结构相同但行为异常。
- 必须显式指定源：
composer install --repository=https://mirrors.aliyun.com/composer/ --no-cache - 禁用 fallback：在
composer.json根节点加"packagist.org": false，防止意外回退到官方源 - 不要依赖
composer update --dry-run验证镜像——它不触发元数据刷新，只比对 lock 文件
最常被忽略的是项目级 repositories 配置的覆盖效应，以及 --refresh 和 clear-cache 的本质区别：前者刷新元数据，后者清下载物——搞错这点，所有重试都只是在原地打转。
