唯一安全可复现的解法是直接修改目录权限而非用 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 都不可写 —— 此时要一并修复该目录权限，否则换项目也还会出问题。

# php  # linux  # laravel  # js  # json  # docker  # composer  # windows  # app  # mac  # ai  # symfony  # 递归  # macos  # unix  # 文件系统  # 这是  # 也不  # 也会  # 不需要  # 还会  # 可在  # 会把  # 不能用