SSD缓存对Composer元数据读取无直接加速作用——因元数据通过HTTP请求获取，不经过本地磁盘；仅当Composer复用~/.composer/cache/repo/中未过期的缓存时，SSD才提升IO性能。
SSD 缓存对 Composer 镜像源的元数据（metadata）读取没有直接加速作用——因为元数据请求走的是 HTTP，不是本地文件读取。真正能提速的，是 Composer 自身的本地缓存机制，而 SSD 只在它生效时放大效果。
Composer 元数据请求根本不经过 SSD 缓存
很多人误以为“把 Composer 缓存目录挪到 SSD 就能加速 packages.json、provider-laravel~6.0.json 这类元数据加载”，但事实是：这些文件由 Composer 在运行时通过 cURL 向镜像站发起 HTTP GET 请求获取，全程不读本地磁盘缓存（除非已提前下载并命中 cache）。也就是说，首次请求、或缓存过期/失效时，SSD 再快也帮不上忙——瓶颈在网络往返和镜像站响应速度。
只有当 Composer 从 ~/.composer/cache/repo/ 里成功复用已缓存的元数据时，SSD 才起作用。而这个缓存是否被复用，取决于两个关键条件：
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
-
cache-files-dir和cache-repo-dir是否指向 SSD 路径（默认二者共享同一 cache-root） - 元数据缓存是否未过期（Composer 默认 TTL 是 15 分钟，且每次
composer update会强制刷新）
怎么让 SSD 缓存真正被用上？
光把 cache-dir 改到 SSD 不够，必须确保 Composer 在高压力下仍愿意复用缓存，而不是频繁重拉。实操要点如下：
- 显式设置缓存路径：
composer config --global cache-dir /mnt/ssd/composer-cache（Linux）或composer config --global cache-dir D:\composer-cache（Windows） - 禁用元数据强制刷新：加
--no-plugins和--prefer-stable减少非必要查询；避免在 CI 中频繁跑composer update，改用composer install复用composer.lock - 确认缓存实际命中：执行
composer install -vvv，观察日志中是否出现Using cached repo.packagist.org或类似提示；若全是Downloading https://mirrors.aliyun.com/composer/...，说明没走缓存 - 别依赖
COMPOSER_CACHE_DIR环境变量覆盖——它只影响cache-dir，不控制cache-repo-dir的行为，优先用composer config命令设
高压力下元数据卡顿的真实原因和对策
在 CI 或多并发构建场景中，Loading composer repositories 卡住几十秒，通常不是 SSD 慢，而是以下问题叠加：
- 镜像源未同步新 provider 文件（如
provider-laravel~10.0.json），导致 Composer 重试多次后 fallback 到下一个源，每轮等待 30 秒 - cURL DNS 缓存复用导致解析到海外 IP（即使域名是
mirrors.aliyun.com），需加环境变量CURLOPT_DNS_USE_GLOBAL_CACHE=0或临时设export CURLOPT_DNS_USE_GLOBAL_CACHE=0 - 并发数太低：默认
parallel-downloads=5，不足以压满镜像带宽；建议设为15：composer config --global parallel-downloads 15 - PHP 的 opcache 或 realpath_cache 过小，大量
file_exists()检查拖慢缓存路径访问——尤其在容器内挂载 SSD 时，要调大realpath_cache_size=4M和realpath_cache_ttl=600
SSD 有价值，但只在缓存命中率高、且磁盘 IO 成为瓶颈时才明显；多数情况下，元数据慢的本质是网络策略和镜像同步问题，不是存储介质问题。
