换镜像不能解决“resolving dependencies”卡顿，因其是本地cpu内存密集型sat求解过程，与网络无关；真正瓶颈在于宽松版本约束、xdebug启用、php内存不足、platform配置错配或composer.lock残留旧引用。
换镜像能解决“Loading composer repositories”卡顿，但对“Resolving dependencies”无效——后者是本地计算瓶颈，不是网络问题。
为什么换镜像后 update 还卡在 Resolving dependencies？
镜像只加速远程元数据拉取和 ZIP 包下载，不参与依赖图求解。这个阶段纯 CPU + 内存运算，和镜像无关。
- Composer 会遍历所有包的版本约束，尝试找出满足全部条件的组合，复杂项目可能耗时数十秒甚至分钟
- Xdebug 启用时会让这一步慢 5–10 倍，务必关掉：
php -d xdebug.mode=off $(which composer) update - PHP 内存不足（默认
COMPOSER_MEMORY_LIMIT=128M）会导致反复 GC，加COMPOSER_MEMORY_LIMIT=-1临时放开 - platform 配置（如
"php": "7.4"）与当前 PHP 版本（如 8.2）不匹配，会触发降级回溯逻辑，大幅拖慢求解
镜像配置必须满足三个硬性条件才生效
写错任意一项，Composer 就静默 fallback 到 https://packagist.org，且不报错。
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 键名必须是
repo.packagist（单数，不是repos.packagist或repositories.packagist） - 命令末尾必须显式指定
composer类型：composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ - URL 必须 HTTPS 且以
/结尾：https://mirrors.aliyun.com/composer/✅，https://mirrors.aliyun.com/composer❌（拼成/composerpackages.json导致 404）
换源后仍看不到新版本？元数据缓存没刷新
Composer 默认复用本地 packages.json 缓存（15 分钟内不过期），哪怕镜像站已同步新包，它也不去拉。
- 验证是否真走镜像：
composer config -g repo.packagist输出必须是你配的 URL，且composer install -vvv日志里出现https---mirrors-aliyun-com-composer - 强制刷新元数据（≥ Composer 2.5）：
composer update --refresh—— 它只删packages.json和provider-*.json，保留 ZIP 包，快且安全 - 老版本（≤ 2.4）只能手动删缓存：
rm -rf $(composer config --global cache-dir)/repo/https---mirrors-aliyun-com-composer -
composer clear-cache不解决这个问题，它清的是 ZIP 和 VCS 缓存，packages.json会立刻重建并复用旧内容
项目级配置比全局更可靠，但容易被覆盖
宝塔、CI 或多用户环境下，composer config -g 可能写到 root 用户配置，而实际执行的是 www 用户，根本读不到。
- 进项目根目录，运行：
composer config repo.packagist composer https://mirrors.aliyun.com/composer/（不加-g） - 该命令会向
composer.json的repositories字段追加"packagist"条目，不覆盖已有私有源 - 但只要
composer.json里存在"repositories"字段（哪怕是空对象{}），全局镜像就会被完全屏蔽 - 验证是否被劫持：
composer config --list | grep repositories.packagist.url，为空说明项目级配置已生效且覆盖了全局
真正卡点往往藏在 composer.lock 里残留的旧 dist URL 或 platform 不匹配上，而不是镜像本身。先看 -vvv 日志里请求的是哪个域名，再决定动哪一层。
