Composer 缓存目录可通过环境变量 COMPOSER_CACHE_DIR 修改，其优先级最高；Linux/macOS 用 export，Windows 用 set 或 $env，CI/CD 在 env 中配置；config --global 仅写配置且易失效；需确保目录可写、本地存储、权限正确，并注意多项目共享时的 hash 冲突风险。
修改 Composer 缓存目录用 COMPOSER_CACHE_DIR
Composer 默认把下载的包缓存到系统用户目录下（比如 ~/.composer/cache），想换位置，最直接有效的方式是设环境变量 COMPOSER_CACHE_DIR。它优先级最高，比配置文件里的设置还管用。
常见错误是只改了 config.json 却发现缓存还是写在老地方——因为环境变量会覆盖配置项。
- Linux/macOS：在 shell 配置里加
export COMPOSER_CACHE_DIR="/path/to/your/cache"，然后source一下 - Windows（CMD）：
set COMPOSER_CACHE_DIR=D:\my-composer-cache - Windows（PowerShell）：
$env:COMPOSER_CACHE_DIR="D:\my-composer-cache" - CI/CD 环境（如 GitHub Actions）：在
env:下设该变量，避免每次拉取都重下 vendor
composer config --global cache-dir 只影响全局配置，不强制生效
这条命令会把缓存路径写进 ~/.composer/config.json 的 cache-dir 字段，但它的实际效果取决于有没有被环境变量或项目级配置覆盖。
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
典型误用场景：在 Docker 容器里执行了 composer config --global cache-dir /tmp/composer-cache，结果发现容器重启后配置丢了——因为 --global 写的是宿主机上的路径，而容器内根本没挂载那个位置。
- 仅当没有
COMPOSER_CACHE_DIR时才读这个配置 - 项目根目录下的
composer.json也能通过"config": {"cache-dir": "..."}设置，但只对当前项目生效 - 运行
composer config --list可以确认最终生效的缓存路径是哪个
缓存目录权限和磁盘空间容易被忽略
Composer 写缓存需要目标目录有可写权限，且不能放在 NFS 或某些网络文件系统上——部分操作（比如解压 zip 包）会失败，报错类似 failed to open stream: Permission denied 或 ziparchive::extractto(): failed to open stream。
- 推荐用本地 SSD 路径，避免跨网络存储
- 确保用户对目录有
rwx权限，尤其是 CI 环境常用非交互用户（如www-data、runner） - 定期清理：用
composer clear-cache，别依赖自动过期；大项目缓存可能轻松占几个 GB
多项目共享缓存要注意 hash 冲突风险
不同项目的 composer.lock 如果用了同一缓存目录，Composer 会按包名 + 版本 + dist URL 的 hash 存档，正常情况下不会混用。但如果你手动改过包源、用了私有仓库又没配好 dist-reference，或者用了 --prefer-source，就可能出现缓存错乱——比如 A 项目装的包，B 项目 install 时意外复用了。
- 企业级部署建议按团队/环境分缓存目录，比如
/cache/composer/prod和/cache/composer/dev - 私有 Packagist 服务必须保证 dist URL 唯一且稳定，否则缓存 key 会变
- 调试时可用
composer install -v看实际从哪加载缓存归档
