Composer权限问题根源是sudo运行导致文件属root，修复需将~/.composer和vendor目录所有权归还当前用户并禁用sudo调用。
Composer 权限问题通常是因为用 sudo 运行过 install/update，导致 vendor 目录或 ~/.composer 下的文件被 root 拥有，后续普通用户操作时被拒绝。修复核心是**把相关文件所有权还给当前用户**，并避免再用 sudo 调用 Composer。
检查并修正 ~/.composer 目录权限
Composer 的全局配置、缓存和全局安装包都存在 ~/.composer（如 /home/username/.composer）。如果该目录或其子目录属于 root，普通用户无法写入：
- 运行 ls -la ~/.composer 查看所有者，若显示 root:root，说明权限异常
- 执行 sudo chown -R $USER:$USER ~/.composer 归还所有权
- 补设合理权限：chmod -R u+rw ~/.composer（确保用户可读写）
修复项目级 vendor 目录权限
如果在某个项目中执行过 sudo composer install，vendor 及其内部文件可能属 root，导致后续 update 失败或 autoload 失效：
- 进入项目根目录，运行 ls -la vendor/ | head -3 快速确认所有者
- 执行 sudo chown -R $USER:$USER vendor/（注意：仅改 vendor，不要连带改整个项目）
- 不需要 chmod，只要 owner 正确，PHP 运行时就能正常加载
防止问题再次发生
Composer 官方明确不建议用 sudo 运行任何命令（除非安装到系统级 bin，且应使用官方推荐方式）：
- 卸载错误安装的全局包：sudo composer global remove xxx → 改为 composer global remove xxx
- 重装 Composer 时，用 curl -sS https://getcomposer.org/installer | php -- --filename=composer，再 mv composer /home/$USER/bin/（确保 $HOME/bin 在 PATH 中），全程不用 sudo
- CI/CD 或 systemd 服务中若需全局依赖，请用 --no-interaction 和指定 COMPOSER_HOME，而非提权运行
基本上就这些。关键是别让 root “碰” Composer 的数据目录，所有权归用户、路径在用户空间，问题就很少出现。
