composer clear-cache只清除~/.composer/cache（linux/macos）或%appdata%\composer\cache（windows）下的files/、repo/、vcs/三个子目录，不删除vendor/、composer.lock或项目文件；执行前应先用composer config --global cache-dir查路径，再用du -sh（linux/macos）或资源管理器属性（windows）确认大小，超1.5gb且长期未用才建议清理。

直接运行 composer clear-cache 就行，它只清 ~/.composer/cache（Linux/macOS）或 %APPDATA%\Composer\Cache（Windows）下的 files/、repo/、vcs/ 三个子目录，不碰 vendor/、composer.lock 或任何项目文件——这是安全底线，别越界。

怎么确认缓存真占地方、在哪儿、值不值得清

很多人一看到磁盘告警就跑命令，结果发现空间没少多少。缓存本身很老实，出问题往往是因为你刚换过 PHP 版本、改过镜像源、或手动动过缓存目录里的文件。

• 先查路径：composer config --global cache-dir，输出就是 Composer 当前认的缓存根目录
• 再看大小：
  • Linux/macOS：执行 du -sh $(composer config --global cache-dir)
  • Windows：把 %APPDATA%\Composer\Cache 粘贴进资源管理器地址栏，右键 → “属性”
• 不到 200MB？基本不用管；超过 1.5GB 且你半年没碰某些老项目，才值得动手
• 有些公司把缓存挂到 NFS 或自建镜像目录，clear-cache 默认只清 cache-dir 指向的那个路径，不会遍历其他可能位置

为什么 composer clear-cache 有时没反应或报错

常见现象是执行后提示 Cache directory does not exist，或者反复运行缓存大小不变。根本原因往往不是命令本身问题：

Discussion Composer

围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par

下载

• 权限错乱：比如之前用 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 是全量操作，但你可以手动进目录精准清理——官方没提供按包名、时间、大小筛选的内置命令，所谓“精准”，只能靠你自己认路：

• 只删下载过的原始包（节省最多空间）：rm -rf ~/.composer/cache/files/* 或 rm -rf ~/.composer/cache/downloads/*
• 只清元数据（解决“装不到新版包”类问题）：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、前端模板）的包更明显
• CI/CD 里无脑加 composer clear-cache 反而拖慢构建——首次 install 变慢是设计使然，不是 bug
• 真正容易被忽略的是：私有仓库配置（比如 repositories 在 composer.json 或全局 config 里）会让清完缓存后的首次请求变慢，这不是 bug，是设计使然，元数据必须重新 fetch