composer self-update不是“能用就行”的命令，而是需主动管理的版本策略：默认不跨主版本、镜像会缓存响应致误判“Up to date”、权限错误即卡死；必须切官方源校验、用户目录安装避权限问题、显式参数控版本、CI/CD禁用自动升级并锁定版本。
composer self-update 不是“能用就行”的命令，它现在是一套需要主动管理的版本策略——默认不跨主版本、镜像会骗它、权限错一次就卡死，不厘清这些，更新就等于埋雷。
为什么 composer self-update 总提示 “Up to date” 却还是旧版
这不是命令失效，是 Composer 被镜像源“哄骗”了。阿里云、腾讯云等镜像会缓存 https://getcomposer.org/ 的响应，导致它根本没连上官方服务器校验版本。
- 先切回官方源：
composer config -g repo.packagist composer https://packagist.org - 再执行：
composer self-update - 升级完立刻换回镜像（推荐）：
composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/
注意：这个流程必须做全，只改镜像或只跑 self-update 都不行。
Permission denied 错误别硬加 sudo
file_put_contents(/usr/local/bin/composer): failed to open stream: Permission denied 是路径权限不匹配，不是 Composer 的 bug。硬加 sudo 可能破坏插件加载机制，后续更难排查。
- 优先重装到用户目录：
php composer-setup.php --install-dir=$HOME/bin --filename=composer - 确保
$HOME/bin在$PATH前置位置（检查echo $PATH） - Windows 用户遇到
Access is denied，改用显式调用：php "C:\path\to\composer.phar" self-update
升级后若命令失效，先清 shell 缓存：hash -d composer（bash/zsh）或重启终端。
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
想升 v3 或锁死某个小版本，参数不能乱写
v2 和 v3 不兼容，self-update 默认拒绝跨主版本跃迁。所谓“高级参数”，其实是你明确承担风险的开关。
- 升到最新 v3：
composer self-update --3（两个短横线 + 数字，不是--preview） - 退回 v2 最新版：
composer self-update --2 - 锁定精确小版本（如修复 patch）：
composer self-update 2.7.7（版本号必须和 GitHub release tag 完全一致） - CI/CD 中必须加
--no-interaction，否则卡在交互确认上直接超时
升级后如果 composer install 报 Plugin API version mismatch，大概率是老插件（如 hirak/prestissimo）不支持 v3 的 composer-plugin-api: ^3.0，临时方案是 composer self-update --2。
CI/CD 和 Docker 里根本别碰 self-update
在 GitHub Actions、GitLab CI 或 Docker 构建中写 composer self-update 是高危操作——它可能突然从 v2 升到 v3，导致整个构建失败，且难以复现。
- CI 中应显式指定版本：
COMPOSER_VERSION=2.6.6+ 官方安装脚本 - Dockerfile 里别在
FROM php:alpine后写RUN composer self-update，改用多阶段 COPY 或系统包安装（如apk add php-composer） - 生产部署命令必须带
--locked：composer install --locked --no-dev --no-interaction，这是防止 lock 文件被绕过的最后一道防线
真正麻烦的从来不是“怎么更新”，而是更新后是否和 composer.json 里的 platform 配置、PHP 版本、插件 ABI 兼容——这些不会报错，但会让依赖解析静默出错。
