卡在“Reading composer.json”说明Composer正读取损坏或过期的本地缓存，而非联网；常见原因包括缓存权限异常、文件截断/含BOM头、provider-*.json损坏、老版本Composer拼接URL缺尾斜杠致404 fallback。
不是网络慢，也不是镜像没换——卡在 “Reading composer.json” 说明 Composer 正在读本地缓存，但这个缓存本身已损坏或过期，它根本没打算联网。
为什么“Reading composer.json”会卡住？
Composer 在执行 composer update 时，若看到日志里反复出现 Reading composer.json from cache 却无后续，大概率是以下情况之一：
- 缓存目录权限异常（比如 root 写入、www-data 读取失败）
-
packages.json文件被截断或含非法字符（常见于镜像源返回 HTML 错误页或 BOM 头） - 缓存路径下存在空文件或损坏的
provider-*.json，导致解析器 hang 住 - 你正在用老版本 Composer（≤2.4），而镜像 URL 缺末尾
/，拼出/composerpackages.json→ 404 → fallback 到空响应
如何快速定位是哪个镜像源在作祟？
别猜，直接查实际生效的配置和请求日志：
Wjs Uploading Video
下载
将一个或多个视频上传至YouTube。当用户想“上传到YouTube”“发YouTube”“批量上传”“upload to YouTube”“post videos to YouTube”或发布到YouTube时使用此技能。
- 运行
composer config -g repo.packagist—— 输出应为完整 JSON 或至少是带https://的字符串；若为空、null或https://packagist.org，说明全局镜像未生效 - 进项目目录后运行
composer config repos.packagist.url—— 若有输出，说明项目级配置优先，全局被覆盖 - 执行
composer update --no-plugins -vvv | grep "Reading.*cache\|Downloading"，观察最后几行是否命中你设的镜像域名（如mirrors.aliyun.com）；若出现packagist.org，就是 fallback 了
手动验证镜像源返回是否正常
绕过 Composer，用 curl 直接测关键元数据文件：
- 先拿到你当前镜像地址：比如
https://mirrors.aliyun.com/composer/ - 执行：
curl -s -f -H "User-Agent: Composer/2.9.6" https://mirrors.aliyun.com/composer/packages.json | head -n 1
—— 正常应输出{开头的 JSON；若返回 HTML、乱码或空，说明镜像源已损坏 - 加
-w "%{time_starttransfer}\n"测 TTFB：curl -s -o /dev/null -f -H "User-Agent: Composer/2.9.6" -w "%{time_starttransfer}\n" https://mirrors.aliyun.com/composer/packages.json—— 超过 2s 就属于拖慢流程的延迟
清缓存不能只靠 composer clear-cache
这个命令不删 repo/ 下的元数据缓存，所以“Reading composer.json”依然读旧文件：
- 查缓存路径：
composer config --global cache-dir（通常是~/.composer/cache） - 进
repo/子目录，找对应镜像的文件夹（如https---mirrors-aliyun-com-composer） - 直接删整个文件夹：
rm -rf $(composer config --global cache-dir)/repo/https---mirrors-aliyun-com-composer - 或者更暴力但可靠：
rm -rf $(composer config --global cache-dir)/repo（Composer 会自动重建）
注意：清完缓存后，第一次 composer update 必须看到 Downloading packages.json 才算真正从镜像拉新数据；如果还显示 Reading ... from cache，说明没清干净或路径不对。
