缓存非磁盘告警主因，200MB内无需处理；超1.5GB且半年未用老项目才需清理，须先查路径再判大小，避免误删；clear-cache仅清cache-dir指向路径，不遍历NFS或镜像目录；清缓存不解决版本、网络或源配置问题。
缓存不是磁盘告警主因，不到 200MB 别急着清；超过 1.5GB 且半年没碰老项目，才值得动手。
怎么确认缓存真占地方？
别凭感觉删。先查路径，再看大小，否则可能白忙活：
- 查当前缓存位置：
composer config --global cache-dir - Linux/macOS 看体积：
du -sh $(composer config --global cache-dir) - Windows 直接打开资源管理器，粘贴
%APPDATA%\Composer\Cache→ 右键“属性” - 不到 200MB？基本不用管；超 1.5GB 才需干预
有些公司把缓存挂到 NFS 或自建镜像目录，composer clear-cache 默认只清 cache-dir 指向的路径，不会遍历其他位置。
为什么清了 clear-cache 还是装旧包、报错或空间没少？
缓存只是加速层，不是决策源头。清它不等于版本升级、也不解决网络问题：
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
-
composer install装什么，由composer.lock和repositories配置决定，和缓存无关 - 报
file could not be downloaded或Failed to decode JSON？大概率是网络、代理或源配置问题，不是缓存脏了 - 刚切了阿里云镜像但还 404？先确认
composer config repo.packagist false已生效，否则缓存清理白搭 - 私有源响应头带
X-Composer-Cache-TTL（如腾讯云 TKE 镜像），本地清了也没用，得等镜像源自己过期，或临时切回官方源验证
手动删 ~/.composer/cache/files 节省最多空间
composer clear-cache 是全量清，官方不提供按包名、时间、大小筛选的选项。“精准清理”只能靠你自己进目录判断：
-
~/.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 install或update进程在后台运行，否则可能触发Corrupted cache file报错
CI/CD 里加 clear-cache 反而拖慢构建
清完 repo/ 子目录后，下次 install 得重新 HTTP 请求拉取 packages.json，首次明显卡顿——这是设计行为，不是故障。
CI 环境中无脑加 composer clear-cache 不仅浪费时间，还掩盖真实问题。更稳妥的做法是：
- 用
composer clear-cache --dry-run预检，确认它清的是你预期的路径（比如不是指向/mnt/nfs/composer-cache） - 某些 CI 平台（如 GitHub Actions）用
actions/cache挂载共享缓存卷，clear-cache根本不作用于那里 - 真正容易被忽略的是：缓存路径可能被
COMPOSER_CACHE_DIR环境变量覆盖，但未生效，导致命令实际清的是空路径
