Composer update看不到新版本是因为默认复用15分钟内未过期的本地packages.json缓存，导致不发起远程请求；解决方法是≥2.5版本执行composer update --refresh强制刷新元数据，≤2.4版本需手动删除对应镜像的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 clear-cache不够用：它只清 ZIP 包和部分 JSON，不删packages.json和provider-*.json - 老版本（≤ 2.4）必须手动删缓存子目录：
rm -rf $(composer config --global cache-dir)/repo/https---mirrors-aliyun-com-composer - 路径由镜像 URL 转义生成，删错目录（比如删了
https---packagist.org却配着阿里云）等于白忙活
composer update --refresh 为什么只对 ≥2.5 有效？
composer update --refresh 是 Composer ≥ 2.5 引入的专用机制，它精准丢弃所有缓存的元数据文件（packages.json、provider-*.json），强制从当前生效镜像源重拉最新索引，但保留已下载的 ZIP 包缓存。
老版本不支持该参数，强行使用会报错或静默忽略；此时只能靠手动删缓存目录或临时加 --no-cache 触发单次重载。
将一个或多个视频上传至YouTube。当用户想“上传到YouTube”“发YouTube”“批量上传”“upload to YouTube”“post videos to YouTube”或发布到YouTube时使用此技能。
- 执行前务必确认
composer config -g repo.packagist输出是你配的镜像地址（如https://mirrors.aliyun.com/composer/） - 若项目级
composer.json含"repositories"字段，会完全屏蔽全局配置，此时需查composer config repo.packagist（不加-g） - 加
--no-cache -v可看到终端输出的真实请求 URL，确认是否命中你配的镜像域名
项目级 repositories 配置如何静默覆盖全局镜像？
只要项目根目录 composer.json 里存在 "repositories" 字段（哪怕内容是空数组 [] 或 {"packagist.org": false}），Composer 就会彻底忽略全局 repo.packagist 设置，且不报错、不提示。
常见陷阱包括："url": "https://packagist.phpcomposer.com"（该地址已 404）、漏写 "type": "composer"、URL 少末尾斜杠导致拼成 /composerpackages.json 直接 404。
- 检查方式：
composer config --list | grep repositories.packagist.url，输出为空或不是你预期的地址，基本就是被项目级覆盖了 - 临时验证：
composer config --unset repositories（不加-g），再跑composer update - 若需保留私有源，别覆盖整个
repositories数组，改用composer config repo.packagist composer https://mirrors.aliyun.com/composer/追加
为什么不能靠多个镜像地址“自动 fallback”？
在 composer.json 的 repositories 数组里堆多个镜像地址，只会让事情更糟：Composer 按顺序逐个尝试，卡在第一个慢源上等满 http.timeout（默认 30 秒），第二个根本没机会响应。
不同镜像同步延迟不一致（阿里云 5 分钟 vs 中科大 12 分钟），同一 composer update 在华东和华北机器上可能解析出完全不同的可用版本。即使第一个源返回 502，Composer 也不会自动切到第二个——它没有失败重试逻辑，只当该源不可用，继续往下找，但不会并发或轮询。
- 跨区域多活唯一可行路径是基础设施抽象：用 Anycast IP 托管统一入口（如
repo.phpmirror.net），靠 BGP 自动调度流量 - 别碰
repositories数组里的“伪多活”，它解决不了同步延迟，反而放大不确定性 - 新包发布后最可靠的动作不是等同步，而是用
composer show vendor/package --no-cache快速验证镜像是否已就绪
