Composer update 的缓存文件统一存放在 COMPOSER_HOME/cache 下，Linux/macOS 默认为 ~/.composer/cache，Windows 为 %APPDATA%\Composer\Cache；运行 composer config --global cache-dir 可查看实际路径。
Composer update 时缓存文件存在哪里
Composer 的 update 命令本身不生成独立的“缓存文件”，它依赖的是 Composer 自身的全局缓存机制，所有下载的包（zip/tar、dist 包、源码克隆）都统一存放在 COMPOSER_HOME/cache 下。这个路径不是每次 update 新建的，而是长期复用的。
默认位置取决于系统：
- Linux/macOS：
~/.composer/cache - Windows：
%APPDATA%\Composer\Cache（通常是C:\Users\{user}\AppData\Roaming\Composer\Cache）
你可以用命令直接查到准确路径：
composer config --global cache-dir
怎么确认某个包是否被缓存了
缓存目录结构是按 vendor/package 名哈希分层的，比如 monolog/monolog 可能落在 cache/files/8a/8a1.../ 这类子目录里。但手动翻找效率低，更可靠的方式是让 Composer 显式告诉你：
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 运行
composer update --verbose，过程中会打印类似Downloading https://api.github.com/... (cached)或Using version ^2.10 for monolog/monolog+Cache hit: ...的提示 - 如果看到
Cache hit，说明该包的 dist 归档已从缓存读取；如果是Downloading且没标(cached)，说明走网络重新拉了 - 注意：
--no-cache参数会强制跳过缓存，可用于对比验证
缓存内容类型和清理时机
Composer 缓存包含三类东西：files（包归档）、repos（packagist.org 元数据快照）、vcs（Git clone 的 shallow repo 镜像）。其中 files 是 update 最常复用的部分。
-
files缓存不会自动过期，除非包版本发布新 commit hash 或新 dist URL（比如 GitHub release 重发） - 执行
composer clear-cache会清空全部三类，不是只清update产生的 - 如果你改了
composer.json中的minimum-stability或加了repositories，旧缓存可能失效，但 Composer 不会主动删，得靠你观察下载行为或手动清
想看 update 过程中具体用了哪些缓存文件
没有现成命令直接列出“本次 update 用到了哪几个缓存文件”，但可以间接追踪：
- 先记下当前缓存目录大小：
du -sh $(composer config --global cache-dir)/files - 运行
composer update --dry-run（不实际安装），再跑一次真实update，对比前后files目录大小变化——没变说明全命中缓存；明显增大说明有新包或新版被下载并存入 - 配合
strace（Linux）或Process Monitor（Windows）监控composer进程对缓存目录的openat/CreateFile调用，能定位具体文件路径，但属调试级操作，日常没必要
真正需要关心的不是“哪个文件被用了”，而是“为什么没命中缓存”——常见原因是包更新了 dist URL、启用了 prefer-source、或者缓存目录权限异常导致写入失败，这时候 update 就会退回到慢速下载模式。
