composer clear-cache 只清除 composer 自维护的下载缓存（~/.composer/cache），含 downloads/、files/、repo/ 三部分，不影响 vendor/、composer.lock、php opcache 等。
composer clear-cache 到底清什么
它只清 Composer 自己维护的下载缓存，路径固定：~/.composer/cache（Linux/macOS）或 %APPDATA%\Composer\Cache（Windows）。里面分三块：downloads/（原始 .zip/.tar.gz）、files/（解压后的源码归档）、repo/（Packagist 或私有源的 JSON 元数据快照）。不会动你的 vendor/、composer.lock、composer.json，也不碰 PHP OPcache 或系统级缓存。
什么时候必须运行 composer clear-cache
不是每次 update 都要清，真需要它的情况很具体：
-
Could not parse version constraint—— 你确认composer.json没写错，但报语法错误，大概率是repo/里缓存了损坏的元数据 - 刚切了国内镜像源（比如阿里云），
composer update却还报404或找不到包 —— 旧源地址还卡在缓存里 - 改过
~/.composer/auth.json加了私有仓库 token，但依然提示认证失败 —— 认证信息可能被缓存在repo/子目录中 -
~/.composer/cache/占了几个 GB（CI 机器或长期未清理的开发机常见）
清完还是装旧版本？别怪缓存
composer clear-cache 后 install 还是旧版，不是缓存没清干净，而是 composer.lock 在起作用。它会强制复现上次锁定的依赖树，哪怕远程包已更新、缓存已空。
- 想重装全部最新兼容版：删掉
composer.lock，再跑composer install（不推荐）或composer update --with-all-dependencies - 只想更新某一个包：用
composer update vendor/package-name，避免全量重算 - 怀疑
lock文件被意外修改：先composer validate检查格式是否合法
彻底清理的组合操作（慎用）
CI 环境、调试依赖冲突、换 PHP 版本后重建依赖时，才需要这组动作：
- 清下载缓存：
composer clear-cache - 删锁文件：
rm composer.lock（Linux/macOS）或del composer.lock（Windows） - 删依赖目录：
rm -rf vendor或rmdir /s vendor - 重装：
composer install --no-cache（本次跳过读写缓存）或直接composer update --with-all-dependencies
注意：--no-cache 不是“清缓存”，它只是让当前命令不读也不写缓存；真正容易被忽略的是——清完缓存后首次访问私有源或新镜像，会明显变慢，因为元数据要重新 fetch，这是设计使然，不是故障。
