versionparser 解析约束时先 normalize 版本（补全四段、去v前缀、转dev分支为伪版本等），再 parseconstraints 得约束对象，最后用 matches 验证；三处易错点：未 normalize 输入版本、约束语法错误、忽略 minimum-stability 设置。
VersionParser 解析约束时到底做了什么
它不是简单切字符串或正则匹配，而是把 ^1.2.3、~2.0、>=7.4 这类写法转成一组可执行的逻辑规则对象。比如 <code>parseConstraints('^1.2.3') 返回的不是字符串，而是一个 ConstraintInterface 实例，内部封装了 min、max、stability 和是否允许预发布版本等状态。
关键点在于：所有约束最终都归一为「版本区间 + 排除列表」。例如 ^1.2.3 被展开为 >=1.2.3 ，再过滤掉 <code>alpha/beta 等不稳定版本（除非 minimum-stability 显式放宽）；而 1.2.* 实际等价于 >=1.2.0 ，不是通配符模糊匹配。
-
parseConstraints()只处理约束字符串，不校验包是否存在，也不触发行下载 - 多个约束用
||连接时，返回的是MultiConstraint，matches()会逐个尝试，任一满足即返回true - 空格敏感：
"^ 1.2.3"（插入符后带空格）会被解析失败，报Invalid version constraint
为什么不能用 version_compare() 直接比 ^1.2.3
version_compare() 只能比较两个具体版本号，比如 version_compare('1.5.0', '1.2.3', '>=')，但它完全不知道 ^1.2.3 的数学含义——它既不理解语义化版本的主次补丁层级，也不处理 dev-main、1.2.x-dev 这类非标准格式。
直接拿 version_compare($v, '1.2.3', '>=') 去模拟 ^1.2.3，会漏掉上限检查（比如装上 2.0.0 就破坏兼容性），更无法处理 ~1.2 这种“锁主版本但放开次版本”的特殊逻辑。
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 错误示例：
Comparator::greaterThan('8.0.0', '7.4.0')只判断单点大小，不是范围匹配 - 正确路径：先
$parser->parseConstraints('^7.4')得约束对象，再$constraint->matches('8.0.0') - 注意：
matches()输入的版本必须是已 normalize 的，如'7.4.5'可以，'v7.4.5'或'7.4'会失败（除非先过$parser->normalize()）
normalize() 不只是加 .0，它在干啥
$parser->normalize('1.2') 返回 '1.2.0.0'，不是为了“好看”，而是统一内部表示：Composer 把所有版本强制扩展为 4 段（major.minor.patch.build），这样 version_compare() 才能稳定工作，也方便做区间交集计算。
这个步骤还处理了常见歧义：去掉 v 前缀、补全缺失段、转换 dev- 分支为伪版本（如 dev-main → 9999999.9999999.9999999-dev）、识别 stable/RC 稳定性标签。没走这步就调 matches()，很可能因格式不一致返回 false。
-
$parser->normalize('v2.0.0')→'2.0.0.0' -
$parser->normalize('2.x-dev')→'2.9999999.9999999.9999999-dev'（用于排序和稳定性判断） -
$parser->normalize('1.2.3-beta')→'1.2.3.0-beta'，后续parseStability()才能正确提取'beta'
实际验证约束时最容易卡住的三个地方
写完 matches() 逻辑却总返回 false？大概率栽在这三处：
- 没对输入版本调
normalize()：传'7.4'进去，matches()内部会按'7.4.0.0'处理，但约束对象可能期望完整四段格式，导致比对失败 - 约束字符串本身有语法错误：比如
"^ 7.4"（插入符后空格）、"php": ">=8.1"（空格紧贴操作符）、"monolog/monolog": "2.x-dev"（缺@dev后缀）——这些在parseConstraints()阶段就抛异常，但很多人没 catch - 忽略 minimum-stability 设置：即使
^1.2.3数学上包含1.3.0-RC，如果项目composer.json里"minimum-stability": "stable"，matches()也会排除它——VersionParser默认尊重该配置
真正可靠的验证流程，一定是：normalize 待测版本 → parseConstraints 原始约束 → 调 matches，中间任何一步跳过，结果都不可信。
