composer self-update 报“permission denied”需先用 which composer 和 ls -l 查明路径与权限，避免 sudo；推荐本地安装或重装至 $home/bin；若提示 openssl 缺失，检查 php.ini 并启用扩展；网络问题可临时用镜像下载替换，但生产环境应坚持官方源；软链接未更新导致版本不一致时需手动修复链接。
Composer self-update 报错：“Permission denied” 怎么办
直接原因是当前用户没有写入 composer.phar 所在目录的权限，常见于全局安装后用 sudo 安装、但后续又普通用户执行更新。系统默认把 composer.phar 放在 /usr/local/bin/composer 或 ~/.local/bin/composer，而这些路径往往只允许 root 写入。
- 先查 composer 实际位置：
which composer，再看文件权限：ls -l $(which composer) - 如果指向的是
/usr/local/bin/composer且属主是 root，别硬加sudo composer self-update—— 这会污染全局环境，后续所有项目都可能因权限混乱出问题 - 推荐做法：改用本地安装方式，把
composer.phar放进项目根目录，用php composer.phar self-update更新，完全规避权限问题 - 若坚持全局使用，可重装为当前用户可写路径，例如：
curl -sS https://getcomposer.org/installer | php -- --install-dir=$HOME/bin --filename=composer，再确保$HOME/bin在$PATH中靠前
执行 self-update 后提示 “The openssl extension is required”
这不是 Composer 自身报错，而是 PHP CLI 环境缺失 OpenSSL 扩展，尤其在 macOS（M1/M2）用 Homebrew 装 PHP、或 Windows WAMP/XAMPP 默认关闭扩展时高频出现。Composer 更新需 HTTPS 下载新版 phar，没 OpenSSL 就连不上官网。
- 运行
php -m | grep openssl确认是否启用；若无输出，说明扩展未加载 - Linux/macOS：检查
php.ini中是否有extension=openssl（注意不是注释状态），路径可通过php --ini查看 - macOS M-series：Homebrew PHP 用户常遇到
ext-openssl编译失败，建议用brew install php@8.2（带完整扩展预编译包）而非源码编译 - Windows：打开
php.ini，取消;extension=openssl前的分号，并确认extension_dir指向正确的ext/目录
self-update 卡住或超时：国内网络怎么绕过
Composer 官方更新地址 https://getcomposer.org/installer 在国内直连不稳定，self-update 本质是下载新 phar 并替换，卡住多因 DNS 污染或 TLS 握手失败，不是 Composer 本身 bug。
- 临时方案：设置镜像源仅对 update 生效，加
-vvv参数观察实际请求地址，确认是否走通 - 更可靠做法：手动下载并替换，例如：
curl -o $HOME/bin/composer https://mirrors.aliyun.com/composer/composer.phar（阿里云镜像），再chmod +x $HOME/bin/composer - 注意：不要混用镜像源和官方源做
self-update，Composer 不校验镜像 phar 签名，存在安全风险；生产环境建议仍走官方通道，仅开发机可临时切镜像 - 如需长期稳定，可在
~/.composer/config.json中配置github-protocols为["https"]，避免某些企业网络拦截 git:// 协议
更新后命令失效或版本没变：phar 文件被覆盖但软链接没刷新
某些 Linux 发行版或自定义安装方式会用软链接指向真实 phar 文件（比如 /usr/local/bin/composer → /opt/composer/composer-stable.phar），self-update 只更新目标文件，不触碰软链接本身，导致执行的仍是旧版本。
- 运行
composer --version和php $(which composer) --version对比，结果不同就说明软链接没同步 - 检查是否为软链接：
ls -la $(which composer)，若第二列有->，就是符号链接 - 修复方式：删掉旧链接，重新创建指向最新 phar，例如：
rm $(which composer) && ln -s /path/to/new/composer.phar $(which composer) - 更省事的办法：不用软链接，直接把
composer.phar放进$PATH目录并命名为composer，避免中间层干扰
真正麻烦的从来不是报错信息本身，而是权限、路径、PHP 扩展、网络四者叠加后的隐性冲突。每次 self-update 失败，优先用 which composer 和 php -m 快速定位到具体哪一环断了，比反复重试更省时间。
