直接运行 composer clear-cache 仅清除 ~/.composer/cache/ 或 %APPDATA%\Composer\Cache 下的缓存，不影响 vendor/、composer.lock 和项目配置；需先用 composer config --global cache-dir 确认路径并检查大小，再针对性清理。
直接运行 composer clear-cache 就能清掉本地缓存文件，但它只删 ~/.composer/cache/（Linux/macOS）或 %APPDATA%\Composer\Cache（Windows）下的内容，不会动你的 vendor/、composer.lock 或项目配置——这点必须先确认清楚，否则容易误以为“清了没用”其实是删错了地方。
怎么确认缓存真占地方？别瞎清
很多人一看到磁盘告警就跑 composer clear-cache，结果发现空间没少多少——因为缓存可能根本不是元凶。
- 先查路径：
composer config --global cache-dir，看它实际指向哪 - 再看大小：Linux/macOS 用
du -sh $(composer config --global cache-dir)；Windows 直接打开资源管理器，导航到%APPDATA%\Composer\Cache看“属性” - 不到 200MB 基本不用管；超过 1.5GB 且你半年没碰某些老项目，才值得动手
- 有些公司把缓存挂到 NFS 或自建镜像目录，
clear-cache默认只清配置里那个路径，不会遍历所有可能位置
为什么 composer clear-cache 有时没反应或报错
常见现象是执行后提示 Cache directory does not exist，或者反复运行缓存大小不变。根本原因往往不是命令本身问题：
- 权限错乱：比如之前用
sudo composer install写过缓存，现在普通用户运行clear-cache就会被拒绝删除 - 缓存路径被覆盖：设置了
COMPOSER_CACHE_DIR环境变量但未生效，clear-cache实际清的是空路径 - 文件被占用：杀毒软件或 IDE（如 PHPStorm）正在扫描
~/.composer/cache/files/下的 ZIP，系统锁住不让删 - CI/CD 中混用用户：Docker 构建时用 root 跑过 composer，后续非 root 用户执行
clear-cache就会失败
想只清某类缓存，而不是全量删
composer clear-cache 是全量操作，但你可以手动进目录精准清理：
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 只删下载过的原始包（节省最多空间）：
rm -rf ~/.composer/cache/downloads/*或rm -rf ~/.composer/cache/files/* - 只清元数据（解决“装不到新版包”类问题）：
rm -rf ~/.composer/cache/repo/* - 只清 Git 克隆缓存（影响 vcs 类仓库拉取）：
rm -rf ~/.composer/cache/vcs/* - 手删前务必确认没有
composer install或update进程在后台跑，否则可能触发Corrupted cache file报错
清完之后装包变慢，是不是命令出错了
不是。这是设计行为，不是故障：
-
repo/清空 → 下次install得重新 HTTP 请求 packagist.org 或镜像源拉packages.json，首次明显卡顿 -
files/清空 → 所有.zip都得重下，尤其含大资产（如 Laravel UI、前端模板）的包更明显 - 频繁清理又频繁装包，建议改用
composer self-update—— 新版 Composer 对缓存压缩和复用更聪明，比反复清缓存更能稳住磁盘增长节奏
真正容易被忽略的是：私有仓库配置（比如 repositories 在 composer.json 或全局 config 里）会让清完缓存后的首次请求变慢——不是 bug，是设计使然，元数据必须重新 fetch。
