composer clear-cache 只清除 composer 下载缓存（如 ~/.composer/cache/repo/ 等），不影响 vendor/、composer.lock 或项目配置；常见误判如 install 拉旧版实为锁文件或元数据未更新所致。
composer clear-cache 命令到底清什么
它只清 Composer 自己的下载缓存（~/.composer/cache/ 下的 repo/、files/、archives/），不影响已安装的包、vendor/ 目录或项目级配置。
常见错误现象：运行 composer install 仍拉旧版本 —— 那不是缓存问题，是 composer.lock 锁定了版本，或 packagist 元数据没刷新。
-
composer clear-cache是最常用、最安全的清理方式，无副作用 - 执行后会显示清理了多少 MB，路径类似
Clearing cache (124.5 MiB) - Windows 用户注意：缓存路径在
%APPDATA%\Composer\Cache\，不是~/.composer
为什么 composer update 不走新缓存
因为 composer update 默认读的是 packagist.org 的远程元数据快照（存在本地 repo/ 缓存里），但这个快照本身有 TTL（通常 24 小时），clear-cache 并不能强制刷新它 —— 它只是删掉旧快照，下次请求时才会重新拉。
真正卡住更新的，往往是以下几种情况：
- packagist.org 源被墙或响应慢 → 改用国内镜像：
composer config -g repo.packagist composer https://packagist.phpcomposer.com - 项目中配置了
repositories且指向了过期的私有源 → 检查composer.json里的repositories字段 - 本地
composer.lock被手动改过，导致 hash 不匹配 → 直接删掉composer.lock再composer install
清除缓存后还报 vendor/autoload.php 不存在
这不是缓存问题，是 vendor/ 根本没生成。可能你刚清完缓存就直接跑 composer dump-autoload，但此时 vendor/ 还空着。
正确顺序只有两个：
- 全新安装：先
composer install（依赖composer.lock）或composer update（重算依赖），再composer dump-autoload - 仅刷新自动加载：确保
vendor/存在，再跑composer dump-autoload；加-o参数可生成优化版（composer dump-autoload -o）
如果 vendor/ 被误删，clear-cache 对它完全没影响，必须重新 install 或 update。
CI/CD 中要不要加 composer clear-cache
一般不需要。Docker 构建或 CI 环境通常是干净容器，~/.composer/cache/ 本来就是空的；反而加了会拖慢构建速度，因为每次都要重新下载 zip 包和元数据。
真要优化 CI，优先做这些：
- 用
--no-interaction --no-progress --prefer-dist减少输出和体积 - 把
~/.composer/cache/挂载为 CI 缓存目录（如 GitHub Actions 的actions/cache） - 避免在 CI 中运行
composer update，固定用composer install+ 提交composer.lock
缓存机制本身没问题，问题常出在对“缓存”边界的误解：Composer 的缓存不包含 vendor、不包含 lock、也不包含你本地改过的 composer.json 解析结果。
