Composer安装失败权限不足的根本原因是目录属主混乱，应通过chown修复vendor/、项目目录及全局缓存目录属主为当前用户，严禁使用sudo或777权限。
Composer 安装包失败并提示权限不足，通常不是 Composer 本身的问题，而是当前用户对 vendor/ 目录、composer.json 所在目录，或全局 ~/.composer/（或 ~/.config/composer/）没有写权限。直接用 sudo composer install 是最常见但最危险的解决方式——它会让 vendor/ 下文件属主变成 root，后续 Git 操作、CI 构建、甚至你自己的 composer update 都可能反复报错。
为什么 chmod -R 777 项目目录是错的
这会让所有文件可读可写可执行，破坏最小权限原则，且 Composer 自动生成的二进制脚本（如 vendor/bin/phpunit）可能因过度宽松被安全扫描工具拦截；更重要的是，它不解决根本问题——权限混乱往往源于混合使用了 sudo 和普通用户命令，导致目录属主不一致。
正确思路是：查清属主，归还控制权，再确保未来操作不越权。
- 运行
ls -ld . vendor composer.json，确认当前目录和vendor/的属主是否为你的普通用户（比如alex），而不是root - 若
vendor/属主是root，别急着chmod，先sudo chown -R $USER:$USER vendor/ -
composer.json所在目录也应属你，否则composer install会因无法创建vendor/失败
全局 Composer 缓存目录权限修复
Composer 默认把包缓存放在 ~/.composer/cache/（旧版）或 ~/.config/composer/cache/（新版）。如果曾用 sudo composer global require，缓存目录可能被设为 root 所有，之后普通用户执行任何 composer 命令都会卡在「Writing cache file」并报 Permission denied。
检查并修复：
- 运行
composer config --global cache-dir确认路径 - 执行
ls -ld $(composer config --global cache-dir)，若属主非当前用户，运行sudo chown -R $USER:$USER $(composer config --global cache-dir) - 顺手清理一次缓存：
composer clear-cache（此时应不再报错）
避免下次再出问题的操作习惯
Composer 设计上就不该用 sudo。几乎所有报权限错的场景，都源于某次误用了 sudo composer ...。
- 永远用普通用户运行
composer install、composer update、composer require - 全局安装（如
phpunit或larastan）也应避免sudo；如遇「Permission denied」，说明~/.composer/vendor/bin不在$PATH，或该目录权限不对——修复路径或运行chown -R $USER:$USER ~/.composer - 如果项目在 Docker 或 CI 中运行，确保容器内运行用户 UID 与宿主机一致，或挂载卷时用
user:指定 UID
真正麻烦的从来不是改一次权限，而是目录属主混杂后，git status 突然显示一堆权限变更（chmod 600 → 644），或者部署脚本在某个环节静默失败。每次看到 Permission denied，第一反应不该是加 sudo 或调 chmod，而是 ls -l 看一眼属主。
