composer update默认受composer.lock约束，改composer.json版本后需全量update或清vendor+install验证；锁死版本用"=x.y.z"，冲突排查用why/prohibits命令。
直接改 composer.json 里的版本约束后，composer update 不一定按你预期拉取新版本——因为 composer.lock 会锁死当前已安装的 commit 或 tag，除非你明确告诉 Composer “要重新计算”。测试约束是否生效，关键在「绕过 lock 文件缓存」和「验证实际安装结果」。
为什么改了 version constraint 却没更新包？
Composer 默认优先信任 composer.lock。哪怕你在 composer.json 里把 "monolog/monolog": "^1.2" 改成 "^2.0"，只要 lock 文件里还记着 1.27.2，运行 composer install 就不会动它。
-
composer install：只按 lock 文件装，完全忽略composer.json的约束变更 -
composer update monolog/monolog：只更新指定包，且仍受 lock 文件中其他依赖的约束影响（可能被“钉住”） -
composer update（无参数）：全量重算，但耗时、易触发意外升级，不适合快速验证单个约束
快速验证 version constraint 的三步操作
不删 lock、不全量 update，也能干净测出约束是否写对：
- 先清掉目标包的 vendor 目录：
rm -rf vendor/monolog/monolog - 再强制只重装这个包：
composer install --no-dev --prefer-dist（加--no-dev避免 dev 包干扰） - 检查实际装的是什么：
composer show monolog/monolog，看输出的 version 和 source 是否符合你写的约束
如果仍没变，说明约束本身没匹配到可用版本——比如你写了 "~3.0"，但 packagist 上该包最高只到 2.10.0，那 Composer 就会 fallback 到 lock 里的旧版，或报错。
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
dev 分支约束测试要额外注意 commit hash 锁定
用 "dev-main" 或 "dev-develop" 这类分支约束时，Composer 实际安装的是某个具体 commit，且会把这个 hash 写进 composer.lock。下次你本地 git pull 更新了分支，composer install 依然不会更新——它认的是 lock 里的 hash，不是远程 HEAD。
- 想让 Composer 拉最新 commit，必须运行：
composer update vendor/package --with-dependencies - 或者删掉 lock 里对应项的手动编辑（不推荐），或干脆删
composer.lock后重update - 验证是否真拉了新 commit：
composer show vendor/package输出里的source行，对比 git log 看 hash 是否一致
避免误判：用 composer why 和 composer prohibits 辅助诊断
有时候约束明明写对了，却装不出想要的版本，大概率是其他依赖在“拦路”：
-
composer why vendor/package：查谁在依赖它，以及用了什么约束 -
composer prohibits vendor/package:2.0.0：查哪个包的约束阻止了2.0.0安装（比如另一个包写了"vendor/package": "^1.0"） - 如果发现冲突，别急着硬改，先用
composer update vendor/package --with-all-dependencies让 Composer 自动协调
真正容易被忽略的是：约束测试必须在 clean vendor + fresh lock 解析环境下做，而不是靠反复 install 猜结果。每次验证前，确认 vendor/ 里没有残留、composer.lock 没被缓存污染，否则你调的不是约束，是在调运气。
