答案是检查并修正目录权限。首先确认 composer 缓存目录（~/.composer）归属当前用户，使用 chown 和 chmod 修复权限；避免用 sudo 执行 Composer 命令，确保项目目录权限正确；若全局安装失败，调整 ~/.config/composer 或全局 bin 目录权限，或自定义 bin 路径至用户可写目录，确保所有相关目录可读写。
当使用 Composer 时遇到 permission denied 错误，通常是因为当前用户没有足够的权限访问相关目录或文件。这类问题多出现在全局安装包、写入缓存目录或修改项目依赖时。下面是一些常见原因和对应的解决方法。
检查 Composer 缓存目录权限
Composer 默认会将下载的包缓存到用户主目录下的 .composer 目录（如：~/.composer）。如果该目录归属其他用户或权限设置不当，就会导致权限拒绝。
可以运行以下命令查看缓存路径：
composer config –global cache-dir
确认目录存在且当前用户有读写权限。如果没有，可执行：
sudo chown -R $(whoami) ~/.composer chmod -R u+rwx ~/.composer
避免使用 sudo 执行 Composer
不要用 sudo composer install 或 sudo composer require 等命令，除非你明确知道在做什么。这会导致生成的文件归 root 所有，后续操作会因权限问题失败。
正确的做法是确保项目目录归属于当前用户：
sudo chown -R $(whoami) /path/to/your/project
然后再以普通用户身份运行 Composer 命令。
全局 bin 目录权限问题
当你运行 composer global require 安装工具（如 laravel/installer）时，Composer 会尝试将可执行文件软链接到全局 bin 目录（通常是 ~/.config/composer/vendor/bin 或 ~/.composer/vendor/bin）。
若该目录不可写，会出现 permission denied。
解决方案是更改全局 vendor/bin 的归属：
sudo chown -R $(whoami) ~/.config/composer
或者重新定义全局 bin 路径为用户可写的目录：
composer config –global bin-dir ~/.bin –absolute
使用正确的用户运行命令
在服务器或 docker 环境中，可能当前 shell 用户不是预期的文件操作用户。例如，在部署脚本中切换了用户但未正确设置 HOME 或权限。
确保你在正确的用户上下文中执行 Composer。可通过以下命令确认：
whoami echo $HOME
并确保 Composer 配置目录（~/.composer）与当前用户匹配。
基本上就这些。只要保证当前用户对项目目录、缓存目录和全局 bin 目录有完整读写权限，就能避免绝大多数 permission denied 问题。不复杂但容易忽略。