Composer缓存目录默认为~/.composer/cache（Linux/macOS）或%APPDATA%\Composer\Cache（Windows），可通过composer config --global cache-dir查看；修改需用--global配置、编辑config.json或设COMPOSER_CACHE_DIR环境变量，但不自动迁移旧缓存。
Composer缓存目录在哪？默认位置和查看方法
Composer 默认把包缓存放在用户主目录下的 vendor 之外的独立位置，不是项目里那个 vendor 文件夹——很多人误以为删了 vendor 就清了缓存，其实没用。
运行 composer config --global cache-dir 能直接看到当前生效的缓存路径；没配置过的话，它会按系统返回默认值：~/.composer/cache（Linux/macOS）或 %APPDATA%\Composer\Cache（Windows）。
- 这个路径是全局生效的，影响所有项目
- 如果用
--local而不是--global查，会显示项目级配置（极少有人这么设） -
composer diag也会在输出里带一行Cache directory，更直观
怎么改 Composer 缓存目录？三种可靠方式
改缓存路径本质是改 cache-dir 配置项，但必须注意：改完不会自动迁移旧缓存，得手动搬或清掉。
- 用命令行设全局路径：
composer config --global cache-dir /path/to/my-composer-cache - 编辑
~/.composer/config.json，手动加或改"cache-dir": "/path/to/cache"字段 - 通过环境变量临时覆盖：
COMPOSER_CACHE_DIR=/tmp/composer-cache composer install（适合 CI 或临时调试）
注意：COMPOSER_HOME 环境变量会影响整个 Composer 配置根目录，别乱动它来“间接”改缓存——容易连带搞乱 auth.json 和插件目录。
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
改缓存目录后为什么 vendor 还是下载慢？常见陷阱
换了路径 ≠ 自动提速。缓存只加速“已下过的包”的安装，首次安装、包更新、require 新包时仍要走网络拉取。
- 缓存目录权限不对（比如挂载到 NFS 或 root 写入的目录），会导致 Composer 静默跳过写缓存，反复重下
- 用了
--no-cache或COMPOSER_CACHE_DIR=""环境变量，会强制禁用缓存，配置白改 - 某些镜像源（如 packagist.phpcomposer.com 已停服）响应异常，Composer 会绕过缓存直接重试，看起来像“缓存失效”
验证是否真在用缓存：装完后看新缓存目录里有没有对应 archived/ 和 repo/ 子目录，再对比 composer show -p 输出里的 install-time 是否明显快于首次。
多用户或 Docker 环境下缓存目录要注意什么？
共享缓存能省空间和时间，但前提是权限和一致性可控。Docker 里尤其容易踩坑。
- Docker 构建阶段挂载宿主机缓存目录时，确保 UID/GID 匹配，否则 Composer 写失败后不报错，只退化为无缓存模式
- CI 环境（如 GitHub Actions）建议用
COMPOSER_CACHE_DIR+ 缓存步骤（actions/cache），而不是依赖默认路径——默认路径在 runner 重启后就丢了 - 多个用户共用一台机器时，不要把缓存设到
/tmp或其他易清理路径，也别设成所有人可写的目录，避免缓存污染或权限冲突
最稳的做法：每个用户或每个 CI job 用自己隔离的缓存路径，哪怕多占点磁盘，也比因缓存错乱导致构建结果不一致强。
