composer self-update 默认只升小版本，不升v3；升v3需显式执行 composer self-update --3（仅2.5+支持），旧版须先升级至2.5+；权限问题应避免sudo，推荐重装到用户目录；可指定版本、通道或预发布版升级，并注意PATH与多版本冲突。
composer self-update 默认只升小版本，不升 v3
执行 composer self-update 不会把你从 v2 升到 v3——哪怕 v3 已发布半年，它也只会卡在 2.x 最新版（比如 2.7.7 → 2.7.8）。这是设计行为，不是 bug。
- v2 和 v3 不兼容：锁文件格式、插件加载机制、PHP 最低要求（v3 需
PHP 8.0+）全变了 - 想升 v3，必须显式告诉 Composer：
composer self-update --3（注意是两个短横线 + 数字 3） - 但
--3参数只在 Composer 2.5+ 才支持；旧版（如 2.2.x）得先跑一次composer self-update升到 2.5+，再加--3 - 验证是否真升上去了：
composer --version，别只信终端返回的 “Updated”
Permission denied 怎么办？别硬加 sudo
Windows 和 Linux/macOS 都常见这个错误，本质是没权限写入当前 composer 文件所在路径，不是网络或签名问题。
- Windows：系统会锁定正在运行的 .phar 文件，
composer self-update直接失败。绕过方法是用 PHP 显式调用：php "C:\ProgramData\ComposerSetup\bin\composer.phar" self-update - Linux/macOS：如果提示
Could not write to /usr/local/bin/composer，说明它是 root 安装的。不建议长期用sudo composer self-update，容易导致后续插件加载异常 - 更干净的解法：重装到用户目录，比如
php composer-setup.php --install-dir=$HOME/bin --filename=composer，再把$HOME/bin加进$PATH
怎么精准控制升级目标？版本、通道、预发布全说清
日常开发里，你往往不需要“最新”，而是要某个确定行为的版本，比如 CI 流水线锁死、或回退修复某个 autoloader 问题。
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 升到指定稳定版：
composer self-update 2.7.7（版本号必须和 GitHub Release 页面 tag 完全一致） - 退回 v2 最新版：
composer self-update --2 - 尝鲜 v3 的 beta/RC：
composer self-update --preview；每日构建版：composer self-update --snapshot - 查自己当前在哪个通道、有哪些可选版本：
composer self-update --list（2.5+ 才支持） - 注意：
--mirror对self-update无效——它只影响包下载，不加速 PHAR 更新
升级后命令没变？可能是 PATH 或多版本冲突
执行完 composer self-update，再输 composer --version 还是旧版，大概率不是更新失败，而是 shell 拿错了二进制。
- 先查真实路径：
which composer，再看它指向的是不是你刚更新的那个 PHAR - macOS 用 Homebrew 装的
/opt/homebrew/bin/composer其实是个 wrapper 脚本，self-update更新的是它背后引用的 PHAR，不是脚本本身 - Linux/macOS 下 bash/zsh 可能缓存了命令路径，试下
hash -d composer清掉缓存 - Windows 常见现象：PowerShell 和 CMD 读取不同 PATH，或者安装了多个 Composer（GUI 版 + 手动版），得手动删掉冗余的
升级本身很简单，难的是判断“我到底在用哪个 Composer”，以及“v3 的 lock 文件变化会不会让队友的 CI 突然挂掉”。别跳过 composer diagnose 和在测试分支跑一遍 composer install。
