结论是权限错配而非权限不足，根本原因是当前用户对vendor/、composer.lock或~/.composer/cache无写权限，多因误用sudo导致属主为root，应通过检查归属、删重装或换缓存路径修复。
直接说结论：不是 Composer 有问题，是你当前用户对 vendor/、composer.lock 或 ~/.composer/cache/ 没有写权限。别用 sudo composer install，它只会让问题更糟。
报 mkdir(): Permission denied 是哪个目录在拦你？
错误信息末尾一定带了路径，比如 mkdir(): Permission denied in /path/to/vendor/autoload.php —— 这说明 vendor/ 目录不可写；又或者提示写入 ~/.composer/cache/repo/... 失败，那就是缓存目录归属错了。
- 立刻检查三处：
ls -ld vendor/、ls -ld composer.lock、ls -ld $(composer config --global cache-dir) - 只要任一输出里 owner 不是你的用户名（
$(whoami)），就是所有权错位，不是权限数字太小，是“东西不归你” - 别只看权限数字（如
drwxr-xr-x），重点看第二列的 owner 名字
vendor/ 和 composer.lock 归 root 了，怎么救？
误用 sudo composer install 后，vendor/ 下所有子目录和文件大概率属主为 root，手动 chown 容易漏掉深层嵌套项，还可能破坏 Phar 内部权限。最干净的做法是清空重来。
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 执行
rm -rf vendor/ composer.lock（确认你没改过 lock 文件，或已 commit） - 再运行
composer install，确保当前用户对项目根目录有写权限：chmod u+rwx . - 如果不能删
composer.lock（如生产部署），至少修复vendor/目录本身：sudo chown $USER:$USER vendor，再补写权限：chmod u+w vendor
~/.composer/cache/ 权限乱了，换路径比硬修更稳
缓存目录权限出问题，会导致所有命令卡在「写缓存失败」，哪怕 vendor/ 没事也照样报错。常见于首次用 sudo 安装 Composer 或全局 require 后残留的污染。
- 查当前路径：
composer config --global cache-dir - 推荐换到用户可控路径：
composer config --global cache-dir "$HOME/.cache/composer" - 然后创建并赋权：
mkdir -p ~/.cache/composer && chown $USER:$USER ~/.cache/composer - 如果整个
~/.composer都属 root，才用：sudo chown -R $USER:$USER ~/.composer，之后顺手加固：chmod -R u+rw ~/.composer
vendor/bin/ 脚本执行报 Permission denied
这不是目录权限问题，是脚本文件缺 x 执行位。Composer 生成的 vendor/bin/phpunit 等文件，在 Git 提交或 Windows 打包时容易丢失可执行属性。
- 临时修复：
chmod -f +x vendor/bin/*（-f忽略无权修改的文件） - 一劳永逸：在
composer.json的scripts里加："post-install-cmd": "chmod -f +x vendor/bin/*" - 某些共享主机禁用
chmod系统调用，就得用 PHP 原生方式：php -r "foreach(glob('vendor/bin/*') as \$f) chmod(\$f, 0755);"
最容易被忽略的是 $HOME 环境变量本身——CI 或容器镜像中即使你 su - myuser，$HOME 仍可能指向 /root，结果 Composer 读取了 /root/.composer/ 配置，而你却在修自己的家目录。
