临时文件干扰镜像同步：composer.lock含原始dist.url，vendor/触发增量安装跳过元数据刷新，cache/repo/下旧元数据快照（如aliyun子目录）不更新；需删vendor、composer.lock，清cache/repo/对应镜像子目录，并用--no-cache重装。
composer install 卡住或报错时，临时文件（vendor/、composer.lock、缓存目录下的 repo/ 子目录）不是“旁观者”，而是同步行为的决定性参与者。镜像源本身不改写包下载地址，只代理元数据；真正影响是否能拉到包、拉到哪个版本、甚至是否走镜像的，是这些文件的状态。
临时文件怎么干扰镜像源同步？
镜像配置再正确，只要本地有残留的旧状态，Composer 就可能绕过镜像、复用错误元数据、或拼出非法 URL：
-
composer.lock里记录的是上次composer update或install时所用源的dist.url和哈希值。如果它来自官方源（如"dist": {"url": "https://api.github.com/..."}），即使你已切到阿里云镜像，composer install仍会直连 GitHub —— 镜像不重写 dist 地址，只管packages.json和provider-*.json -
vendor/目录存在会触发 Composer 的“增量安装”逻辑，跳过部分元数据刷新，导致依赖解析基于过期索引 -
~/.composer/cache/repo/https---mirrors-aliyun-com-composer/这类目录里存的是packages.json、provider-*.json等元数据快照，默认 15 分钟内不主动更新。哪怕镜像站已同步新包，本地仍按旧快照算依赖
为什么 composer clear-cache 常常没用？
composer clear-cache 只删 ZIP 包、dist 文件和部分 provider 缓存，对决定“有没有这个包”的核心元数据（packages.json）完全无效。它不碰 ~/.composer/cache/repo/ 下的镜像子目录。
- 查真实缓存路径：
composer config --global cache-dir - 定位镜像元数据目录：
ls -d $(composer config --global cache-dir)/repo/https---mirrors-aliyun-com-composer - 手动清理（必须）：
rm -rf ~/.composer/cache/repo/https---mirrors-aliyun-com-composer（Windows 对应%APPDATA%\Composer\cache\repo\https---mirrors-aliyun-com-composer） - 清理后验证：
composer show monolog/monolog—— 此时才会强制发起新请求，终端第一行Downloading https://mirrors.aliyun.com/composer/...才算真正走镜像
切换镜像前必须做的三件事
临时文件不是可选清理项，而是同步生效的前提条件。漏掉任一，就等于没切镜像：
- 删掉整个
vendor/：rm -rf vendor/—— 防止 Composer 复用旧 autoload 或跳过元数据加载 - 删掉
composer.lock：rm composer.lock—— 强制重新解析依赖树并生成新 lock，确保所有dist.url来自当前镜像源（实际仍是原始地址，但元数据来源一致） - 加
--no-cache参数运行：composer install --no-cache -v—— 避免命令级缓存干扰，-v可直接看到第一行请求 URL 是否为镜像地址
镜像同步机制的本质：元数据代理，非下载代理
理解这点才能避免“配了镜像却还慢/失败”的困惑。Composer 镜像只做两件事：
- 响应
/packages.json、/p/vendor/package.json、/provider-*.json这类元数据请求（JSON 格式，轻量） - 把
dist.url字段原样返回给 Composer 客户端（即仍指向 GitHub、GitLab 等原始地址）
所以网络卡在 “Loading composer repositories” 是元数据层问题（DNS/TLS/缓存），而卡在 “Downloading xxx.zip” 是 dist 层问题（GitHub 访问限制、CDN 路由、本地网络策略）——后者镜像完全不参与。很多团队误以为换镜像就能解决所有下载慢，其实是混淆了这两层。
