composer update 看不到新版本主因是本地元数据缓存未刷新，15分钟内复用旧packages.json；需用composer update --refresh（≥2.5）或手动清理repo缓存，同时检查项目级repositories配置是否覆盖全局镜像。
composer update 看不到新版本？先查元数据缓存是否过期
Composer 默认复用本地 packages.json 缓存，15 分钟内不重新请求镜像站——哪怕阿里云镜像已同步了 monolog/monolog v3.6.0，你执行 composer update monolog/monolog 仍会显示 Nothing to install or update。
这不是镜像没更新，而是 Composer 没发请求。验证方式很简单：curl -I https://mirrors.aliyun.com/composer/packages.json 返回 200，且响应头含 Last-Modified 时间比你本地缓存文件新，就说明问题出在本地。
-
composer update --refresh（仅 ≥2.5 支持）会清空所有 provider 缓存，但保留 ZIP 包缓存，只重拉元数据 - 老版本（≤2.4）必须手动删缓存目录：
rm -rf $(composer config --global cache-dir)/repo/https---mirrors-aliyun-com-composer -
composer clear-cache不够用：它清的是 ZIP 包，不碰packages.json和provider-*.json，下次 update 仍读旧索引
项目级 repositories 配置会彻底屏蔽全局镜像
很多人配了 composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/，却依然走官方源，原因几乎全是项目根目录 composer.json 里写了 "repositories" 字段——它会完全覆盖全局设置，且不报错、不提示。
常见陷阱包括："repositories": [{"type": "composer", "url": "https://packagist.phpcomposer.com"}]（该地址已 404），或漏写 type、URL 少末尾 /，导致请求拼成 /composerpackages.json 直接 404 后静默 fallback 到官方源。
- 查实际生效配置：
composer config --list | grep repositories.packagist.url，确认输出是你预期的镜像地址 - 检查
composer.json是否含"repositories"；若有，删掉或改成有效地址（如"https://mirrors.aliyun.com/composer/"） - 注意键名是
repo.packagist（单数），不是repos.packagist（多一个 s 就失效）
强制刷新元数据的三种实操路径
没有“刷新镜像源”的命令，只有让 Composer 重拉元数据的组合操作。关键在于跳过本地缓存校验，且确保请求命中真实镜像地址。
- 最推荐：
composer update --refresh -v（≥2.5），加-v可看到日志中实际请求的 URL，确认是否为https://mirrors.aliyun.com/composer/... - 临时绕过缓存：
composer require vendor/package --no-cache -v，适用于调试单个包，会触发对应p2/vendor/package.json重载 - 彻底重走流程：
rm composer.lock && composer install --no-cache，仅限开发环境，适合 lock 文件陈旧、依赖解析卡死时
别用 --repository 临时切源却不加 -v：看不到真实请求地址，容易误判是否生效。
镜像选型与同步延迟的真实边界
阿里云、腾讯云、中科大镜像同步频率都在 5–15 分钟，但策略不同：阿里云强制校验 packages.json 签名，签名失效直接返回 404；腾讯云跳过签名验证，但部分新包首波同步可能失败；中科大镜像教育网友好，北方地区延迟更低。
所谓“同步慢”，90% 是本地缓存或配置覆盖导致的假象。真遇到超 30 分钟未同步，可临时回退官方源，但不能裸连：
- 临时切源：
composer config --no-plugins repo.packagist composer https://packagist.org - 若报
curl error 60，说明证书链问题，临时禁用校验：composer config -g secure-http false（用完立刻恢复） - 更稳妥方式：
composer require vendor/package --prefer-source --no-cache，直接从 Git 拉（前提是包支持）
真正难处理的不是延迟本身，而是缓存策略和配置层级的隐式覆盖——它们不会报错，只会让你反复怀疑镜像是不是又挂了。
