composer不读取changelog.md，它仅依赖composer.json的version或git tag；changelog仅供开发者判断是否升级或修复，须严格按keep a changelog规范与tag对齐，并通过composer show、git describe和composer.lock三处确认所装版本是否真实包含对应变更。
Composer 本身不读取、不解析、不验证 CHANGELOG.md，你看到的变更日志内容和实际安装行为完全无关——它只是给人看的，不是给 Composer 看的。
为什么翻 CHANGELOG.md 却发现功能没生效
常见错误现象：执行 composer update 后，新特性或修复没出现，于是去查 CHANGELOG.md，结果发现“已修复”字样，误以为是包的问题。其实根本原因是：
-
CHANGELOG.md和 Git tag /composer.json中的version没对齐——比如 CHANGELOG 写了 v2.1.0 的变更，但你装的是 v2.0.9（因为约束是^2.0） - 作者没按 Keep a Changelog 规范写，混用了模糊描述（如“优化日志输出”），你无法判断是否包含你要的改动
- 你依赖的包本身没发新 tag，只在 main 分支提交了 CHANGELOG 更新，但 Composer 完全不认分支内容
CHANGELOG.md 怎么写才算真正有用
它唯一作用是帮你快速判断「这个版本值不值得升」「我遇到的 bug 是否已修复」。要做到这点，必须满足：
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 每个段落标题严格对应一个 Git tag，格式为
## [2.1.0] - 2026-08-15（日期可选，但版本号不可省） - 只记录可观察的行为变化：比如
HttpClient::send()默认超时从 30s 降为 10s，而不是「提升稳定性」 - 分类明确：用
### Added、### Changed、### Fixed三级标题，别自己发明「Enhancement」「Tweak」这类词 - Breaking change 必须单独列在
### Breaking Changes下，并附带迁移建议（如方法签名变更、配置项移除）
怎么确认你装的版本真包含某条 CHANGELOG 记录
不能靠猜，得查三处：
- 运行
composer show vendor/package，看输出里的versions行，确认当前安装的是不是 CHANGELOG 里写的那个 tag - 进
vendor/vendor/package/目录，执行git describe --tags --exact-match HEAD 2>/dev/null，能返回 tag 才说明是真实发布版本 - 检查
composer.lock中该包的source字段："type": "git"且"reference"是短哈希，"url"对应正确仓库——如果是"type": "package"或"dist"，可能来自 ZIP 镜像，不一定含完整日志
最常被忽略的一点：CHANGELOG 不是 API 文档。哪怕某行写着「支持 PHP 8.4」，你也得去看实际代码里有没有 #[\ReturnTypeWillChange] 或 mixed 类型声明——这些细节不会出现在日志里，但会直接导致 runtime 报错。
