composer clear-cache 清完仍走 packagist.org，是因为它默认只清 files/（ZIP包）缓存，不清理 repo/ 下的元数据（如 packages.json），而镜像生效依赖元数据是否从镜像站拉取；必须手动删 repo/ 对应目录或用 --all 才能彻底清除元数据缓存。
composer clear-cache 为什么清完还是走 packagist.org
不是缓存没清掉，是 Composer 2.x 的元数据缓存（packages.json）和 ZIP 包缓存分属两层，clear-cache 默认只清 ZIP 缓存，不碰元数据——而镜像是否生效，恰恰取决于元数据是否从镜像站拉取。
必须显式清理元数据缓存：
-
composer clear-cache→ 清下载包缓存（.composer/cache/files/） -
composer clear-cache --all或rm -rf ~/.composer/cache/repo/→ 才能删掉packages.json等元数据 - 验证是否清干净：执行
ls ~/.composer/cache/repo/https---packagist.org/，若目录还存在，说明元数据缓存残留
更稳妥的做法是清完后立刻跑一次 composer show monolog/monolog -vvv 2>&1 | grep "Downloading"，看 URL 是 mirrors.aliyun.com 还是 packagist.org。
镜像配置写对了，但 install 仍卡在 Loading composer repositories
这基本等于“请求根本没发到镜像站”，90% 是以下三个条件漏一：
-
-g参数缺失 → 命令变成项目级配置，只改当前目录的composer.json，换目录就失效 - 键名写成
repos.packagist（多一个s）或packagist.org→ Composer 2.x 完全忽略，静默 fallback 到官方源 - URL 少末尾
/→https://mirrors.aliyun.com/composer❌ 会拼出/composerpackages.json路径，直接 404
验证是否真写入成功，只看这一行输出：composer config -g repo.packagist。正确返回必须是 {"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}；返回空、null、或仍是 https://packagist.org，说明没写对。
项目级配置如何安全合并私有仓库而不覆盖
全局配置在 CI、Docker、宝塔等场景下不可靠，项目级才是协作刚需。但手动编辑 composer.json 极易破坏 JSON 格式或误删已有源。
安全做法是用命令自动合并：
- 进项目根目录，执行
composer config repo.packagist composer https://mirrors.aliyun.com/composer/（注意不加-g） - 如果原
composer.json中"repositories"是空对象{}，命令会转为标准数组并插入packagist条目 - 如果已是数组（如含私有包源），命令会在末尾追加新项，不覆盖原有内容
- 切勿手动写
"packagist": false—— 这会导致php、ext-json等基础平台约束校验失败
改完必须删掉 vendor/ 和 composer.lock，再跑 composer install（不是 update），否则旧 lock 文件仍记录官方源地址。
缓存与镜像配合提速的关键盲区
镜像只加速元数据拉取和 ZIP 下载，不参与依赖解析；缓存也分两层，很多人只清 ZIP 缓存却忽略了元数据缓存。
-
--no-dev可省 30–60% 时间，生产环境必加 -
--optimize-autoloader必开（生成autoload_classmap.php），但--classmap-authoritative只适合部署或 CI 构建，开发环境禁用 - CI 中要显式缓存
~/.composer/cache目录，并用${{ hashFiles('**/composer.lock') }}当 cache key，否则跨版本污染 - 私有 Git 仓库混用 SSH 和 HTTPS 地址，Composer 视为两个仓库，缓存不互通
最常被忽略的是：缓存目录若挂到 NFS 或 Docker volume 上，I/O 性能暴跌，cache-dir 应指向 SSD 或本地高速磁盘。
