先确认当前用户归属，再用ls -ld检查composer config --global cache-dir返回路径的属主，若为root则执行sudo chown -R $USER:$USER修复，并推荐迁移到~/composer-cache等用户可控路径。
composer config --global cache-dir 返回的路径权限不对
运行 composer config --global cache-dir 查出来的路径（通常是 ~/.composer/cache 或 ~/.cache/composer），如果 ls -ld 显示 owner 不是当前用户，后续所有 composer install、composer update 都会卡在「failed to write」——哪怕 vendor 目录本身没问题，缓存写不进去也会连带失败。
修复要点：
- 先确认当前用户：
whoami - 查缓存目录归属：
ls -ld $(composer config --global cache-dir) - 若 owner 是
root，执行：sudo chown -R $USER:$USER $(composer config --global cache-dir) - 别只改 cache 目录，顺手修一下整个全局配置目录：
sudo chown -R $USER:$USER ~/.composer（Windows WSL 用户还要注意%APPDATA%\Composer是否被 sudo 污染过）
缓存目录被设为只读或 umask 导致子目录无写权限
即使缓存目录 owner 正确，chmod 权限也可能不够。Composer 解压包时会在 cache 下建多层 hash 子目录，若父目录权限是 755 但 umask 是 022，某些临时目录可能生成为 755 而非 775，导致后续写入失败。
更稳妥的做法是换一个干净、完全可控的缓存路径：
- 新建专属缓存目录：
mkdir -p ~/composer-cache - 赋权：
chown $USER:$USER ~/composer-cache && chmod 755 ~/composer-cache - 切换缓存位置：
composer config --global cache-dir ~/composer-cache - 清旧缓存：
composer clear-cache（此时会清掉原路径，新路径自动生效）
WSL 或 Docker 中 cache-dir 修复后仍报 Permission denied
在 WSL（尤其是挂载 Windows 文件系统如 /mnt/c/）或 Docker bind mount 场景下，Linux 权限模型失效是常见原因。此时改 cache-dir 或 chown 都无效，因为底层文件系统不支持 metadata。
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
必须从环境层面解决：
- WSL：把项目移到
~/projects/myapp这类原生 Linux 路径，再运行composer install - WSL 必须用 Windows 路径？编辑
/etc/wsl.conf，加入：[automount] options = "metadata,uid=1000,gid=1000,umask=22,fmask=11"
然后执行wsl --shutdown重启 - Docker：不要在宿主机跑
composer install后挂载vendor/进容器；应在Dockerfile中COPY composer.json . && RUN composer install
为什么 clear-cache 后还是 Permission denied
composer clear-cache 只清内容，不改权限。如果缓存目录本身属主仍是 root，清完立刻重试照样失败。
最容易被忽略的一点是：错误里提示的「failed to write …/cache/xxx」路径，往往不是你正在看的那个目录，而是 Composer 内部某个临时子路径（比如 cache/repo/https---packagist.org/provider-xxx$xx.json）。它出错的真实原因是其父目录（甚至祖父目录）权限继承异常，或者该路径被上一次 sudo composer 创建过。
所以别盯着报错路径硬 chmod，先用 ls -ld $(dirname "报错路径") 一级级往上查 owner 和权限，直到找到第一个非当前用户拥有的目录——那里才是根因。
