根本原因是Composer试图向系统级目录写入文件时被权限机制阻止，应改COMPOSER_HOME目录权限而非系统目录；修复方法为chown -R $USER:$USER ~/.composer并chmod -R u+rw ~/.composer。
Composer 执行时报 Permission denied 怎么办
根本原因不是 Composer 本身有问题，而是它试图往系统级目录（比如 /usr/local/bin 或 /opt/composer）写文件时被 Linux/macOS 权限机制拦住了。常见于用 sudo curl -sS https://getcomposer.org/installer | php 后直接 sudo mv composer.phar /usr/local/bin/composer，但没改后续权限或没考虑用户组归属。
改 COMPOSER_HOME 目录权限比硬改系统目录更安全
Composer 默认把全局配置、缓存、插件全塞进 ~/.composer（Linux/macOS）或 %USERPROFILE%\AppData\Roaming\Composer（Windows）。只要这个路径属主是你本人、且可读写，绝大多数权限报错就消失了。
- 检查当前归属：
ls -ld ~/.composer，如果显示属主是root，说明之前误用了sudo - 修复命令：
sudo chown -R $USER:$USER ~/.composer（Linux/macOS） - 顺手加个宽松但不过分的权限：
chmod -R u+rw ~/.composer（避免未来因 umask 导致子目录不可写） - Windows 用户重点检查：是否在 PowerShell 或 CMD 中以管理员身份运行过 Composer 命令？删掉
%APPDATA%\Composer后重试即可
composer global require 报错时先确认执行用户和 COMPOSER_HOME
很多人以为 global 就是“装给所有人用”，其实只是“装给当前 COMPOSER_HOME 对应的用户”。如果 PHP-FPM 或 cron 用的是 www-data 或 daemon 用户，它们根本看不到你个人账户下的 ~/.composer。
- 查当前生效的
COMPOSER_HOME：composer config --global home - 如果输出是空，说明走默认路径；如果输出是
/var/www/.composer这类非家目录，就得确认该路径属主是不是当前执行用户 - 临时切换作用域验证：
COMPOSER_HOME=/tmp/my-composer composer global require laravel/installer，看是否还报错——能跑通就说明原路径权限/归属才是问题 - 不建议长期用
sudo composer global require，这会让二进制文件（如laravel）落在/root/.composer/vendor/bin，普通用户根本执行不到
用 --no-interaction 和 --no-plugins 快速定位是不是插件/钩子惹的祸
有些权限错误不是出在 Composer 主流程，而是某个全局安装的插件（比如 hirak/prestissimo 或自定义脚本）在初始化时尝试访问受限路径。
- 加参数绕过插件试试：
composer install --no-plugins --no-interaction - 如果成功，说明问题在插件；再逐个禁用：
composer global remove hirak/prestissimo - 特别注意：某些企业镜像源插件会尝试写
/etc/composer/或调用systemctl，这类行为在无 sudo 权限时必然失败 - 插件日志一般藏在
~/.composer/cache/plugins/，权限不对时连缓存都写不进去，会静默失败
最常被忽略的一点：Docker 容器里跑 Composer，~/.composer 绑定到宿主机目录时，UID 不一致会导致容器内看到的文件属主是 “nobody” 或 “1001”，这时候改宿主机目录权限没用，得在 Dockerfile 里用 user 指令对齐 UID，或者挂载时用 uid=1001,gid=1001 参数。
