composer clear-cache 不支持按组织名过滤，仅全量清理；精准清理需手动操作：files/ 下用前缀匹配 ZIP 文件，vcs/ 中按 URL 片段查找删除，repo/ 不建议手动删，清理后须验证是否生效。
composer clear-cache 不支持按组织名过滤
官方命令 composer clear-cache 是全量清理，没有 --vendor、--prefix 或正则参数。它只删 ~/.composer/cache/files/、repo/、vcs/ 三个目录下的全部内容，无法识别“monolog/”或“spatie/”这类组织前缀。
手动进 cache/files/ 按 vendor 名筛选删除
真正能精准清理的只有手动操作，核心是利用文件名中的组织名特征（Composer 下载包时会把 vendor/name 转成小写 + 哈希路径，但 ZIP 文件名保留原始命名）：
-
files/目录下所有 ZIP 文件名含monolog-、spatie-、laravel-等前缀，可直接grep或find定位 - Linux/macOS 示例：
find "$(composer config --global cache-dir)/files" -name "monolog-*.zip" -delete
- Windows CMD 示例：
for %f in ("%APPDATA%\Composer\Cache\files\monolog-*.zip") do del "%f" - 注意：不要在
files/外层目录用通配符删，比如rm -rf ~/.composer/cache/files/monolog*可能误删合法哈希子目录
repo/ 和 vcs/ 目录里怎么找组织相关缓存？
repo/ 存的是 JSON 元数据，路径由哈希生成，不体现组织名；vcs/ 是 Git 裸仓库，目录名含 URL 片段（如 github.com-spatie-laravel-backup），可用字符串匹配：
- 查
vcs/中 spatie 相关：ls -d "$(composer config --global cache-dir)/vcs/*spatie*"
- 安全删除：
rm -rf "$(composer config --global cache-dir)/vcs/*spatie*"
-
repo/不建议手动删——它没明确组织标识，且删错会导致下次composer update重拉整个包索引，耗时更长 - 若确认某组织所有包都已弃用，可先
composer clear-cache，再删files/和vcs/中匹配项，跳过repo/
删完要验证是否生效，否则下次 install 还走旧缓存
缓存清理不是“删完就结束”，尤其 files/ 里残留一个旧 ZIP 就会让 composer install 直接解压复用，掩盖你刚做的清理动作：
- 验证
files/是否真清了：find "$(composer config --global cache-dir)/files" -name "monolog-*.zip" | head -n1
应无输出 - 触发一次真实下载：运行
composer require monolog/monolog:^3.0 --no-cache，观察是否从网络拉新 ZIP（而非秒解压） - 如果仍秒完成，说明有同名但不同哈希的 ZIP 残留，或你删的是错误路径（比如被
COMPOSER_CACHE_DIR环境变量覆盖了） - 最易忽略的一点：IDE（如 PHPStorm）或杀毒软件可能正占用 ZIP 文件，导致
find ... -delete静默失败，建议关掉相关进程再操作
