根本原因是缓存目录被root占用，应先用ls -ld确认归属，再sudo chown -r $user:$user修复属主，而非chmod 777；优先排查cache-dir路径，因其写入失败会导致vendor等连带报错。
直接结论：不是缓存目录“没权限”，而是它被 root 占了——chown -R $USER:$USER 修复属主，比 chmod 777 或 sudo composer install 安全、彻底、可复现。
cache-dir 路径归属错乱是根本原因
Composer 报 failed to write 或卡在 Writing cache file，90% 是因为 composer config --global cache-dir 返回的路径（如 ~/.cache/composer 或 ~/.composer/cache）属主是 root，而非当前用户。哪怕你只用过一次 sudo composer global require，这个目录就会被污染。
验证方式：
- 运行
composer config --global cache-dir确认路径 - 执行
ls -ld $(composer config --global cache-dir)，看输出第三列是否为你的用户名 - 若显示
root root，问题就在这里
修复缓存目录权限的正确操作顺序
别跳步，顺序错了会残留问题：
- 先清掉旧缓存：
composer clear-cache（此时若仍报错，说明路径确实不可写） - 再修正属主：
sudo chown -R $USER:$USER $(composer config --global cache-dir) - 顺手修整个全局配置目录：
sudo chown -R $USER:$USER ~/.composer（新版可能在~/.config/composer，同样检查） - 最后再跑一次
composer clear-cache，确认无报错
为什么推荐迁移到 ~/composer-cache
默认路径（如 ~/.cache/composer）在某些系统或 WSL 配置下容易被其他工具干扰；更关键的是，它和系统级缓存混在一起，权限策略不透明。
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
新建专属路径更可控：
- 创建目录：
mkdir -p ~/composer-cache - 赋权：
chown $USER:$USER ~/composer-cache && chmod 755 ~/composer-cache - 切换路径：
composer config --global cache-dir ~/composer-cache - 迁移后旧缓存自动失效，无需手动清理
注意：WSL 中若项目仍在 /mnt/c/ 下，改 cache-dir 也无效——必须把项目移到 WSL 原生文件系统（如 ~/projects），否则底层不支持 metadata。
vendor 目录写入失败？往往只是缓存问题的连带现象
很多人看到 file_put_contents(): failed to open stream: Permission denied 就去修 vendor/，其实 Composer 在解包前必须先写缓存。缓存写不进，后续所有步骤都会中断。
所以优先排查缓存路径，而不是一上来就 chown -R $USER:$USER vendor/。只有当缓存路径修复后仍报错，再按以下顺序检查：
- 确认
composer.json所在目录可写：touch test && rm test - 检查
vendor/是否已存在且属主为root（误用sudo composer install后常见） - 若存在，删掉
vendor/和composer.lock，再用普通用户重装
最常被忽略的一点：全局配置目录（~/.composer 或 %APPDATA%\Composer）一旦被 sudo 污染，所有项目都会受影响——它不像 vendor/ 可以单个项目修复，必须统一处理。
