composer self-update是官方唯一推荐的升级方式，它仅替换自身PHAR文件、不依赖项目、失败自动回退；若显示“Up to date”但版本陈旧，多因which composer指向包管理器安装路径（如/usr/bin/composer），此时需用对应工具更新而非self-update。
composer self-update 就是官方唯一推荐的升级方式，不是“可选方案”，而是设计上就该这么用。它不依赖项目、不改配置、不删文件，只替换自身的 composer.phar，失败自动回退，比重装安全得多。
执行 composer self-update 为什么有时没反应？
常见现象是命令返回 “Up to date”，但 composer --version 显示的仍是旧版（比如卡在 2.5.5）。这不是命令失效，而是你当前运行的 composer 命令根本不是那个可更新的 PHAR 文件。
- 检查真实路径：
which composer（Linux/macOS）或where composer（Windows），确认输出是否指向composer.phar - 如果指向
/usr/bin/composer或C:\Program Files\Composer\composer.exe，说明你用的是包管理器（apt/brew/宝塔）安装的版本——这类安装禁用self-update，必须改用对应工具更新（如sudo apt install composer） - 若路径正确但仍卡住，加
-vvv看日志：常卡在 DNS 解析或 GitHub 下载阶段，国内用户应加--mirror https://mirrors.aliyun.com/composer/
Permission denied 错误到底该怎么修？
报错 file_put_contents(/usr/local/bin/composer): failed to open stream: Permission denied，本质是你没权限写入系统目录，不是 Composer 的 bug，硬加 sudo 反而可能破坏插件加载机制。
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 推荐做法：卸载现有安装，改用官方方式重装到用户目录：
curl -sS https://getcomposer.org/installer | php，然后mv composer.phar ~/bin/composer，再确保~/bin在$PATH中 - Windows 用户遇到
Access is denied，是因为 Windows 锁住了正在运行的 PHAR；绕过方法是显式调用 PHP：php "C:\path\to\composer.phar" self-update - 升级后若命令失效，先清 shell 缓存：
hash -d composer（bash）或重启终端
想升 v3 或退回旧版，参数不能乱写
v2 和 v3 不兼容，self-update 默认策略会拦住主版本跃迁，必须显式声明意图。参数不是“高级功能”，而是明确承担风险的开关。
- 升 v3 最新版（实验性）：
composer self-update --3（注意是两个短横线加数字，不是--preview） - 退回 v2 最新版：
composer self-update --2 - 锁定精确小版本（如修复某个 patch 的 bug）：
composer self-update 2.7.7，版本号必须和 GitHub release tag 完全一致（不能写^2.7） - 查看当前支持哪些通道：
composer self-update --list（2.5+ 才支持）
真正容易被忽略的是签名验证机制：Composer 2.2+ 默认启用 GPG 校验，若代理篡改了下载内容或本地 CA 证书缺失，更新会直接中止，不会静默覆盖。这不是故障，是安全设计。
