先运行composer config --global cache-dir查清实际缓存路径，再通过composer diag | grep "cache directory"验证最终生效路径，确保目录存在、属主为当前用户（linux/macos用chown -r $user:$user，windows用acl授“完全控制”），而非盲目改权限或猜路径。
查清当前 cache 目录在哪，再动手
别猜，先确认 Composer 实际用的是哪个缓存路径：composer config --global cache-dir。输出通常是 ~/.composer/cache（Linux/macOS）或 %APPDATA%\Roaming\Composer\Cache（Windows）。这个路径必须是绝对路径，~ 在配置里不被解析，也不能写成相对路径。
90% 的问题不是 chmod 不够，而是 owner 错了
运行 composer install 卡在 Writing cache file 或报 Permission denied，大概率是目录属主为 root（比如之前误用了 sudo composer install），而不是权限位（如 755）不够。
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 执行
ls -ld $(composer config --global cache-dir)，看第三列是不是当前用户（$(whoami)） - 如果是
root root，就该修所有权，不是改权限 - 安全做法：先删旧目录
rm -rf $(composer config --global cache-dir)，再重建并归还控制权：mkdir -p $(composer config --global cache-dir) && sudo chown -R $USER:$USER $(composer config --global cache-dir) - 最后设合理权限：
chmod 755 $(composer config --global cache-dir)（不是 777）
Windows 下 ACL 比 chmod 更关键
在 Windows 上，即使目录归属是你自己，也可能因 ACL（访问控制列表）缺失“完全控制”而失败。图形方式最稳：
- 右键
%APPDATA%\Roaming\Composer\Cache→ 属性 → 安全 → 编辑 → 添加当前用户名 → 勾选“完全控制” - 命令行（管理员 PowerShell）：
icacls "$env:APPDATA\Roaming\Composer\Cache" /grant "$env:USERNAME:(OI)(CI)F" /t - 更省事的长期方案：
composer config -g cache-dir "%USERPROFILE%\composer-cache"，然后mkdir "%USERPROFILE%\composer-cache"—— 这个路径天然属于你，ACL 默认放行
Docker/CI 场景下，别依赖默认路径
容器里用 root 启动但挂载宿主机目录（如 -v ~/.composer/cache:/root/.composer/cache），容易因 UID/GID 不匹配导致静默 fallback 到默认缓存，根本没生效。
- 显式指定缓存路径：
COMPOSER_CACHE_DIR="/tmp/composer-cache" composer install - 提前创建并授权：
mkdir -p /tmp/composer-cache && chmod 755 /tmp/composer-cache - 验证是否真生效：
composer diag | grep "Cache directory"，再ls -lh看目录里有没有新生成的文件
composer diag 输出的那行 Cache directory: —— 它反映的是最终生效路径，不是你配置了什么，而是系统实际用了什么。路径对了，owner 对了，ACL 或 umask 也对了，cache 才算真正可写。
