Composer镜像配置错误导致插件钩子卡死，主因是全局配置失败后静默回退至packagist.org引发超时重试，或旧插件（如fxp/composer-asset-plugin）绕过镜像机制；需严格校验composer config -g repo.packagist输出为含type和正确URL的JSON，移除废弃插件，并删vendor与composer.lock后重装。
composer config -g repo.packagist 配错导致插件钩子卡死
插件钩子（如 pre-install-cmd、post-autoload-dump）本身不依赖镜像，但若全局镜像配置失败，composer install 会在解析阶段 fallback 到 packagist.org，触发大量超时重试——这些重试会阻塞整个流程，让钩子迟迟无法执行。
常见错误包括：
-
repo.packagist写成repos.packagist（多一个s） - URL 缺末尾
/，例如https://mirrors.aliyun.com/composer❌ → 实际请求变成https://mirrors.aliyun.com/composerpackages.json，返回 404 后静默回退 - 漏掉
type值，命令写成composer config -g repo.packagist https://mirrors.aliyun.com/composer/，缺少中间的composer
任一出错，composer config -g repo.packagist 输出为空或 {"type":"composer","url":"https://packagist.org"}，说明已静默回退，钩子实际运行前就卡在元数据加载上。
fxp/composer-asset-plugin 这类旧插件与镜像完全不兼容
该插件早已废弃，它绕过 Composer 原生镜像机制，直接请求 Bower/NPM 官方源（无国内镜像），且自身不支持 HTTP/2 和并发下载。一旦启用，composer install 会先跑完原生包安装，再单独拉前端资源——此时镜像配置对这部分完全无效。
典型现象是：前半段快，后半段卡死在 Downloading bower-asset/jquery。
解决方案不是调镜像，而是移除插件：
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
composer global remove fxp/composer-asset-plugin- 改用
npm-asset-packagist.org或迁移到yarn/npm
项目级配置必须删 vendor 和 composer.lock 才生效
项目级镜像配置（composer config repo.packagist composer https://mirrors.aliyun.com/composer/）写入 composer.json 的 repositories 字段，但不会自动刷新已有产物。
composer.lock 里记录的是旧源下的 dist URL，不删它，composer install 仍按旧地址下载，根本不会走新镜像。
必须执行：
- 删除
vendor/目录 - 删除
composer.lock - 只运行
composer install（不是update），让 Composer 从头解析依赖、生成适配新镜像的 lock 文件
镜像不影响 vendor 目录结构，但影响是否重装
镜像本身不改 vendor/ 目录结构，但失效的缓存或错误源配置会让 Composer 退化为暴力重装——表现为每次 composer install 都删光 vendor 再重建。
关键判断点：
-
composer config -g cache-files-dir输出为空 → 缓存目录未设置，所有包下载后不落盘，下次 install 就得重来 - 项目
composer.json里有"repositories": {}（哪怕只是空对象）→ 全局镜像被屏蔽，实际走packagist.org，缓存命中率归零 -
platform.php在全局 config 和项目lock中不一致（比如 lock 记的是"8.1"，而你本地 PHP 是8.2）→ Composer 认为环境不兼容，强制丢弃vendor重建
真正让 vendor “稳定下来”的，是镜像、缓存、平台声明三者对齐，而不是单纯换源。
