应升级到满足 ^1.2.0 的版本（如 1.2.0+），因 Composer 严格遵循语义化版本约束，1.1.5 不符合 ≥1.2.0 要求，需运行 composer update xxx 或指定兼容版本。
Composer 报错 requires xxx ^1.2.0 但已安装 1.1.5 怎么办
这不是“能不能强制升级”的问题，而是 Composer 默认拒绝降级或跳过约束——它发现当前装的版本不满足 ^1.2.0（即 ≥1.2.0 且 1.1.5 明确低于下限，所以直接中止。你看到的“依赖版本过低”其实是安装/更新流程被阻断的提示，不是警告。
解决路径只有两条：让项目兼容更高版本，或让 Composer 换一种方式解析依赖。别试图用 composer update --ignore-platform-reqs 硬闯，它不解决版本号不匹配问题。
- 先运行
composer why-not vendor/package:1.2.0查清谁在锁死旧版本（比如某个间接依赖要求"vendor/package": "） - 检查
composer.json里是否有手动写死的旧版本，例如"vendor/package": "1.1.5"，改成"^1.2.0"或删掉让 Composer 自动推导 - 如果该包有多个版本分支（如
1.x和2.x），确认项目代码是否真能兼容1.2.0+—— 特别留意CHANGELOG.md里的 BC break
想跳过版本检查直接装指定版本行不行
可以，但后果自负。Composer 提供 composer require vendor/package:1.2.0 --update-with-dependencies 这类命令强行拉取，但它会连带更新所有冲突依赖，可能引入新问题。
更危险的是用 composer install --ignore-platform-reqs 配合手动改 composer.lock —— 这会导致 lock 文件和 composer.json 不一致，下次别人 composer install 时仍会失败，CI 也会崩。
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 临时调试可用
composer require vendor/package:1.2.0 --no-update && composer update vendor/package，分步控制影响范围 - 若项目用 PHP 8+ 但某依赖只声明支持到 PHP 7.4，需先在
composer.json加"config": {"platform": {"php": "8.1.0"}}再 update，否则 Composer 会因平台不匹配跳过升级 -
--with-all-dependencies比--with-dependencies更激进，会升级传递依赖，容易引发意料外的变更
为什么 composer update vendor/package 没反应
因为默认行为是“只更新到 composer.json 允许的最高兼容版本”，不是“更新到最新版”。如果你的 composer.json 写着 "vendor/package": "^1.1"，那 composer update vendor/package 永远不会升到 1.2.0，哪怕它已发布。
- 必须先改
composer.json中的版本约束，再执行 update；或者用composer update vendor/package --with-all-dependencies强制重新计算整个依赖图 - 运行
composer show vendor/package看当前允许的版本范围（versions行）和实际安装版本（installed行），比报错信息更直观 - 某些包使用
dev-main或dev-develop分支，这类版本不受语义化版本约束，composer require vendor/package:dev-main可绕过限制，但稳定性无保障
升级后运行时报 Class not found 或 Method not exists
说明新版本确实存在 BC break，而你的代码没适配。Composer 不负责校验运行时兼容性，只管安装成功与否。
常见诱因包括：方法签名变更、类名重命名、配置键名调整、废弃接口被移除。不要假设 “小版本升级就一定安全”。
- 查该包的
UPGRADE.md或 GitHub Releases 页面，重点关注Breaking Changes条目 - 用
git grep -n "OldClassName"快速定位旧调用点，配合 IDE 的全局重命名功能批量修复 - 如果只是测试环境需要快速验证，可临时加
autoload-dev映射补旧类名，但不可提交到生产
composer.lock 文件是否被 Git 正确跟踪——很多人改完 composer.json 却忘了 git add composer.lock，导致协作时其他人 composer install 依然装旧版。 
