直接运行composer clear-cache即可安全清除缓存，它只删除~/.composer/cache（linux/macos）或%appdata%\composer\cache（windows）下的files/、repo/、vcs/子目录，不触碰vendor/、composer.lock或项目配置。
直接运行 composer clear-cache 就行，它只动缓存目录里的 files/、repo/、vcs/，不碰 vendor/、composer.lock 或项目任何配置——这是最安全、最标准的清理方式。
怎么确认缓存路径和大小？别一上来就删
清之前先看两件事：缓存到底在哪、占了多大空间。盲目清理既没必要，还可能掩盖真问题。
- 查路径：
composer config --global cache-dir—— 输出类似/home/user/.composer/cache（Linux/macOS）或C:\Users\user\AppData\Roaming\Composer\Cache（Windows） - 看大小：
Linux/macOS 执行du -sh $(composer config --global cache-dir)
Windows 直接打开资源管理器，导航到上述路径，右键“属性” - 不到 200MB 基本不用管；超过 1.5GB 且你半年没碰过某些老项目，才值得动手
- 如果输出路径指向
/mnt/nfs/composer-cache这类非默认位置，说明缓存被自定义过，clear-cache只清这个路径，不会遍历其他地方
为什么加 --dry-run 是必做的预检动作？
它不删文件，只告诉你“接下来会清哪些东西”，能帮你避开误删风险，尤其在共享缓存或 CI 环境里。
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 执行
composer clear-cache --dry-run，观察输出的路径是否符合预期 - 如果显示的是 NFS 挂载路径，而你本意是清本地缓存，那就得先检查
composer config --global cache-dir是否被覆盖 - CI/CD 中若用自建镜像源，
--dry-run能提前发现缓存路径错位，避免构建失败后排查半天
composer clear-cache 在 CI/CD 里为什么容易卡住？
因为默认行为会等待交互确认，而 GitHub Actions、GitLab CI 这类环境没有 TTY，命令就 hang 住了。
- 必须加
--no-interaction：用composer clear-cache --no-interaction - 脚本里写成
"clean-cache": "composer clear-cache --no-interaction"，再通过post-install-cmd调用，但注意：CI 通常加--no-scripts，这类脚本根本不会执行 - 更稳妥的做法是在 workflow 步骤里单独写：
run: composer clear-cache --no-interaction - 如果想彻底模拟“干净安装”，光清缓存不够，还得搭配
rm -rf vendor+composer install --no-cache --prefer-dist
手动删子目录时，哪些能删、哪些最好别碰？
Composer 不提供按包名或时间筛选的清理能力，所谓“精准”只能靠你进目录自己判断，但得知道边界在哪。
-
~/.composer/cache/files/：存所有.zip/.tar包，冗余最多，可安全删，比如用find ~/.composer/cache/files -name "*.zip" -mtime +90 -delete清 90 天前的 -
~/.composer/cache/vcs/：存 Git 裸仓库，切分支/换源频繁时容易积攒废弃目录，rm -rf ~/.composer/cache/vcs/*安全，下次需要时自动重建 -
~/.composer/cache/repo/packagist.org/：核心索引缓存，删了会导致首次composer update明显变慢，不建议动 - 手删前务必确认
composer进程已退出，否则可能引发Corrupted cache file报错
真正影响依赖行为的是 composer.lock，不是缓存；缓存只是加速手段。很多“清了没用”的情况，根源其实在镜像源配置、网络代理或 lock 文件锁定的版本上——缓存只是第一个被怀疑的对象，不是万能解药。
