90%的“Permission denied”是目录属主非当前用户所致，应定位报错路径→用ls -ld查归属→执行sudo chown -R $USER:$USER精准修复vendor/、composer.lock或缓存目录，禁用sudo composer install。
Composer install 插件时不需要、也不应该“申请更高权限”。报错提示 Permission denied，90% 是目录属主（owner）不是当前用户，而不是权限位（rwx）不够——sudo composer install 不是解法，而是问题放大器。
为什么 sudo composer install 会把事情搞砸
它会让 vendor/、composer.lock、缓存目录全变成 root 所有。后续你用普通用户执行 composer update 或运行 PHP 脚本时，会遇到一半成功一半失败的诡异状态；连 chown -R 都可能漏掉嵌套子目录。
-
vendor/bin/phpunit变成 root 所有后，CI 工具常直接拒绝执行 -
~/.composer/cache/被设为 root，下次composer require就卡在写缓存 - Git 提交时提示 “ownership changed”，干扰 diff 和审查
真正该修的是谁 owns 这些路径
错误信息里一定带具体路径，比如：file_put_contents(/home/alex/myapp/vendor/autoload.php) 或 Writing cache file ~/.composer/cache/repo/https---packagist.org/。立刻查归属：
-
ls -ld vendor/—— 第三列不是$(whoami)？就是它了 -
ls -ld composer.lock—— 同样检查 -
ls -ld $(composer config --global cache-dir)—— 全局缓存也得看，尤其 CI 环境
精准修复：只对必要路径 chown，不碰 chmod
修复必须分范围，不能一刀切：
- 项目内问题：
sudo chown -R $USER:$USER vendor/ composer.lock（注意vendor/末尾斜杠，否则可能漏子目录） - 全局缓存被占：
sudo chown -R $USER:$USER $(composer config --global cache-dir) - 整个
~/.composer都属 root：sudo chown -R $USER:$USER ~/.composer，再加固：chmod -R u+rw ~/.composer
复杂点在于：Web 服务器（如 www-data）和 CLI 用户不一致时，storage/ 或 bootstrap/cache 需要组写权限，但 vendor/ 不需要——混着修容易开后门，得分开处理。
