composer.json 中的 version 字段不应手动填写，应留空由 Composer 根据 Git tag（如 v1.2.0）或分支名（如 dev-main）自动推导，否则会导致依赖解析异常、安装失败或 Packagist 拒绝收录。
composer.json 里的 version 字段到底要不要手动写
别写。除非你发的是稳定 tag，否则 version 字段由 Composer 自动推导更可靠。手动填死会导致 composer install 时版本解析异常、依赖安装失败，甚至让 Packagist 拒绝收录。
- 本地开发中，
version字段留空或删掉最安全；Composer 会根据 Git tag（如v1.2.0）或分支名（如dev-main）自动识别版本 - 如果你在私有包里硬写了
"version": "1.0.0"，但 Git 没打对应 tag，Composer 会警告Package <name> has a version constraint ... which does not match the version in its composer.json</name> - 发布到 Packagist 的包，必须靠 Git tag 触发同步，
version字段在composer.json中的存在反而可能干扰自动识别
想让 require 时锁定具体版本，该用什么方式
靠 require 里的约束写法，而不是改自己项目的 version。项目自身的 version 对依赖解析没作用，真正起效的是你在别的项目里写 "my/package": "1.2.0" 这类声明。
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 固定小版本：
"my/package": "1.2.0"—— 只匹配这个精确版本 - 兼容性写法：
"my/package": "^1.2.0"—— 允许1.x.x但不跨主版本 - 开发中临时指向本地路径：
"my/package": "dev-main#abc123"，配合repositories使用，绕过版本字段 - 误改了
version导致composer update报错？先删掉它，再运行composer dump-autoload清缓存
发布正式版时怎么让 version 正确生效
靠 Git tag，不是改 composer.json。Composer 在读取包信息时，优先信任 tag 名，tag 名格式必须严格匹配语义化版本（如 v2.1.3），且要推送到远程仓库。
- 打 tag 前确保
composer.json里没有手写的version字段（或者值为"@package_version@"这类占位符） - 正确命令：
git tag v2.1.3 && git push origin v2.1.3；注意开头的v，很多错误源于漏写 - Packagist 同步后，其他项目
composer require my/package:^2.1才能命中；如果只改了composer.json但没打 tag，Packagist 根本看不到这个“版本” - CI 发布流程里，不要用
sed -i替换version字段——这会让 Git diff 和 tag 失去一致性
为什么 vendor 里某些包显示 version 是 dev-main 而不是数字
因为那个包没打语义化 tag，或者你用 require 指定了分支（如 "monolog/monolog": "dev-main"）。这不是 bug，是 Composer 的预期行为：没 tag 就回退到分支快照。
- 检查源包 Git 仓库是否真有
v3.5.0这样的 tag：git ls-remote --tags origin | grep -v '\^{}$' - 你自己的项目出现
dev-main，大概率是还没打 tag，或者composer.json里写了"version": "dev-main"这种无效值 - CI 构建时若需稳定版本号，别依赖
composer show输出的 version 字段，改用git describe --tags --always
composer.json 里的 version 字段根本不是一回事，前者决定别人怎么装你，后者几乎只在极少数私有注册表场景下被读取——多数时候它只是个干扰项。 
