Composer 2.2+ 已官方移除 self-update 命令，因其存在安全与稳定性风险，尤其影响 CI/CD 和容器化部署；执行时直接报错“Command not defined”并非网络或拼写问题，而是命令本身已被删除。
composer self-update 命令为什么执行不了
多数人遇到 Command "self-update" is not defined 或直接报错，不是打错了，而是 Composer 2.2+ 已默认禁用该命令——官方明确移除了远程自更新能力，认为它在 CI/CD 和容器环境中不可控、不安全。
常见误判点：
- 以为是网络问题，其实根本没走网络：命令本身已被删，
composer self-update在 2.2+ 版本里就是无效指令 - 在 Homebrew / apt / snap 安装的环境下硬试 self-update，结果失败还污染 PATH
- 看到旧文档写“推荐用 self-update”，没注意发布时间，实际对应的是 Composer 1.x 或 2.1 之前版本
验证方式很简单：composer list | grep self-update，如果无输出，说明当前版本确实不支持。
手动下载 composer.phar 替换前必须校验 SHA384
GitHub Releases 页面（https://github.com/composer/composer/releases）上每个 composer.phar 文件都附带 SHA384 校验值。跳过这步等于把执行权交给中间链路，风险远高于“懒得校验”。
操作要点：
- 用
curl -o composer.phar https://github.com/composer/composer/releases/download/2.7.7/composer.phar下载，别用浏览器“另存为”，某些浏览器会加 .zip 后缀 - 校验命令必须用官网公布的哈希值：
shasum -a 384 composer.phar，比对输出是否完全一致（注意是 384，不是 256） - Windows 用户若无
shasum，可用 PowerShell：Get-FileHash composer.phar -Algorithm SHA384 | Format-List
校验失败就删掉重下，别改后缀、别解压、别用 --no-sigcheck 绕过。
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
替换时怎么确认覆盖的是正在用的那个 composer
which composer 输出的路径，未必是你真正要更新的目标文件——它可能是 symlink、wrapper 脚本，甚至是个 alias。
分三步锁定真实目标：
- 运行
which composer，得到路径（如/usr/local/bin/composer） - 运行
ls -l $(which composer)，看是不是指向~/.composer/composer.phar这类实际 PHAR 的软链接 - 如果是 symlink，直接覆盖它指向的源文件；如果是独立二进制（比如 Homebrew 安装的），则需用
sudo mv composer.phar $(which composer)并sudo chmod +x $(which composer)
特别注意 macOS 上 Homebrew 的 /opt/homebrew/bin/composer 是个 shell wrapper，它内部调用的是 $(brew --prefix)/share/composer/composer.phar，替换 wrapper 本身没用。
替换后 composer --version 显示旧版怎么办
这不是更新失败，而是 shell 缓存了旧的二进制路径或存在多版本共存。最典型的情况是：你刚覆盖了 ~/.composer/composer.phar，但 which composer 指向的是 /usr/local/bin/composer（一个早已存在的旧 symlink）。
快速排查顺序：
- 执行
hash -d composer（Linux/macOS）清空命令缓存，再试composer --version - 执行
which -a composer，看是否列出多个路径；若有，按顺序删掉低优先级的（如/usr/bin/composer）或调整$PATH - Windows 用户运行
where composer，检查是否混用了ComposerSetup安装路径和手动 PHAR 路径
真正麻烦的不是换不上去，而是换上去之后，项目里 composer.lock 生成所用的 Composer 版本和当前运行版本不一致——这会导致 install 行为差异，比如 v3 首次运行可能拒绝读取旧 lock 文件里的 require-dev 字段。
