Composer本身不提供changelog生成能力，必须借助conventional-commits+standard-version等外部工具链，通过规范提交格式、自动生成CHANGELOG.md、打语义化标签并更新composer.json version字段来实现。
Composer包的changelog不能靠Composer自动生成
Composer本身不提供 changelog 生成能力，它只是依赖管理器，不是发布工具。你看到的 composer.json 中的 version 字段仅用于约束安装行为，和 Git 标签、语义化版本、变更日志完全无关。想让 changelog 出现在 Packagist 页面或本地开发流中，必须借助外部工具链。
用 conventional-commits + standard-version 实现自动化
主流可靠方案是约定式提交（conventional commits）配合 standard-version：它读取 Git 提交信息，按规则生成 CHANGELOG.md、打语义化标签、更新 composer.json 中的 version 字段，并推送。
- 先统一提交格式，比如
feat(auth): add token refresh、fix(api): handle 401 in client、chore(deps): update guzzlehttp/guzzle to ^7.8 - 安装：
npm install --save-dev standard-version - 首次运行前确保 Git 已提交所有变更，然后执行：
npx standard-version --tag-prefix="v" --commit-hooks=false - 它会自动：生成
CHANGELOG.md、修改composer.json的version、创建 Git tag（如v1.2.0）、提交并退出 —— 后续只需git push --follow-tags - 注意：别在 CI 中直接运行
standard-version，它会写文件、改 commit；应只在本地发版时运行
Packagist 自动同步 changelog 的关键点
Packagist 不解析 CHANGELOG.md，也不展示它。但它会抓取 Git tag 对应的 composer.json 版本，并把该 tag 的 README.md 渲染为包主页。所以真正影响用户看到什么的，是你的 README 结构和是否手动/自动把 changelog 聚合进去。
- 推荐做法：在
README.md底部加一个## Changelog章节，用[v1.2.0](https://github.com/yourname/yourpkg/releases/tag/v1.2.0)链接到 GitHub Release 页面 - GitHub Release 页面能自动渲染
CHANGELOG.md内容（如果存在），或显示 tag diff；你也可以用gh release create手动发布并粘贴 changelog 摘要 - 别指望
composer show yourname/yourpkg显示 changelog —— 它只返回name、description、version、source等元数据
CI 中触发 changelog 更新的常见误区
很多人想在 GitHub Actions 里“自动发版”，结果要么重复打 tag，要么覆盖已有版本，要么破坏本地工作流。核心矛盾在于：语义化版本号应由人判断，而非机器猜。
- 不要用
on: push自动跑standard-version—— 这会导致每次 push 都升版本，且无法控制feat还是fix - 可行方式：用
on: workflow_dispatch或on: release（监听 Draft Release 发布），再调用standard-version并 push tag - 更安全的做法是：CI 只做验证（测试、静态分析、打包），发版动作保留在本地，由维护者显式执行 —— 这样才能对
major/minor/patch做准确决策 - 如果真要用自动化，务必加
--dry-run先看输出，确认生成的版本号和 changelog 条目符合预期
实际落地时，最易被忽略的是提交信息规范与团队协作节奏的匹配。没人检查 feat 和 fix 是否写对，changelog 就会迅速失真；而一旦失真，standard-version 生成的版本号就不可信 —— 后面所有基于它的自动化都会出错。
