答案是COMPOSER_CACHE_DIR临时设置不生效的主因是验证方式错误，真正可信的是composer diag中“Cache directory”行；必须确保路径存在、有读写权限且不含空格或中文，临时使用应直接前缀命令如COMPOSER_CACHE_DIR="/tmp/composer-cache" composer install --no-cache。
COMPOSER_CACHE_DIR 临时设置后不生效？验证方式错了
不是环境变量没设对，而是你只看了 composer config cache-dir 的输出——它根本不反映真实路径。真正可信的验证是运行 composer diag，看 “Cache directory” 那一行。如果显示 Cache is not working due to permissions，说明目录存在但不可写，Composer 已悄悄 fallback 到默认位置（~/.composer/cache）。
临时设置必须满足三个条件才起作用：
-
COMPOSER_CACHE_DIR路径必须已存在（mkdir -p $PATH不可省） - 当前用户对该路径有读写权限（
ls -ld $PATH确认 owner/group） - 路径不能含空格或中文（否则静默失败，fallback 到默认路径）
Linux/macOS 下临时改缓存路径的正确命令
别用 export COMPOSER_CACHE_DIR=... 再执行 composer install —— 这在某些 shell 或 CI 环境里会因子进程继承问题失效。最可靠的是直接在命令前拼接：
COMPOSER_CACHE_DIR="/tmp/composer-cache" composer install --no-cache
注意两点：
-
--no-cache是保险策略：即使COMPOSER_CACHE_DIR指向不可写路径，也不会 fallback 失败，而是跳过缓存直接下载 -
/tmp/在大多数 Linux/macOS 系统中默认可写，且重启后自动清理，适合 CI 场景
为什么 composer clear-cache 对权限问题完全无效？
这个命令只清内容，不修权限。如果缓存目录属主是 root（比如之前误用 sudo composer install），那 clear-cache 后新建的 files/、repo/ 子目录依然属于 root，普通用户还是写不进去。
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
必须手动修复归属：
- 先查真实缓存路径：
composer diag | grep "Cache directory" - 再改属主：
sudo chown -R $USER:$USER /path/to/cache（注意-R，否则只改目录本身） - 如果路径是
/tmp/composer-cache，通常不用改——但得确认ls -ld /tmp/composer-cache中 owner 是当前用户
Docker 或 CI 中 COMPOSER_CACHE_DIR 设了却仍报错？检查 UID 是否一致
容器内 whoami 显示 runner，但 ls -ld $(composer config --global cache-dir) 显示 owner 是 root，大概率是挂载卷时 UID 错位。Docker 默认以 root 启动，而 CI runner 用户 UID 可能是 1001。
此时 chown -R $USER 会失效（因为容器里没有同名用户）。正确做法是：
- 用数字 UID 操作：
sudo chown -R 1001:1001 /path/to/cache - 或启动容器时指定用户：
docker run -u 1001:1001 ... - CI 脚本里提前创建缓存目录并授权：
mkdir -p .composer-cache && chmod 700 .composer-cache，再设COMPOSER_CACHE_DIR="$PWD/.composer-cache"
最容易被忽略的是：错误信息里写的“Permission denied”路径，往往不是 vendor/，而是 ~/.composer/cache/files/xxx.zip 这类临时解压路径——它比 vendor/ 更早触发权限校验，也更难定位。
