90%的“Permission denied”是因目录属主为root而非当前用户，需用ls -ld定位vendor/、composer.lock或缓存路径归属，再执行sudo chown -R $USER:$USER修复，禁用chmod -R 777。
为什么composer install报Permission denied
90% 的报错不是因为权限位（rwx）不够，而是目录或文件的属主（owner）是 root 或其他用户，不是当前执行命令的人。操作系统拒绝写入，本质是“这目录不归你管”，不是“你不被允许写”。
典型错误信息里一定带路径，直接锁定问题位置：
-
file_put_contents(/path/to/vendor/autoload.php): Permission denied→ 问题在vendor/ -
Could not write to /path/to/composer.lock→ 问题在composer.lock -
Writing cache file ~/.composer/cache/...→ 问题在全局缓存目录
怎么确认是不是所有权问题
别猜，用 ls -ld 看第三列（属主）是不是你的用户名：
ls -ld vendor/ls -ld composer.lockls -ld $(composer config --global cache-dir)
只要任意一行输出第三列不是 $(whoami)（比如显示 root root 或 www-data www-data），就坐实了所有权错配。注意：ls -ld 输出第一列是权限位，第三列才是属主——别看串行。
修复必须用chown，禁用chmod -R 777
chown 是归还控制权，chmod -R 777 是敞开大门——后者会触发 CI 拒收 vendor/bin/ 下的可执行文件、Git 提示 ownership changed、后续 composer update 可能只失败一半。
正确操作分范围处理：
- 项目内问题：
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，再补一句chmod -R u+rw ~/.composer防 umask 导致子目录不可写
绝对不要 sudo composer install —— 它是污染源头，会让新生成的所有文件都变成 root 所有，后续普通用户几乎无法收拾。
Docker / CI / Windows 下的隐性坑
这些环境不总报明显错误，但一样卡住：
- Docker：宿主机 UID 是 1000，容器却以 UID 0（
root）运行，挂载进来的vendor/属主变成root→ 启动时加user:1000，或修复时用数字 UID：sudo chown -R 1000:1000 ~/.composer - Windows：报
Access is denied且路径含%APPDATA%\Roaming\Composer\Cache→ 用 PowerShell 运行：icacls "$env:APPDATA\Roaming\Composer\Cache" /grant "$env:USERNAME:(OI)(CI)F" /t - CI 场景中，
composer config --global cache-dir常被忽略，缓存目录实际落在不可写路径 → 提前设COMPOSER_CACHE_DIR="$PWD/.composer-cache"并mkdir -p .composer-cache && chmod 700 .composer-cache
最常被跳过的一步是查全局缓存归属——哪怕 vendor/ 和 composer.lock 都正常，cache-dir 归属错也会让 install 卡在下载后写缓存阶段，报错却不明显。
