答案是 composer update --refresh（≥2.5）能解决镜像元数据延迟问题，它强制丢弃本地 packages.json 并从镜像源重拉最新元数据，不清理 zip 缓存，精准高效；老版本需手动删除对应 repo 子目录。
Composer 中文镜像本身不会导致死锁，真正引发“解析卡住”或“root requirements could not be resolved”的，是镜像元数据延迟 + 本地缓存复用 + 项目约束冲突三者叠加的结果。单独换镜像源解决不了问题，必须拆解这三层。
为什么换阿里云/腾讯云镜像后反而 update 卡 CPU 或报 cycle detected
中文镜像（如 https://mirrors.aliyun.com/composer/）同步有 15–30 分钟延迟，但 Composer 默认复用本地 cache/repo/https---mirrors-aliyun-com-composer/packages.json，不校验远程是否更新。当你执行 composer update 时，求解器基于过期元数据构建依赖图——如果新版本已修复循环引用，旧元数据里仍保留着那个坏路径，就会触发无限回溯或直接报错。
- 现象：终端无输出、
top显示 PHP 进程占满 CPU、内存持续上涨 - 验证方式：运行
curl -I https://mirrors.aliyun.com/composer/packages.json，对比Last-Modified时间与你上次update时间 - 别信
composer clear-cache—— 它清 ZIP 包缓存，但packages.json仍在原地，下次 update 照样复用
强制刷新镜像元数据的正确命令（不是 clear-cache）
composer update --refresh（≥ Composer 2.5）才是专为元数据延迟设计的操作：它只删掉 cache/repo/ 下所有 packages.json 和 provider-*.json，然后从当前配置的镜像源重新拉取最新元数据，不碰 ZIP 缓存、不重装包。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 执行前先确认镜像生效：
composer config --list | grep repositories.packagist.url，确保没被项目级"repositories"覆盖 - 若用的是老版本 Composer（rm -rf $(composer config --global cache-dir)/repo/https---mirrors-aliyun-com-composer
- 刷新后立刻跑
composer update --dry-run -v，看报错是否消失或变更——这才是元数据生效的证据
镜像源配置被项目级 composer.json 静默覆盖
项目根目录下的 composer.json 若含 "repositories" 字段，会完全屏蔽全局镜像设置。很多人复制模板时留着已停更的 https://packagist.phpcomposer.com，结果 composer install 静默 fallback 到官方源，而别人走的是阿里云镜像——同一份 composer.lock 在不同机器上装出不同行为。
- 查全局镜像：
composer config -g repo.packagist，输出应为完整 URL（如https://mirrors.aliyun.com/composer/） - 查实际生效配置：
composer config --list | grep repositories.packagist.url - 检查项目
composer.json是否含"repositories"；若有，删掉或改成有效镜像地址（如{"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}） - 验证连通性：
curl -I https://mirrors.aliyun.com/composer/packages.json必须返回 HTTP 200
元数据刷新后仍报 root requirements could not be resolved
这时问题已不在镜像，而是约束本身矛盾：比如 laravel/framework ^10.0 和 spatie/laravel-backup ^8.0 同时 require 互斥的 symfony/console 版本范围。Composer 不会猜测或降级，它只报错退出。
- 运行
composer why-not laravel/framework:10.0，看最后一行那个无法松动的叶子包（常是psr/log或phpunit/phpunit） - 用
composer prohibits monolog/monolog:^3.0直接列出所有拦路包，比why-not更聚焦 - 检查
composer.json里的"conflict"字段：写成"conflict": {"php": "8.3.*"}会拦住整个分支，应删掉或写具体小版本 - 临时绕过：
composer update --no-dev可排除require-dev干扰，快速验证是否 dev 依赖拖了后腿
最易被忽略的点：你以为在调镜像，其实 Composer 正在用你本地缓存的旧元数据算一个根本不存在的依赖图；你以为删了 lock 就能重来，其实只是把问题推迟到 CI 或线上环境爆发。元数据刷新和约束排查，缺一不可。
