根本不用sudo，问题八成出在~/.composer或项目目录归属错乱；检查ls -ld ~/.composer和项目根目录，若owner或group为root，立即执行sudo chown -R $(whoami):$(whoami) ~/.composer ./并chmod -R u+rw ~/.composer。
根本不用 sudo，问题八成出在 ~/.composer 或项目目录归属错乱。
检查 ~/.composer 所有权是否被 sudo 污染
macOS 上 Composer 全局行为（composer global require、缓存、插件）全依赖 ~/.composer 目录。只要它属主不是你，后续所有命令都可能卡在 Permission denied。
- 运行
ls -ld ~/.composer—— 如果输出里第三列（group）或第二列（owner）是root，就是它了 - 立刻修复：
sudo chown -R $(whoami):$(whoami) ~/.composer - 顺手加固写权限：
chmod -R u+rw ~/.composer（避免 umask 导致子目录不可写） - 如果已改过全局缓存路径（如设为
~/.cache/composer），同样要检查并修复那个目录：ls -ld ~/.cache/composer→sudo chown -R $(whoami):$(whoami) ~/.cache/composer
项目目录 vendor/ 或 composer.lock 权限异常
常见于用 sudo git clone、sudo composer create-project 后遗留的 root 所有文件，导致普通用户无法更新或重装依赖。
- 进项目根目录，运行
ls -ld . vendor/ composer.lock - 若任一显示
root为 owner，执行：sudo chown -R $(whoami):$(whoami) ./（注意结尾的./，别漏） - 不建议单独修
vendor/：万一composer.lock是 root 写的，下次composer update还会失败 - 修完立刻验证：
composer install应该能跑通；如果还报mkdir(): Permission denied，说明路径没彻底交还给你
Mac 用户特别注意：WSL 风格挂载或 /Volumes 下项目
macOS 本身没有 WSL，但如果你通过 Parallels、VMware 或外接 NTFS 硬盘（如用 ntfs-3g 挂载）把项目放在非 APFS/HFS+ 分区，Composer 创建 vendor/ 时可能因文件系统不支持 Unix 权限而失败。
- 先确认位置：
pwd输出是否含/Volumes/、/private/tmp或虚拟机共享路径 - 最稳解法：把项目移到本地磁盘（如
~/Sites/myapp），再运行composer install - 临时测试：在项目目录运行
touch test-perm && rm test-perm—— 若失败，说明底层文件系统不支持常规权限模型，Composer 必然出问题
别碰 chmod 777，也别用 sudo composer install
这两个操作看似“快”，实则埋雷：前者让 CI/CD 构建失败、Git 提交混乱；后者让 vendor/ 下所有文件变成 root 所有，Web 服务器（PHP-FPM）以 _www 身份运行时直接拒绝加载 autoload。
- 永远用普通用户执行：
composer install、composer update、composer global require - 如果曾误用
sudo composer install，请先清理：sudo rm -rf vendor composer.lock，再用普通用户重来 - 全局工具（如
laravel/installer）装完后，二进制文件默认在~/.composer/vendor/bin，记得把它加进$PATH（如在~/.zshrc加export PATH="$HOME/.composer/vendor/bin:$PATH"）
真正麻烦的不是权限本身，而是错误归属扩散后难以定位——比如 composer install 失败，实际根源可能是 ~/.composer/cache/ 下某个包解压失败，而这个 cache 目录早在三个月前就被一次 sudo composer global update 污染了。每次只修表象，不如一次性扫清所有 ~/.composer 和项目根目录的归属。
