composer clear-cache仅清除全局缓存目录（Linux/macOS为~/.composer/cache，Windows为%APPDATA%\Composer\Cache）中的files/、repo/、vcs/子目录，不删除vendor/、composer.lock或项目文件；需先用composer config --global cache-dir确认路径并检查大小（如du -sh或资源管理器属性），不足200MB无需清理，超1.5GB且长期未用老项目才建议执行。
直接运行 composer clear-cache 就能清掉本地缓存，但它只删 ~/.composer/cache/（Linux/macOS）或 %APPDATA%\Composer\Cache（Windows）下的内容，不会动你的 vendor/、composer.lock 或项目文件——这点必须先确认清楚，否则容易误以为“清了没用”其实是删错了地方。
怎么确认缓存真占地方？别瞎清
很多人一看到磁盘告警就跑 composer clear-cache，结果发现空间没少多少——因为缓存可能根本不是元凶。
- 先查路径：
composer config --global cache-dir，看它实际指向哪 - 再看大小：Linux/macOS 用
du -sh $(composer config --global cache-dir)；Windows 直接打开资源管理器，导航到%APPDATA%\Composer\Cache看“属性” - 不到 200MB 基本不用管；超过 1.5GB 且你半年没碰某些老项目，才值得动手
- 有些公司把缓存挂到 NFS 或自建镜像目录，
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 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/：核心索引缓存，删了会导致首次composer update明显变慢，不建议动 - 手删前务必确认
composer进程已退出，否则可能删到一半被写入，后续报Corrupted cache file
真正容易被忽略的是：私有仓库配置（比如 repositories 在 composer.json 或全局 config 里）会让清完缓存后的首次请求变慢——不是 bug，是设计使然，元数据必须重新 fetch。
