Composer项目版本号由Git标签或VCS元信息自动推导，不应在composer.json中硬写"version"字段，否则会导致依赖解析异常、安装失败；正确做法是删除该字段，通过git tag（如v3.2.1）管理版本。

Composer 项目自身的版本号不由 composer.json 中的某个字段“定义”，而是由 Git 标签（tag）或 VCS 分支/提交决定；"version" 字段在大多数情况下应**删除或留空**，强行写死会导致依赖解析异常、包管理混乱甚至安装失败。

为什么不能手动写死 "version" 字段

Composer 在安装时会根据 VCS（如 Git）元信息自动推导版本，例如：

• 存在 v2.1.0 tag → 解析为 2.1.0 版本
• 当前分支是 dev-main 且有未打 tag 的提交 → 解析为 dev-main 或带 hash 的开发版（如 dev-main#abc123）

若你在 composer.json 中硬写：

{
  "name": "myorg/myapp",
  "version": "1.0.0"
}

则 Composer 会认为这是一个「无 VCS 的本地包」，并强制将其视为 1.0.0 —— 即使你已打过 v2.0.0 tag，它也视而不见。更严重的是，当该包被其他项目 require 时，版本约束（如 ^1.0）可能匹配失败，或触发“Package not found”错误。

"version" 字段只在特定离线场景下可用

仅当满足全部以下条件时，才可显式设置 "version"：

• 项目不托管在 Git / SVN 等 VCS 中（例如纯 ZIP 分发、内网共享目录）
• 你完全控制该包的分发方式，且不会通过 Packagist 或私有仓库发布
• 所有依赖方都以 path repository 方式引入（即 "type": "path"）

即便如此，也建议改用 "minimum-stability": "dev" + "prefer-stable": false 配合分支名（如 "dev-master"）来管理，而非硬编码 version。

Workspace Git Setup

一键在任意工作目录中设置 Git 跟踪，并附带安全为重点的 .gitignore（包括凭证、TLS/SSH 私钥、令牌、运行时缓存和 PID 等）

下载

正确标注版本的实操方式

真正可控、可复现、被 Composer 和 Packagist 正确识别的版本来源只有 Git tag：

• 打语义化标签：git tag -a v3.2.1 -m "release 3.2.1"
• 推送标签：git push origin v3.2.1（或 git push origin --tags）
• 确保 composer.json 中不含 "version" 字段（可安全删除）
• 若需声明稳定版本策略，在根 composer.json 加：

  {
    "minimum-stability": "stable",
    "prefer-stable": true
  }

Packagist 自动抓取时，会读取 tag 名并标准化为版本号（如 v3.2.1 → 3.2.1），同时支持 ^3.2、~3.2.0 等约束匹配。

常见错误现象与排查点

当你发现 composer install 显示版本不对、require 不生效、或 composer show 输出 dev-main 而不是预期的 2.0.0，先检查：

• git tag 是否真的存在且已推送（git ls-remote --tags origin）
• composer.json 是否意外残留了 "version" 字段（grep version composer.json）
• 当前工作目录是否在 Git 仓库根下（非子目录，否则 Composer 无法读取 .git）
• 是否在 CI/CD 中用了浅克隆（--depth=1），导致没拿到 tags（需加 --tags 或 git fetch --depth=full origin）

版本号不是配置项，是源码状态的快照。Git tag 才是唯一可信的源头，其余都是干扰项。