composer clear-cache只清全局缓存目录下的files/、repo/、vcs/子目录，不删vendor/、composer.lock等项目文件；清完后install仍按lock文件装旧版，是设计如此而非命令失效。
composer clear-cache 只清本地下载缓存，不删 vendor/、composer.lock 或项目文件；清完后 composer install 仍按锁文件装旧版，不是命令失效，是设计如此。
composer clear-cache 到底删哪些路径
它只操作 Composer 全局缓存目录下的子目录，路径由 composer config --global cache-dir 决定（Linux/macOS 默认 ~/.composer/cache，Windows 默认 %APPDATA%\Composer\Cache）：
-
files/：所有已下载的.zip、.tar包 -
repo/：远程源的元数据快照（如packagist.org/packages.json） -
vcs/：Git 克隆的裸仓库（用于从 Git 安装包时复用）
不会碰：vendor/、composer.json、composer.lock、PHP OPcache、CI 构建中挂载的共享缓存卷、镜像 CDN 缓存、插件（如 hirak/prestissimo）的临时文件。
为什么清了缓存还是装不到新版包
常见误判根源不在缓存，而在版本锁定或元数据延迟：
-
composer.lock文件存在 →composer install必然还原旧依赖树，和缓存无关 - 镜像源有 CDN 缓存（如阿里云、腾讯云）→
clear-cache只清本地，不刷新镜像服务器上的packages.json - 私有包改了 tag 但没推新 commit → Composer 复用本地解压结果，根本不会查远程，这时清缓存才有效
- 元数据 TTL 未过期（通常 24 小时）→ 即使清了
repo/，首次update仍可能拉到旧快照
想强制升版：先 rm composer.lock，再 composer update 或 composer install --no-cache（注意 --no-cache 是跳过本次读写，不是清缓存）。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
手动精准清理比全量 clear-cache 更实用
Composer 没提供按包名、时间、大小筛选的内置命令，真要省空间得自己进目录认路：
- 清老 zip 包（90 天前）：
find ~/.composer/cache/files -name "*.zip" -mtime +90 -delete - 清废弃 Git 缓存（安全，下次自动重建）：
rm -rf ~/.composer/cache/vcs/* - 别乱动
repo/packagist.org/→ 这是核心索引，删了会导致首次composer update明显变慢 - 手删前确保没有
composer进程在后台运行，否则可能触发Corrupted cache file报错
真正容易被忽略的是：某些团队把缓存挂到 NFS 或自建镜像目录，clear-cache 默认只清 composer config --global cache-dir 指向的那个路径，不会遍历所有可能位置。
CI/CD 中无脑加 clear-cache 反而拖慢构建
缓存本该复用，不是每次都要重来：
- GitHub Actions 等平台推荐用
actions/cache挂载~/.composer/cache，清缓存等于放弃加速优势 - 真要“干净构建”，更稳妥的做法是：
composer config -g cache-dir /tmp/composer-cache，让缓存随容器销毁自动清理 - 遇到
Failed to extract或file could not be downloaded这类明确损坏错误，再针对性rm -rf ~/.composer/cache - 频繁清理又频繁装包？不如定期
composer self-update—— 新版对缓存压缩和复用更聪明
缓存不是垃圾，是 Composer 的性能杠杆；乱清不如看清它在哪、被谁用、坏了怎么换。
