在Composer依赖解析中定义自定义版本号-composer-PHP中文网

项目版本号唯一来源是git tag（如v2.1.0），而非composer.json中的version字段；手动填写会导致包识别异常、同步失败和依赖匹配错误。

在composer依赖解析中定义自定义版本号

composer.json 里写 `version` 字段是自定义版本号？别写

不是。你不能靠在 composer.json 里手动填 "version": "2.1.0" 来“定义”项目自己的版本号——这会直接让 Composer 把你的包识别为无 VCS 的本地包，跳过 Git tag、拒绝同步到 Packagist、下游 require 可能匹配失败甚至报 Could not find package。

真实版本唯一来源是 Git tag（如 v2.1.0），Packagist 自动解析为语义化版本，并支持 ^2.1、~2.1.0 等约束。开发中分支名（如 dev-main）也由 Git 自动推导，无需干预。

硬写了 "version": "1.0.0" 又打了 v2.0.0 tag？Composer 仍坚持用 1.0.0 字面值，不校验一致性
CI 里用 sed 替换 version 是高危操作：Git diff 和 tag 元信息脱节，composer.lock 不可复现
仅当完全脱离 Git/SVN、不发布到任何仓库、所有依赖都走 repositories.type = "path" 时，才可勉强填写；且值必须是合法语义化版本（如 "2.1.0"），禁用 "v2.1.0" 或占位符

想让项目对外暴露 Git tag 版本，该怎么做

根本不需要改 composer.json。只要确保：

Git 仓库已打规范 tag（如 v3.2.1，注意带 v 前缀）
composer.json 中的 version 字段被彻底删除或留空
项目已提交到 Packagist（或私有仓库），并启用自动更新

Packagist 会自动抓取 tag，解析出 3.2.1，下游用户就能用 "yourvendor/yourpkg": "^3.2" 正常 require。如果你用的是私有仓库（如 Satis 或 Private Packagist），同样依赖 Git tag 解析，而非 version 字段。

验证方式：运行 composer show yourvendor/yourpkg，看输出的 version 是否与 tag 一致；再查 composer.lock 中对应条目的 version 字段，应为 "3.2.1"，source.type 应为 "dist"。

Discussion Composer

围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par

下载

需要在代码里读取当前版本号？别从 composer.json 读

composer.json 不是运行时配置文件，也不保证和当前 Git 状态一致。正确做法是在构建阶段用 git describe --tags --abbrev=0 2>/dev/null || echo "dev" 生成版本字符串，写入 VERSION 文件或环境变量 APP_VERSION，再由 PHP 代码读取。

CI 流水线中可加一步：echo $(git describe --tags --abbrev=0 2>/dev/null || git rev-parse --short HEAD) > VERSION
PHP 中用 file_get_contents(__DIR__ . '/VERSION') 读取，比解析 JSON 安全、轻量、可控
若必须动态注入到某处（如常量），可用 sed 或模板工具处理 config.php 类文件，但绝不要碰 composer.json

试图在运行时 json_decode(file_get_contents('composer.json')) 拿 version，等于把一个被弃用的信号位当事实来源——它可能为空、为 dev-main、或早已和 tag 脱节。