composer_cache_dir是唯一真正生效的临时缓存路径方式，优先级最高、进程退出即失效，且必须用绝对路径并确保当前用户有读写权限，否则静默回退默认路径。
COMPOSER_CACHE_DIR 是唯一真正生效的临时缓存路径方式
命令行加 --cache-dir 会直接报错：Unknown option cache-dir；composer config cache-dir 只读不写，composer config --global cache-dir 是永久修改，不是临时方案。真正能“这次 install 换个缓存位置、下次自动恢复”的，只有环境变量 COMPOSER_CACHE_DIR ——它优先级最高，不改任何配置文件，进程退出即失效。
设置 COMPOSER_CACHE_DIR 的实操要点
必须用绝对路径，且当前用户对该路径有读写权限；目录不存在时 Composer 不报错，而是静默 fallback 到默认缓存位置（比如 ~/.composer/cache），导致你以为设成功了，其实没写进去。
- Linux/macOS：运行
export COMPOSER_CACHE_DIR="/tmp/composer-cache"，再执行mkdir -p "/tmp/composer-cache"并确认权限（ls -ld /tmp/composer-cache） - Windows CMD：运行
set COMPOSER_CACHE_DIR=C:\cache\composer，然后手动创建该目录并检查当前用户是否有写入权 - 验证是否真生效：运行
composer diag，看输出中Cache directory:行是否匹配你设的路径——这是唯一可信依据
CI/Docker 场景下最容易漏掉的三件事
在 CI 脚本或 Dockerfile 中设了 COMPOSER_CACHE_DIR 却仍写入 /root/.composer/cache，大概率是以下某个环节出问题：
- 没提前
mkdir -p目录，尤其在 alpine 或最小化镜像里，/tmp 可能被清理或不可写 - 容器以 root 运行但目标路径属主是其他用户（如
/data/cache属于 www-data），导致权限拒绝 - 脚本里用了
su -c或gosu切换用户，但环境变量没透传过去（例如su -l www-data -c "composer install"会丢掉父 shell 的COMPOSER_CACHE_DIR）
clear-cache 命令和 COMPOSER_CACHE_DIR 的关系
composer clear-cache 只清 COMPOSER_CACHE_DIR 当前指向的路径，不会扫默认位置，也不会清全局配置里的 cache-dir。所以你在 CI 里设了临时缓存目录，跑完 composer clear-cache 就只清那一个目录，干净利落。
真正容易被忽略的是：即使 composer diag 显示路径正确，也得进磁盘确认文件是否真写进去了——因为权限或路径合法性失败时，Composer 既不报错也不提示，只默默退回去用默认位置。
