应避免sudo安装Composer，改用用户级安装：下载composer.phar至~/bin/并加入PATH，chmod +x赋权；vendor权限错误时用chown -R修复属主，勿混用sudo与非sudo命令。
Composer全局安装提示 Permission denied 怎么办
根本原因不是 Composer 本身有问题，而是它试图往系统级目录（比如 /usr/local/bin）写文件，而当前用户没权限。Linux 默认不允许普通用户直接向这些路径写入可执行文件。
最稳妥的做法是避开系统目录，改用用户级安装：
- 运行
curl -sS https://getcomposer.org/installer | php把composer.phar下载到当前目录 - 执行
mv composer.phar ~/bin/composer（确保~/bin在$PATH中；没有就先mkdir -p ~/bin并在~/.bashrc或~/.zshrc里加export PATH="$HOME/bin:$PATH"） - 给文件加执行权限：
chmod +x ~/bin/composer
别用 sudo composer install 或 sudo curl ... | sudo php —— 这会让后续所有依赖包也以 root 身份写入，项目里再跑 composer update 可能报 Could not write to /path/to/vendor。
本地项目里 composer install 报 vendor/ permission denied
常见于用 sudo composer install 初始化过一次，导致 vendor/ 目录属主变成 root，之后普通用户就无法修改。
直接修复权限比重装更省事：
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 先确认当前用户：运行
whoami，假设输出是alice - 递归改属主：
sudo chown -R alice:alice vendor/ - 如果还报错，再补一句：
chmod -R u+rw vendor/
注意：不要对整个项目根目录跑 chown -R，尤其当项目含 .env、storage/ 等敏感目录时，可能破坏原有权限策略。
为什么不用 sudo composer global require
因为 global 命令默认把包装进 ~/.composer/vendor/bin/，但这个路径往往不在 $PATH 里；强行加 sudo 会导致二进制文件属主为 root，下次执行会卡在「permission denied」或「command not found」。
正确姿势是：
- 确保
~/.composer/vendor/bin/已加入$PATH（检查echo $PATH是否含该路径） - 去掉
sudo，直接运行composer global require laravel/installer - 验证是否生效：
laravel --version
如果提示 command not found，八成是 ~/.composer/vendor/bin/ 没进 $PATH，而不是 Composer 安装失败。
真正麻烦的不是权限报错本身，而是错误操作留下的“权限污染”——比如混用 sudo 和非 sudo 命令，让 vendor/、composer.phar、~/.composer/ 几个关键位置属主不一致。修一次权限容易，但得想清楚每个目录本该属于谁。
