Composer 依赖冲突需用 composer why-not 定位源头，CI 中 PHP 版本不匹配应指定完整 PHP 路径或正确配置 platform.php，锁文件必须严格维护，版本约束如 ^1.0 || ^2.0 因无交集必然失败，须查 Packagist 确认实际兼容版本。
composer install 报错 “Your requirements could not be resolved” 怎么办
这不是网络或权限问题，是 Composer 在依赖解析阶段就判定无解，直接终止。它不会尝试安装、也不会写入 vendor/，只输出 Conflict 信息和若干 Problem 条目。
关键动作不是删 lock 或清缓存，而是立刻定位阻塞源头：
- 复制报错中出现的
don't install vendor/package:version片段（比如don't install guzzlehttp/guzzle:^7.5） - 执行
composer why-not vendor/package:version（版本号必须完整，如7.5.0，不能写^7.5） - 输出从下往上读：最后一行是你
composer.json的根声明，上面每行末尾的(required by ...)就是施加冲突约束的包
注意：如果 why-not 输出为空，大概率是 require-dev 在作祟（比如 phpunit/phpunit 锁死了某个 sebastian/* 版本），此时加 --dev 参数重试。
CI 构建中 PHP 版本不匹配导致失败
常见现象是 CI 日志里出现 requires php ^8.2 but your PHP version (8.0.30) does not satisfy that requirement —— 这说明构建环境的 php -v 和项目要求的 platform.php 不一致。
正确做法不是加 --ignore-platform-reqs（它会跳过所有扩展校验，运行时可能直接 Class 'Redis' not found），而是：
- 在 CI 脚本开头加
php -v打印实际版本，确认是否真不匹配 - 用完整路径调用目标 PHP：Linux/macOS 写
/usr/bin/php8.2 composer install，Windows 写"C:\php\php82\php.exe" composer install - 若必须用
config.platform.php（例如为高版本生产环境提前打包），则先运行composer config platform.php "8.2.10"，再跑composer update --lock重写锁文件
切记："platform": {"php": "8.2"} 是非法写法，版本号必须带小数点后两位（如 "8.2.10"），否则 Composer 解析失败。
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
自动构建时频繁因间接依赖升级失败
典型表现是某次 composer install 成功，下次却失败，错误指向一个你没动过的包（比如 symfony/console 突然要求 php >=8.1）。这往往是因为上游包发布了新版本，而你的 composer.lock 没锁定其子依赖的兼容范围。
应对策略是收紧更新行为：
- 禁用全量更新：永远不要在 CI 中跑
composer update或composer update --with-all-dependencies - 只允许最小变更：CI 中统一用
composer install --no-interaction --prefer-dist，确保完全按composer.lock还原 - 本地开发升级时，优先用
composer update vendor/package --with-dependencies，而非update全局命令 - 对主框架（如
laravel/framework）升级，务必配合--dry-run -v预检，确认无隐性冲突再提交 lock 文件
锁文件不是摆设——它唯一的作用就是让 install 可重现。一旦 CI 报错，第一反应应是检查 git diff composer.lock，看谁偷偷改了依赖树。
为什么加了 ^1.0 || ^2.0 还是冲突
因为 || 是逻辑或，不是版本交集运算符。Composer 的 SAT 求解器必须选出**唯一确定的版本**，而 ^1.0 和 ^2.0 在语义化版本规则下没有交集（1.x 和 2.x 主版本不兼容），所以求解必然失败。
真正有效的做法是人工找交集：
- 去 Packagist 查目标包的每个版本页，点开
composer.json，看它的require字段是否同时被多个冲突包接受 - 或运行
composer show vendor/package --all | grep -E "(^v[0-9]|requires)"，快速扫一遍各版本的依赖声明 - 找到一个双方都 require 的具体版本（如
2.9.3），然后在composer.json中写死："vendor/package": "2.9.3"
别信文档里写的“支持 ^2.0”，要以实际发布在 Packagist 上的 composer.json 文件为准——有些包在 README 说兼容，但 require 里仍锁着 "php": "^7.4"，会间接卡住整棵树。
