Composer global self-update命令_Composer更新全局管理的Composer-composer-PHP中文网

composer self-update 是全局操作，只更新当前 shell 通过 which composer 找到的那个可执行文件（如 /usr/local/bin/composer 或其指向的 composer.phar），与项目目录、composer.json、依赖无关；homebrew 安装时更新的是 wrapper 脚本背后的真实 phar；权限错误应重装至用户目录而非滥用 sudo；升级后版本未变需检查 which composer 和软链接路径；升 v3 需先确保 composer ≥ 2.5 且 php ≥ 8.0，再执行 --3。

composer global self-update命令_composer更新全局管理的composer

composer self-update 是全局操作，不是项目级命令

执行 composer self-update 永远只更新你当前 shell 调用的那个 Composer 二进制文件，和当前所在目录、composer.json 或项目无关。它不读取项目配置，也不影响 vendor 或 lock 文件——它只换掉 composer 这个可执行体本身。

常见误解是“在项目里运行就只更新本项目”，其实没有“项目级 Composer”这回事；所谓“全局”，指的是该命令作用于当前 PATH 中生效的那一个实例。

如果你用 which composer 得到 /usr/local/bin/composer，那 self-update 就去改那个路径下的文件（或它指向的 composer.phar）
如果你用 Homebrew 安装，/opt/homebrew/bin/composer 可能是个 wrapper 脚本，self-update 实际更新的是它背后引用的 PHAR，不是脚本本身
如果你通过 curl -sS https://getcomposer.org/installer | php 装在 ~/bin/composer，但 $PATH 里 /usr/local/bin 排在前面，那你敲的 composer 根本不是你亲手装的那个

权限错误 Permission denied 怎么办

报错 file_put_contents(...): failed to open stream: Permission denied 不代表网络或镜像问题，而是你没权限写入当前 composer 文件所在目录。硬加 sudo 能过，但会埋下后续权限混乱的坑——比如 composer install 生成的 vendor 目录属 root，CI 流水线直接失败。

Workflow Decomposer

工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。

下载

首选方案：重装到用户目录，例如 php composer-setup.php --install-dir=$HOME/bin --filename=composer，再把 $HOME/bin 加进 $PATH
临时绕过：用 PHP 显式调用 PHAR 文件路径，如 php /path/to/composer.phar self-update（但要注意路径是否真对应当前 which composer 输出）
绝对避免：长期依赖 sudo composer self-update，尤其在 CI/CD 环境中

为什么 --version 还是旧版，明明提示 “Updated”

终端告诉你 “Updated”，但 composer --version 没变，大概率是 PATH 冲突或软链接套娃。Composer 更新的是它自己所在的那个文件，但 shell 找到的可能是另一个。

第一步永远是 which composer，然后 ls -l $(which composer) 看它到底指向哪
Homebrew 用户注意：/opt/homebrew/bin/composer 常是 shell 脚本，里面可能调用 $(composer-dir)/composer.phar，self-update 更新的是后者，但脚本本身不会变
Windows 用户注意：C:\ProgramData\ComposerSetup\bin\composer.bat 是批处理文件，它调用的 composer.phar 才是真正被更新的目标
多版本共存时，别信提示语，只信 $(which composer) --version

想升 v3？--3 不是万能钥匙

composer self-update --3 确实能升 v3，但有两个硬性前提：当前 Composer 版本 ≥ 2.5，且 PHP 版本 ≥ 8.0。低于这两个条件，命令会静默失败或报错 “unrecognized option”。

旧版（如 2.2.x）必须分两步：composer self-update 升到 2.5+，再 composer self-update --3
v3 移除了 content-hash 字段，首次用 v3 执行 composer install 可能报 The lock file does not contain a compatible version，需先 composer update --lock 重生成锁文件
私有插件若基于 v1/v2 插件 API 开发，v3 下默认不加载，得手动适配新钩子或降级回 --2

最易被忽略的一点：v3 的签名验证更严格，国内某些代理或中间设备会篡改 HTTPS 响应体，导致 Signature mismatch。此时不是删参数了事，而是该换镜像源或检查网络环境。