95%的Composer权限问题是属主错位，应先用ls -ld定位vendor/、composer.lock或全局缓存目录的owner，再执行sudo chown -R $USER:$USER修复归属，禁用sudo composer install和chmod 777。
别用 sudo composer install，也别给 vendor/ 设 777——95% 的权限问题其实是属主错位，不是权限数字不够大；Composer 本身不控制权限，真正起作用的是你运行命令时的用户、umask 和文件系统行为。
怎么快速定位权限报错在哪
终端报错里写的路径就是真相。比如 file_put_contents(/home/alex/myapp/vendor/autoload.php): Failed to open stream: Permission denied，问题就在 vendor/；如果是 Writing cache file ~/.composer/cache/repo/https---packagist.org/ 失败，那得查全局缓存目录。
三处必须立刻检查：
-
ls -ld vendor/—— 看属主是不是当前用户（$(whoami)），不是root或www-data -
ls -ld composer.lock—— 这个文件常被sudo创建后变成只读且属root -
ls -ld $(composer config --global cache-dir)—— 默认是~/.composer/cache或~/.cache/composer，90% 的“缓存写入失败”出在这儿
修复权限该用 chown 还是 chmod
绝大多数情况该用 chown：它改的是“谁拥有”，而 chmod -R 777 vendor/ 是放任所有用户可写，等于把后门焊死在服务器上。
正确操作（复制即用）：
- 修项目内：
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 700 ~/.composer，chmod 600 ~/.composer/auth.json
如何防止下次再被 root 污染
根本解法是让 Composer 永远不以高权限身份启动：
- Docker 构建时，在
Dockerfile中加RUN umask 0022 && composer install --no-dev --optimize-autoloader - CI 脚本里禁用
sudo composer install，改用非特权用户 + 显式umask 0022 - 本地开发机上，确认
umask输出是0022（不是0002或0007） - Windows WSL 用户注意：
/mnt/挂载的 NTFS 盘默认不支持chmod，需在/etc/wsl.conf启用metadata
vendor 目录权限设成多少才安全
文件统一 644，目录统一 755 是通用底线；若生产环境需多用户协作（如 CLI 用户和 PHP-FPM 用户不同但同属一个组），可改用 664/775，但绝不能跳过组权限校验。
安装后必须手动加固（尤其当某些包自带 post-install-cmd）：
- 禁止写入：
find vendor/ -type f -exec chmod 644 {} \; - 仅目录可执行：
find vendor/ -type d -exec chmod 755 {} \; - 单独处理
vendor/bin/：chmod 755 vendor/bin/*（脚本需可执行，但不应可写） - 确认
vendor/composer/installed.json是644，不是666
Web 服务器能否直接读 vendor/？不能。PHP-FPM 若以 www-data 身份运行，而部署用户是 deploy，就得把 www-data 加入 deploy 所在组，再跑 chmod -R g+rX vendor/——而不是放宽到 775 或更糟。
