Composer下载依赖时的临时文件默认存于缓存根目录下的downloads/（下载中）和files/（校验后），实际路径由COMPOSER_CACHE_DIR环境变量或composer config --global cache-dir决定，可通过composer diag确认；downloads/为瞬态目录，下载完成后即清空。
composer下载依赖时的临时文件存在哪里？
Composer 下载依赖过程中产生的临时文件（如未解压的 .zip、.tar.gz 归档，以及解包中途的临时目录）默认不存放在项目内，而是统一写入缓存根目录下的 downloads/ 和 files/ 子目录中——但注意：downloads/ 仅用于暂存正在下载的原始归档（下载完成后立即移走），而 files/ 才是长期存放已验证 ZIP 包的最终位置。
关键路径结构如下：
-
downloads/：存放正在下载中的临时归档（例如downloads/2a/2a3b4c5d.zip.part），下载失败或中断时可能残留 -
files/：下载完成并校验通过后，ZIP 包会被移动至此，按vendor/name/hash/组织（hash 是 dist URL 的 SHA256） -
repo/：存放packages.json等元数据缓存，不影响下载临时文件行为 -
http/：HTTP 响应体缓存（如 304 响应头），与包文件无关
也就是说，你看到 Downloading https://... 日志时，文件正往 downloads/ 写；一旦日志变成 Writing into cache: /files/...，说明已转入 files/ 并准备解压。
如何准确查看当前生效的默认缓存路径？
别猜，直接问 Composer 自己。它会告诉你真实路径，而不是配置里写的“理想路径”——尤其当 COMPOSER_CACHE_DIR 环境变量存在时，它会直接覆盖所有 config 设置。
执行以下命令组合确认：
- 查环境变量是否生效：
php -r "echo getenv('COMPOSER_CACHE_DIR');"，输出非空则以此为准 - 查全局 config 配置：
composer config --global cache-dir，仅当上一步为空时才参考此值 - 看完整诊断信息：
composer diag，最后一行会明确写出Cache directory实际路径
注意：即使 cache-dir 配置为 /tmp/composer-cache，真正的 ZIP 包仍落在 /tmp/composer-cache/files/ 下——因为 Composer 强制将包文件写入 cache-dir/files/，且该子目录必须存在、可写。
为什么 ls ~/.composer/cache 有时看不到 downloads/？
因为 downloads/ 是瞬态目录：Composer 只在下载进行中创建它，下载成功后立刻把文件 mv 到 files/，并删除空的 downloads/。所以你通常只能看到 files/ 和 repo/。
要捕获它，可以：
- 用
composer install -vvv观察日志，留意Downloading行出现时快速ls -l ~/.composer/cache/downloads/ - 手动制造失败：比如断网后运行
composer require some/package，中断后downloads/往往残留.part文件 - 不要依赖
downloads/做任何自动化清理——它本就不该长期存在
真正需要关注和定期清理的是 files/，它不会自动收缩，积攒几个月可能达数 GB，且不同项目同一包的多个版本 hash 全堆在里面，而你往往只用最新一两个。
