Composer版本约束无通用最优解，需按项目权衡：^1.x允许次版本升级但^0.x仅限补丁；精确版本如"7.4.5"易引发冲突，~1.2.3实为>=1.2.3而非全兼容1.2.x。
Composer 依赖版本配置没有“通用最优解”，只有“当前项目可维护的最小约束”——写宽了会悄悄升级出问题，写死了又卡死协作和升级路径。
composer.json 里版本号到底怎么写才不翻车
别信“用 ^ 最安全”这种笼统说法。^ 的行为取决于主版本号是否为 0：^1.2.3 允许升到 1.99.99，但 ^0.2.3 只能升补丁（0.2.4、0.2.5），次版本变动即视为破坏性变更。实际项目中常见陷阱：
- 把
"monolog/monolog": "^2.0"当成“永远只用 2.x”，结果某天 CI 装上2.10.0，而你的日志格式化逻辑在2.9.0后被静默废弃 - 私有 SDK 里写
"guzzlehttp/guzzle": "7.4.5"这种精确版本，下游项目一加 Laravel 10 就直接报错，因为 Laravel 10 要求^7.5 - 误用
~1.2.3以为能兼容1.2.x全系列，其实它等价于>=1.2.3 ，连 <code>1.2.10都可能被排除（如果包作者跳过了该版本）
务实做法是：查 Packagist 确认哪个小版本被上下游同时接受（比如 2.9.3），然后锁死——"monolog/monolog": "2.9.3"，再配合 composer.lock 提交。
冲突报错时先别改 composer.json，跑这两个命令
报 Conclusion: don't install vendor/package:2.5.0 不代表你要删包，而是某个依赖在封杀它。必须分两步定位：
- 运行
composer why-not vendor/package:2.5.0—— 查谁在显式/隐式阻止这个版本（输出里出现dev-main就说明你本地用了 path repo，得进那个私有库目录再跑一次） - 再跑
composer why vendor/package—— 看这个包是怎么被拉进来的，常发现是require-dev里的测试工具（如orchestra/testbench）硬绑了旧框架版本
注意：composer prohibits vendor/package:2.5.0 也能列出所有冲突路径，但它不显示依赖层级，不如 why-not 直观。
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
升级一个包却失败？大概率是子依赖没跟上
想升 monolog/monolog 到 3.0.0，直接跑 composer update monolog/monolog 失败，不是命令错了，是它的子依赖（比如 psr/log 或 PHP 版本要求）还卡在旧值。正确姿势：
- 加
--with-dependencies：运行composer update monolog/monolog --with-dependencies，让 Composer 同时重算它所需的最小依赖集 - 别写
composer update "monolog/monolog:^3"—— 引号 +^会让 Composer 自行找最新兼容版，不是你要的3.0.0 - 如果提示
Your requirements could not be resolved，先检查 PHP 版本：monolog 3.0要求php >=8.1，而你本地是7.4，这时升级本身就不成立
极端情况下可用 --with-all-dependencies，但它会重算整棵树，适合新包引入阶段，不适合生产环境热修复。
私有库的 composer.json 是冲突源头，不是背锅侠
团队里 80% 的跨项目冲突，根因都在私有 SDK 的 composer.json 里。它不能按自己喜好写约束，必须为下游让路：
- 禁用精确版本：
"monolog/monolog": "2.8.0"→ 改成"monolog/monolog": "^2.8"（前提是代码真兼容） - 别设
minimum-stability：私有库应完全继承主项目的稳定性策略，否则下游项目一 require 就默认接受dev-master -
composer why-not必须在私有库根目录下运行——你在主项目里跑，查不到它源码里写的约束
最易被忽略的一点：私有库发布必须打 Git tag（如 v2.3.0），而不是靠 dev-main 顶替。Packagist 同步的是 tag，不是分支名。
