唯一安全可复现的解法是直接修改目录权限而非用 sudo composer；因sudo会导致vendor/等文件属主为root，引发后续Permission denied、Operation not permitted等错误，须用chown -R $(whoami)修复所有权。
直接改目录权限，别用 sudo composer —— 这是唯一安全、可复现的解法。
为什么不能用 sudo composer install
Composer 会把 vendor/ 下所有文件、缓存、脚本都以 root 身份创建，后续普通用户无法修改或更新；composer.lock 时间戳、vendor/bin 软链接权限也会错乱；某些包（如 laravel/installer）的 post-install 脚本在 root 下执行可能写入系统路径，污染环境。
- 现象：之后运行
composer update报Permission denied: vendor/autoload.php - 现象：
vendor/bin/phpunit执行时报Operation not permitted（macOS 上尤其常见） - 现象：
composer dump-autoload失败，提示file_put_contents(): failed to open stream: Permission denied
正确修复目录写入权限（Linux/macOS）
核心原则：让当前用户拥有项目根目录及子目录的完整控制权，不依赖 sudo，也不盲目 chmod 777。
- 确认当前用户名：
whoami - 确认项目路径，比如是
/home/alice/myproject或/Users/bob/code/myproject - 递归重设所有权（推荐）：
chown -R $(whoami):$(whoami) /path/to/myproject
- 若需兼容某些共享环境（如 Docker 挂载），可仅修复关键目录：
chown -R $(whoami):$(whoami) /path/to/myproject/{vendor,composer.lock,composer.json} - 避免
chmod -R 755或777：PHP 脚本不需要执行权限，且开放写权限会引发安全警告（如 Symfony 的cache目录被扫描到可写时会报 warning）
Windows 上 Composer 权限异常的典型场景
不是 Unix 权限问题，而是 Windows ACL 或 WSL 与宿主机文件系统交互导致。常见于使用 WSL2 + Windows 文件系统挂载（/mnt/c/...）。
- 错误现象：
mkdir(): Permission denied在vendor/创建时抛出 - 根本原因：WSL2 对
/mnt/c/下目录默认禁用 metadata（即不支持 Linux 权限位），Composer 内部调用mkdir会失败 - 解决方式：把项目移到 WSL2 原生文件系统，例如
~/projects/myapp，再运行composer install - 如果必须用 Windows 路径，可在
/etc/wsl.conf中启用 metadata：[automount] options = "metadata,uid=1000,gid=1000,umask=22,fmask=11"
，然后重启 WSL（wsl --shutdown）
最常被忽略的一点：Composer 自身的全局配置目录（~/.composer 或 %APPDATA%\Composer）如果也被 sudo 污染过，会导致所有项目缓存、插件、auth.json 都不可写 —— 此时要一并修复该目录权限，否则换项目也还会出问题。
