根本原因是镜像配置路径错误、参数缺失或缓存未刷新：composer 以非 root 用户（如 www）运行，但 sudo 配置写入了 /root/.composer；应确认实际用户配置路径、使用项目级数组配置、删除对应 repo/ 子目录缓存，并验证镜像源文件是否存在。
轻量应用服务器（如腾讯云Lighthouse、阿里云SAE轻量版）上 Composer 镜像源“配了但没生效”，根本原因不是网络不通，而是配置写进了错的用户路径、漏了硬性参数、或缓存没刷新到元数据层——这些机器通常以非 root 用户（如 www、lighthouse、app）运行 PHP 和 Composer，而你用 sudo 配的全局镜像却落在 root 的 ~/.composer/config.json 里，PHP 进程压根读不到。
确认当前用户和 Composer 实际读取的配置路径
轻量服务器默认不给你 root 权限，whoami 和 ps aux | grep php 能暴露真相：
- 运行
composer config --global config-dir，输出的路径才是 Composer 当前认为的“全局配置位置” - 如果输出是
/root/.composer，但你的 Web 服务跑在www用户下，那全局配置完全无效 - 更直接的方式：
sudo -u www composer config -g repo.packagist（把www换成你实际的运行用户），看是否返回空或官方源 - 别信
composer diagnose的 “Repo: https://packagist.org” —— 它只查自己启动时的上下文，不反映 Web 请求真实行为
项目级配置比全局更可靠，且必须用数组格式
轻量服务器常跑单项目（如 Laravel API 或 Slim 微服务），项目级配置可提交 Git、绕过用户权限问题，但 Composer 2.2+ 要求严格：
- 进项目根目录后执行：
composer config repo.packagist composer https://mirrors.aliyun.com/composer/（不加-g） - 这条命令会自动向
composer.json的repositories字段写入标准数组，形如：[{"packagist.org": false}, {"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}] - 手写 JSON 极易出错：漏掉
{"packagist.org": false}、把url写成https://mirrors.aliyun.com/composer（少/）、逗号多写或少写，都会导致静默 fallback 到官方源 - 改完立刻
git add composer.json && git commit -m "set aliyun mirror"，确保 CI 或其他同事拉代码即生效
删错缓存目录等于白干，关键文件在 repo/ 子目录下
composer clear-cache 只清 ZIP 包和部分临时 JSON，对决定“有没有这个包”的元数据文件（packages.json、provider-*.json）基本没动——它们藏在 ~/.composer/cache/repo/https---mirrors-aliyun-com-composer/ 这类转义路径里：
- 先查真实缓存位置：
composer config --global cache-dir - 再进
repo/子目录看镜像对应路径：ls -d $(composer config --global cache-dir)/repo/https---* - 如果当前用的是阿里云镜像，就删那个
https---mirrors-aliyun-com-composer目录；若删了https---packagist.org却配着腾讯云镜像，毫无意义 - Windows 或 WSL 用户注意路径分隔符差异，
%APPDATA%\Composer\cache\repo\https---mirrors-aliyun-com-composer才是正确目标
同步延迟时别等，换源比重试更有效
轻量服务器资源有限，composer update 卡在 provider-laravel~10.0.json 不是慢，是镜像站还没同步到这个文件——它采用“首次请求触发拉取”，不是全量实时同步：
- 验证镜像是否真有该文件：
curl -I https://mirrors.aliyun.com/composer/p2/laravel/framework/10.0.0.json，返回200才算有 - 若返回
404或302到官方源，立刻切中科大源：composer config -g repo.packagist composer https://mirrors.ustc.edu.cn/composer/ - 或者直接用
composer update --refresh（≥2.5）：它强制丢弃所有本地元数据缓存，从当前镜像重拉packages.json和全部provider-*.json，但保留已下载的 ZIP 包，最省带宽 - CI 流水线中建议加
--no-cache -v，终端日志会明确打出请求 URL，一眼确认是否命中镜像域名
真正卡住的从来不是镜像本身，而是你删了缓存却没删对目录、配了源却配给了错误用户、信了 diagnose 的假反馈——轻量服务器资源紧，每一步都要精准落到实际运行用户的配置和缓存路径上。
