小众包慢的本质是镜像策略性同步+Composer fallback机制+配置细节叠加所致；国内镜像非全量实时同步，低热度包延迟可达数小时甚至跳过，且项目级repositories空配置会覆盖全局镜像，导致依赖链中任一子包缺失即触发串行fallback至官方源。
镜像源根本没同步那个包
国内镜像（如阿里云、腾讯云）不是实时全量同步 packagist.org 的，而是按热度、更新频率、包体积做策略性同步。小众项目可能几天甚至一周才拉一次元数据，composer update 时会 fallback 到官方源去查——你看到的“慢”，其实是本地在等 packagist.org 的 TLS 握手和首字节响应。
验证方式：composer show vendor/package-name -vvv 2>&1 | grep "GET "，如果出现 https://packagist.org/ 域名，说明镜像未覆盖该包。
- 阿里云镜像同步延迟通常为 5–30 分钟，但低活跃度包可能长达数小时甚至跳过
- 腾讯云镜像对 abandoned 包、dev-only 包、无 star 的私有命名空间包基本不抓取
- 别信“镜像已启用”就万事大吉，小众包必须单独验证
项目级 repositories 覆盖了全局镜像
只要你的 composer.json 里写了 "repositories": []（哪怕空数组），Composer 就会忽略全局 repo.packagist 配置，直接走默认源。很多脚手架或旧模板自带空 repositories 字段，你根本没注意。
检查命令：grep -A5 "repositories" composer.json；修复方法：删掉整个 "repositories" 块，或用命令精准追加：composer config repo.packagist composer https://mirrors.aliyun.com/composer/（不加 -g）。
- 项目级配置优先级高于全局，这是 Composer 的硬规则，不是 bug
- CI/CD 环境中常因缓存了旧
composer.json导致行为不一致 - 某些 IDE 自动生成的
composer.json默认带空repositories
小众包依赖链触发 fallback 校验
即使主包在镜像里，它依赖的某个小众子包不在，Composer 就会逐层 fallback 到 packagist.org 查找——而这个过程是串行阻塞的，一个包卡住，整条链停摆。
典型现象：Resolving dependencies 阶段突然变慢，-vvv 日志里反复出现 GET https://packagist.org/p/xxx/ 请求。
- 用
composer depends vendor/package-name查清依赖树，定位哪一层引入了小众包 - 临时替换为
path类型仓库（适合调试）：composer config repositories.foo path ../local-fork - 加
--no-cache强制绕过本地元数据缓存，避免残留的错误 fallback 记录
镜像 URL 配置缺 type 或末尾 /
小众包元数据请求路径拼接更敏感。比如镜像 URL 写成 https://mirrors.aliyun.com/composer（缺末尾斜杠），Composer 会拼出 https://mirrors.aliyun.com/composerp/vendor/package.json 这种 404 地址，然后自动降级到官方源重试。
正确写法只有两种：composer config -g repos.packagist.type composer + composer config -g repos.packagist.url https://mirrors.aliyun.com/composer/；或者一行命令：composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/（注意是 repo.packagist，不是 repos.packagist）。
- Composer 2.9.6 仍支持
repo.packagist单键写法，但必须带composertype 参数 -
repos.packagist（带 s）是旧写法，2.x 已废弃，设了也无效 - URL 缺
/导致的 404 不报错，只静默 fallback，极难察觉
