composer self-update 升级失败主因是 PHP 版本不足、文件权限受限或镜像源不代理 GitHub API；需切官方源、显式指定版本、加 --no-interaction 参数，并确保环境满足 v2.5+ 要求。
直接运行 composer self-update 就能升级 Composer 自身，但它不是“一按就灵”的黑盒操作——它受 PHP 版本、文件权限、镜像源策略三重制约，任一环节出问题都会静默失败。
为什么 composer self-update 总提示 “Up to date” 却没真升级？
这不是命令失效，而是 Composer 默认从 GitHub 拉取最新版，但你的全局配置可能把包源（repo.packagist）设成了阿里云或腾讯云镜像——这些镜像不代理 self-update 所需的 GitHub API 请求，导致它连不上官方版本接口，只能本地比对，误判为“已最新”。
- 先临时切回官方源：
composer config -g repo.packagist composer https://packagist.org - 再执行更新：
composer self-update - 升级完立刻换回镜像（推荐）：
composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/
Windows 上报 Permission denied 怎么办？
Windows 会锁住正在运行的 composer.phar 文件，导致 self-update 无法覆盖自身——这不是权限不足，是系统级文件锁定。
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 别硬加
sudo或右键“以管理员身份运行”，这解决不了根本问题 - 用 PHP 显式调用 PHAR 文件本身：
php "C:\Users\YourName\AppData\Roaming\Composer\vendor\bin\composer.phar" self-update - 先查真实路径：
where composer或composer --version --no-ansi看输出里的加载路径 - 长期建议卸载 GUI 安装版，改用手动安装到用户目录（如
C:\Users\YourName\bin\），再加进PATH
想升 v3 或退回 v2，必须显式指定参数
self-update 默认只在当前主版本内滚动更新（比如 v2.7.6 → v2.7.7），绝不会跨主版本跃迁。v2 和 v3 不兼容，插件、锁文件格式、签名验证机制都变了，所以它必须被明确告知“我要换通道”。
- 升到 v3 最新版（生产环境慎用）：
composer self-update --3 - 退回 v2 最新版（适合从 v3 预览版撤退）：
composer self-update --2 - 锁定某精确版本（如修复某个 CI 构建问题）：
composer self-update 2.5.8 - 检查可用通道：
composer self-update --list（需 Composer ≥ 2.5）
CI/CD 里自动升级总卡住？记得加 --no-interaction
GitHub Actions、GitLab CI 这类无终端交互环境里，self-update 默认会等待用户确认，超时后整个构建失败——错误日志里往往只显示“timeout”，看不出是卡在哪儿。
- 必须加参数：
composer self-update --no-interaction - 如果还要控制版本范围，直接指定更稳妥：
composer self-update 2.7.7 --no-interaction - 某些基础镜像（如
php:8.2-cli）自带的 Composer 版本老旧，CI 脚本第一行就该做这步，否则后续install可能因插件签名验证失败而中断
最麻烦的从来不是命令本身，而是它悄悄依赖的三样东西：PHP 版本是否 ≥ 8.0（v2.5+ 强制要求）、当前用户能否写入 which composer 返回的路径、以及你配的镜像源有没有干扰 GitHub API 访问——漏掉任何一个，self-update 就会变成一个安静的失败。
