composer clear-cache对第三方扩展包缓存无效，因其仅清理默认files/、repo/和vcs/目录，而私有源元数据（如packages.json）缓存在独立子目录（如https---my-private-repo.com/），需手动定位并删除对应repo子目录。
为什么 composer clear-cache 对第三方扩展包缓存无效
因为 composer clear-cache 只清理 ~/.composer/cache/files/、repo/ 和 vcs/，而很多第三方扩展包（如私有 Packagist、Satis、Private Packagist、GitLab Package Registry）的元数据会缓存在独立子目录里，比如 ~/.composer/cache/repo/https---my-private-repo.com/。这些路径不被 clear-cache 覆盖，但又直接影响 composer update 是否能拉到新版包。
- 执行
composer clear-cache后仍拉不到新版本？大概率是这类 repo 子目录残留了过期的packages.json或provider-*.json - 私有仓库 URL 中的特殊字符（如
:、/、.）会被转义为-，所以https://gitlab.example.com/api/v4/groups/my-group/-/packages/composer实际缓存在https---gitlab-example-com-api-v4-groups-my-group---packages-composer/ - 用
ls ~/.composer/cache/repo/能一眼看到所有活跃仓库缓存目录，其中带https-前缀的几乎全是第三方扩展源
如何精准定位并清理特定第三方源的 metadata 缓存
别盲目删整个 repo/——你可能顺手清掉 Packagist 的缓存，导致后续装开源包变慢。应该只动目标源：
- 先确认你要清理的源地址：查
composer config --list | grep repositories或直接看composer.json里的repositories数组 - 把源 URL 中的
://替换为---，/和.全部替换成-，再小写处理，就是缓存子目录名。例如https://packages.myorg.com→https---packages-myorg-com - 执行：
rm -rf ~/.composer/cache/repo/https---packages-myorg-com（Linux/macOS）或rd /s /q "%APPDATA%\Composer\Cache\repo\https---packages-myorg-com"（Windows） - 验证是否生效：运行
composer update --dry-run -v，观察输出中是否出现Downloading https://packages.myorg.com/packages.json
第三方包更新滞后时，必须同步清理的三个位置
仅删 repo 缓存还不够。第三方扩展包的版本判断依赖三处快照，缺一不可：
-
~/.composer/cache/repo/https---xxx/：远程 packages.json 的本地镜像，决定“有哪些版本” -
vendor/composer/installed.json：当前已安装包的精确记录，影响composer show和依赖解析起点 -
composer.lock：硬性锁定旧版本号；若不删它，composer update默认仍按锁文件装，根本不会去远端查新版本
推荐组合命令（Linux/macOS）：composer clear-cache && rm -rf ~/.composer/cache/repo/https---packages-myorg-com && rm -f vendor/composer/installed.json && rm -f composer.lock && composer update
CI/CD 中清理第三方缓存容易卡住的两个坑
在 GitHub Actions、GitLab CI 等无交互环境里，对第三方源缓存操作极易失败，不是权限问题，而是进程锁和路径错位：
-
composer clear-cache在 CI 中默认等待确认，必须加--no-interaction；但更关键的是：它可能清的是 runner 的全局缓存，而非你构建镜像里挂载的缓存路径 - 某些私有源配置用了
COMPOSER_CACHE_DIR环境变量，但 CI 脚本没继承该变量，composer config --global cache-dir返回的是默认路径，实际缓存却在/tmp/composer-cache这类临时位置 - 解决办法：统一用绝对路径操作，例如
rm -rf $COMPOSER_CACHE_DIR/repo/https---packages-myorg-com，而不是依赖composer config输出 - 如果不确定缓存是否被占用，CI 中不要用
rm -rf，改用find $COMPOSER_CACHE_DIR/repo -name "https---packages-myorg-com" -type d -exec rm -rf {} +，避免误删其他目录
第三方扩展包的缓存机制比官方源更隐蔽，路径转义、多级嵌套、环境变量覆盖都容易让清理动作落空。最稳妥的做法是：每次清理前，先 ls 看真实目录名，再手动删，而不是依赖任何“一键”命令。
