90%的“Permission denied”源于属主为root而普通用户运行命令，应优先用chown归还所有权而非chmod 777；通过ls -ld检查报错路径的属主，确认非当前用户后执行sudo chown -R $USER:$USER修复。
直接结论：90% 的 “Permission denied” 不是权限位（rwx）不够，而是文件或目录的属主（owner）是 root，而你正以普通用户运行命令。修复方式只有一条路——用 chown 归还所有权，不是用 chmod 777 硬开后门。
看报错路径，立刻定位问题目录
错误信息里带完整路径的那一行就是线索，别被 “Permission denied” 四个字带偏。比如：
-
file_put_contents(/home/alex/myapp/vendor/autoload.php): Failed to open stream: Permission denied→ 问题在vendor/ -
Could not write to /var/www/myapp/composer.lock→ 问题在composer.lock -
Writing cache file ~/.composer/cache/repo/https---packagist.org/ failed→ 问题在全局缓存目录
立刻执行这三行命令确认归属：
ls -ld vendor/ ls -ld composer.lock ls -ld $(composer config --global cache-dir)
只要任意一行输出中第三列（属主）不是 $(whoami)（比如显示 root root），就坐实是所有权错配。
用 chown 修复，禁用 sudo composer install
chown 是解药，sudo composer install 是污染源。后者会让新生成的 vendor/ 全变成 root 所有，后续所有操作都可能卡住。
- 修复项目内目录：
sudo chown -R $USER:$USER vendor/ composer.lock - 修复全局缓存：
sudo chown -R $USER:$USER $(composer config --global cache-dir) - 整个
~/.composer都被 root 占了？直接重置：sudo chown -R $USER:$USER ~/.composer
sudo 这里仅用于临时提权执行 chown，不是让你去跑 sudo composer install——那等于把刚修好的又弄脏。
Windows 和 Docker 场景下的隐性坑
Windows 用户若用过管理员权限的 PowerShell/CMD 运行过 Composer，%APPDATA%\Composer 很可能已被锁死。最干脆的解法是删掉整个目录，再重装。
Docker 中常见现象是宿主机 UID=1000，容器却以 UID=0（root）运行，挂载卷后文件不可写。解决方法有两个：
- 启动容器时加
user:1000参数 - 或在
Dockerfile里加USER 1001（确保和宿主机 UID 一致）
如果 composer global require 报错，先查 composer config --global home；若输出是 /root/.composer 或 /var/www/.composer，说明环境已被污染，得手动清理并重建。
永远不要用 chmod -R 777
它看似能绕过报错，实则埋雷：
-
vendor/bin/phpunit这类可执行文件会被 CI 工具或安全扫描器直接拒收 - Git 提交时提示
ownership changed，后续composer update可能静默失败一半 - 某些框架（如 Laravel）的
storage/目录若被 777，Web 服务器读取时反而因安全策略被拦截
真正需要的是归属清晰、权限克制：目录用 755，文件用 644，可执行脚本单独 755。复杂点在于，很多问题不是单一目录出错，而是嵌套污染——比如 vendor/ 属主是当前用户，但里面某个子目录（如 vendor/symfony/console/bin/）却是 root，这种就得删掉 vendor/ 重来。
