最安全标准的清理方式是直接运行 composer clear-cache，它只清空 ~/.composer/cache 或 %appdata%\composer\cache 下 files/、repo/、vcs/ 三个子目录，不触碰 vendor/、composer.lock 和项目配置。
直接运行 composer clear-cache 就行，它只动缓存，不碰项目文件
这是最安全、最标准的清理方式。命令会清空 ~/.composer/cache（Linux/macOS）或 %APPDATA%\Composer\Cache（Windows）下的 files/、repo/、vcs/ 三个子目录，不会删除你的 vendor/、composer.lock 或任何项目配置。
- 执行前不用进项目目录，任意路径下敲命令都有效
- 看到
Clearing cache (cache-dir): /home/xxx/.composer/cache这类输出，说明路径正确、操作成功 - 别加
sudo——除非你当初用sudo装过 Composer，否则后续所有命令都会因权限错乱而报错 -
composer clearcache是等价别名，效果完全一样
先看缓存占多大、在哪儿，再决定要不要清
很多人一遇到装包慢或版本不对，就急着清缓存，结果发现根本不是缓存的问题。缓存本身很老实，出问题往往是因为你刚换过 PHP 版本、改过镜像源、或手动动过 ~/.composer/cache/ 里的文件。
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 查当前路径：
composer config --global cache-dir - 看大小（Linux/macOS）：
du -sh $(composer config --global cache-dir)；Windows 直接打开资源管理器导航到%APPDATA%\Composer\Cache看属性 - 不到 200MB？大概率不是磁盘告警主因；超过 1.5GB 且半年没碰老项目，才值得动手
- CI/CD 里无脑加
composer clear-cache反而拖慢构建——首次 install 会变慢是设计使然，不是 bug
--dry-run 是必做的预检动作
它不删文件，只告诉你“接下来会清哪些东西”，能帮你避开误删风险，尤其当你怀疑缓存路径被自定义过、或公司用了 NFS 共享缓存时。
- 运行：
composer clear-cache --dry-run - 输出里如果显示的路径不是你预期的（比如指向了
/mnt/nfs/composer-cache），说明缓存不在默认位置，clear-cache默认只清那个路径，不会遍历其他可能位置 - 手删前务必确认
composer进程已退出，否则可能删到一半被写入，后续报Corrupted cache file
想精准清理？官方没提供，只能手动筛
composer clear-cache 是全量清，没有按包名、按时间、按大小筛选的选项。所谓“精准”，只能靠你进缓存目录自己判断。
- 清旧包归档：
find ~/.composer/cache/files -name "*.zip" -mtime +90 -delete（删 90 天前的 zip） - 清废弃 Git 缓存：
rm -rf ~/.composer/cache/vcs/*（vcs 目录下次需要时自动重建，安全） - 别轻易动
repo/packagist.org/——这是核心索引缓存，删了会导致首次composer update明显变慢 - 真正锁定版本的是
composer.lock，清缓存不会改变依赖解析结果；要模拟“从零开始”，得组合操作：rm -rf vendor composer.lock && composer install --no-cache
xdebug 开着、私有包 token 过期、PHP 版本和 composer.json 里写的不一致，这些都比清缓存优先级更高。
