composer config --global cache-dir 输出的是当前 composer 实际使用的缓存根目录，因环境变量（如 composer_cache_dir）、用户权限或容器挂载可能与默认路径（linux/macos 为 ~/.composer/cache，windows 为 %appdata%\composer\cache）不同；查实路径后需用 du -sh（linux/macos）或资源管理器“属性”（windows）确认占用，仅当超 1.5 gb 且长期未用才清理，注意 vcs/ 子目录不被 clear-cache 覆盖。
composer config --global cache-dir 能直接告诉你真实路径
Composer 不会把缓存路径硬编码进源码，而是运行时根据 COMPOSER_HOME、COMPOSER_CACHE_DIR 环境变量和系统平台动态推导。所以别猜，直接问它：
- 运行
composer config --global cache-dir，输出的就是当前 Composer 实际使用的缓存根目录 - 没配过的话，Linux/macOS 默认是
~/.composer/cache，Windows 是%APPDATA%\Composer\Cache - 如果输出路径看起来“不像”你预期的（比如是
/tmp/composer-cache），说明环境变量COMPOSER_CACHE_DIR已被设过，优先级高于默认值
为什么 ~/.composer/cache 有时不是真实路径？
常见干扰项有三个：环境变量覆盖、root 用户切换、CI 容器挂载。它们会让 composer config --global cache-dir 输出与直觉不符的结果：
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
-
COMPOSER_CACHE_DIR环境变量一旦设置，就完全接管缓存位置，~/.composer/cache变成摆设 - 在 Docker 或 GitHub Actions 中，经常用
-v $(pwd)/.composer-cache:/root/.composer/cache挂载，此时缓存实际存在宿主机的.composer-cache/目录里 - 用
sudo composer install后，缓存可能写进了 root 的/root/.composer/cache，而普通用户运行clear-cache清的是自己的路径，根本清不到
确认路径后怎么查实际占用？
光知道路径不够，得看它到底占了多少空间。不同系统检查方式不一样，但核心逻辑一致：先定位，再统计
- Linux/macOS：
du -sh $(composer config --global cache-dir)—— 一行命令出结果 - Windows：在资源管理器地址栏粘贴
%APPDATA%\Composer\Cache，回车后右键文件夹 → “属性”，看“大小” - 若结果小于 200 MB，基本不用管；超过 1.5 GB 且你半年没碰相关项目，才值得清理
- 特别注意
vcs/子目录：它存 Git 裸仓库，默认不被composer clear-cache清理，单个仓库常占 300–800 MB，还容易耗尽 inode
缓存路径和 vendor 目录不是一回事
新手最容易混淆这两处。缓存是全局的、只读的中间产物；vendor 是项目的、可写的最终依赖目录：
- 缓存路径由
composer config --global cache-dir查，内容在files/、repo/、vcs/下 - vendor 目录在项目根目录下，由
composer.json中config.vendor-dir决定（默认就是vendor） - 磁盘告警时，
vendor/常比缓存大得多（一个 Laravel 项目 vendor 轻松超 300 MB），但删 vendor 不等于清缓存，两者互不影响
composer config --global cache-dir 这一步，也别在没看体积前就动手删。
