^2.8允许2.8.0至
^2.8 表示允许安装 2.8.0 到 2.99.99.99（主版本不变、次版本 ≥8），但绝不会装 3.0.0——这是 SemVer 在 Composer 里的实际边界，不是“大概意思”。
什么是 ^、~、精确版本的区别？
^ 和 ~ 看似都“放宽版本”，但卡位逻辑完全不同，直接影响你下次 composer update 能不能升级、升到哪。
-
"monolog/monolog": "^2.8"→ 允许2.8.0到2.99.99（等价于>=2.8.0 ） -
"monolog/monolog": "~2.8.0"→ 只允许2.8.x（等价于>=2.8.0 ） -
"monolog/monolog": "2.8.1"→ 死锁，只认这个版本，连2.8.2的安全修复都不会拉
常见错误现象：写成 "^2"，本意是“只要 2.x 就行”，结果它真会装 2.99.99；而写成 "2.*" 看似一样，其实被解析为 >=2.0.0 ，和 <code>^2 行为一致——但别这么写，语义模糊，容易误读。
为什么 composer show -a 比 composer search 更可靠？
composer search 只查包名和描述关键词，不返回版本列表；真正要看一个包有哪些可用版本，必须用 composer show -a。
-
composer show -a monolog/monolog会列出所有 tagged release（如3.5.0、2.10.0）、预发布（3.6.0-RC1）、分支快照（dev-main） - 它不依赖本地是否已安装该包，也不看你
composer.json里有没有写它 - 如果输出太长，加
--format=json | jq -r '.versions | join("\n")'只看版本号 - 私有包查不到？检查
repositories配置和 token 是否有效，镜像源可能延迟数小时
拼错包名会直接报 Package not found，这不是命令失效，是 Packagist 上真没这个命名空间。
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
项目自身的 version 字段到底要不要填？
不要手动填。Composer 会根据 Git tag（如 v2.1.3）或当前分支名（如 dev-main）自动推导版本，硬写反而导致问题。
- 手动写
"version": "1.0.0"但没打对应 tag → Composer 报警告：Package xxx has a version constraint which does not match the version in its composer.json - 发布到 Packagist 的包，必须靠 Git tag 触发同步；
version字段存在反而干扰识别 - CI 流程里用
sed -i替换version字段 → Git diff 和 tag 不一致，Packagist 同步失败
正确做法：留空 version 字段，打 tag 前确保格式是 vX.Y.Z（开头带 v），然后 git push origin v2.1.3。
怎么安全地升级自己包的版本号？
Composer 本身没有bump 命令，得靠插件，最常用的是 vinkla/composer-bump（本地开发安装即可）。
- 安装：
composer require --dev vinkla/composer-bump - 升级：
composer bump patch（1.2.3→1.2.4）、composer bump minor（→1.3.0） - 默认会自动
git add composer.json、提交、打v1.3.0标签；不想提交就加--no-commit --no-tag - 必须满足两个前提：Git 仓库已初始化、当前工作区干净（无未提交变更）
注意：这个插件只改你自己的 composer.json 中的 version 字段，不会碰你 require 的其他包——那是 composer update 的事。
版本号不是编号游戏，是你和 Composer 之间的风险约定：你写 ^2.8，等于说“我接受次版本和修订号的所有变更，但绝不跨主版本”；一旦对方包不守 SemVer 规则（比如在 2.8.1 里删了你正在用的方法），再严谨的约束也救不了你。所以看 CHANGELOG、信知名库、别迷信数字本身。
