详解Composer国内镜像的元数据缓存策略-composer-PHP中文网

composer元数据缓存策略硬编码为15分钟且不可配置，所谓“刷新频率”是误解；唯一可控操作是手动执行composer update --refresh（≥2.5），强制重拉packages.json和provider-*.json，不重下zip包。

详解composer国内镜像的元数据缓存策略

Composer元数据缓存根本不能“调频率”

Composer 客户端没有 --refresh-interval、cache-ttl（元数据）这类配置项，所谓“刷新频率”是常见误解。它的元数据缓存策略硬编码为 15 分钟，且不可通过 config 或环境变量修改。你看到的“等几分钟就更新了”，其实是镜像站服务端同步完成 + Composer 恰好过了本地 15 分钟缓存窗口的叠加结果，不是你在控制节奏。

真正可控的只有手动触发：composer update --refresh（≥2.5 版本），它会清空当前镜像对应的 repo/https---mirrors.aliyun.com-composer/ 下所有 provider 缓存，强制重拉 packages.json 和 provider-*.json，但不重新下载 ZIP 包。

这个动作只影响元数据，不影响 files/ 下的包文件缓存
执行后仍可能因镜像站未同步而拉到旧数据——得看阿里云、清华源等实际同步延迟，不是 Composer 的锅
CI 环境里频繁用 --refresh 反而增加失败率，不如固定用 --no-cache -v 看真实请求是否命中镜像

换镜像后元数据缓存还在用旧地址？清错地方了

运行 composer clear-cache 只删 ~/.composer/cache/files/ 和默认源 https---packagist.org/ 下的元数据，但你配的是阿里云镜像，缓存实际存在 https---mirrors.aliyun.com-composer/ 这类路径里。不手动清理，Composer 就一直读旧缓存，哪怕 composer config -g repo.packagist 已显示新 URL。

正确做法是先确认当前镜像路径：

composer config -g repo.packagist

再转义 URL（去掉 :、/、.，替换为 -），定位并删除对应目录：

阿里云：rm -rf ~/.composer/cache/repo/https---mirrors.aliyun.com-composer
清华源：rm -rf ~/.composer/cache/repo/https---mirrors.tuna.tsinghua.edu.cn-composer
删完立刻跑 composer install -vvv，观察日志里是否出现新镜像域名和 200 OK

元数据缓存乱码？别怪镜像，查本地环境

composer show 显示中文包名变 ??? 或 \uXXXX，不是镜像返回了乱码 JSON——所有中文镜像返回的 packages.json 都是标准 UTF-8 无 BOM。问题出在本地 PHP 解析时用了错误编码读取缓存文件。

Discussion Composer

围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par

下载

典型场景：

Windows CMD 未执行 chcp 65001，PHP 用系统默认 GBK 解 UTF-8 缓存 → 字节错位
Git Bash 中 $LANG 为空或为 C，file_get_contents() 返回原始字节，但后续 json_decode() 未校验编码
PHP

验证方法：用 xxd 查缓存文件头，7b22... 是纯 UTF-8；efbbbf 才是 BOM 污染。直接用 PHP 解析：

php -r "var_dump(json_decode(file_get_contents('~/.composer/cache/repo/https---mirrors.aliyun.com-composer/packages.json'), true));"

报 Syntax error 才真有问题，否则就是终端或 PHP 运行时编码不一致。

为什么 `composer update` 有时快有时慢，跟镜像关系不大

换镜像后 update 报错变快，不是因为“同步更快”，而是 SAT 依赖解析器更快穷尽了所有冲突路径。镜像只负责提供元数据（packages.json），不参与版本约束求解。如果你看到 Your requirements could not be resolved，根源永远在 composer.json 里的 require、conflict 或隐含的平台约束（如 PHP 版本、扩展）。

排查优先级应是：