composer clear-cache 只清除 cache-dir 下 files/、repo/、vcs/ 三个子目录，不影响 vendor/、composer.lock 等；清 repo/ 是切换镜像后生效前提，但会导致首次 update 变慢并重拉 packages.json。
composer clear-cache 在中文镜像下到底清什么
它只清 composer config --global cache-dir 指向路径下的 files/、repo/、vcs/ 三个子目录，不碰 vendor/、composer.lock、auth.json，也不清 PHP OPcache 或镜像 CDN 缓存。你切了阿里云镜像（composer config -g repo.packagist https://mirrors.aliyun.com/composer/），但 repo/ 里还存着旧源的 packages.json 快照——这时候清缓存才是生效前提，否则新配置等于白配。
为什么清完反而 install 变慢、还报 Could not find package
这不是命令错了，是缓存结构被重置后的正常行为：
-
repo/被清空 → 下次composer update必须重新 HTTP 请求镜像源拉取packages.json，国内镜像通常多耗 2–5 秒 -
vcs/全删 → 用dev-main或未打 tag 的分支时，会重建 Git 裸仓库，I/O 明显升高 -
files/清空 → 所有.zip包重下，大包如laravel/framework或带前端资源的包最拖时间 - 如果仍报
Could not find package，先确认composer config repo.packagist输出是否为镜像地址；再跑composer clear-cache --dry-run看路径是否真指向你预期的缓存位置（比如挂载在/mnt/nfs/composer-cache却误删了本地~/.composer/cache）
手动清理 vcs/ 和 files/ 才真正释放空间
composer clear-cache 默认清三类，但 vcs/ 单个裸仓库常占 300–800 MB，files/ 里积压的旧版 .zip 更是空间大户——而这两项恰恰最容易被忽略：
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 安全清
vcs/：rm -rf ~/.composer/cache/vcs/*（Windows 对应%APPDATA%\Composer\Cache\vcs\*），下次需要时自动重建，无风险 - 精准清
files/里的老包：用find ~/.composer/cache/files -name "*.zip" -mtime +90 -delete删 90 天前的包，避免全删导致后续所有 install 都重下 - 别碰
repo/packagist.org/—— 这是核心索引目录，删了会导致首次 update 延迟显著上升，且中文镜像的元数据 TTL 通常 24 小时，没必要频繁清 - 检查是否被自定义路径覆盖：
echo $COMPOSER_CACHE_DIR或composer config --global cache-dir，尤其在 CI/CD 或团队 NFS 共享环境下，clear-cache只作用于配置路径，不会遍历其他挂载点
CI/CD 里加 clear-cache 的坑和写法
在 GitHub Actions 或 GitLab CI 里直接写 composer clear-cache 很容易卡住，因为默认等待交互确认，而 CI 环境没有 TTY：
- 必须加
--no-interaction：composer clear-cache --no-interaction - 建议前置
--dry-run做校验：composer clear-cache --dry-run输出路径不对就立刻停，避免误清共享缓存 - 别无脑加在每个 job 开头——缓存本该复用，只有镜像源切换、私有包更新或构建失败排查阶段才需要清
- 如果用了自建镜像并启用了
X-Composer-Cache-TTL响应头（如腾讯云 TKE 镜像），清本地缓存没用，得等镜像源过期或临时切回官方源验证
真正容易被忽略的是 inodes 耗尽问题：磁盘 df -h 显示还有空间，却报 No space left on device。这时候要跑 df -i，尤其在 WSL 或 macOS APFS 下，files/ 里几万个 .zip 文件会快速吃光 inodes——定期清理比全量清缓存更治本。
