Composer不能直接触发发布，因其无内置发布钩子和Git事件监听能力，scripts仅响应本地命令；可行方案是Git平台触发、CI执行、Composer仅校验元数据与打包。
Composer 本身不提供发布脚本或仓库触发器功能——它只是 PHP 的依赖管理工具，不是 CI/CD 工具，也不是 Git 钩子代理。想靠 composer.json 或 composer publish（根本不存在这个命令）自动发版？行不通。
为什么不能用 Composer 直接触发发布？
Composer 没有内置的「发布」生命周期钩子，也没有对 GitHub/GitLab 事件的监听能力。它的 scripts 字段只在本地执行（如 post-install-cmd），且仅响应 composer install、update 等命令，无法感知远程 push、PR 合并或 tag 创建。
常见误操作包括：
- 在
composer.json里写"post-push": "git tag v1.0.0 && git push --tags"—— 这个 script 根本不会被调用，因为post-push不是 Composer 支持的事件名 - 把 GitHub Actions 的
on: push: tags逻辑误认为是 Composer 能处理的范围 - 试图用
composer config repositories反向驱动发布流程 —— 它只影响依赖解析，不产生副作用
真正可行的自动化发布链路
必须分层协作：Git 平台负责触发，CI 工具负责执行，Composer 仅承担「包元数据校验」和「归档准备」角色。
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
典型组合：
- GitHub：配置
on: push: tags: ['v*']触发 workflow - GitHub Actions：运行
composer validate、composer archive、生成 CHANGELOG、打正式 release - Composer 仅做三件事：
composer validate（检查composer.json合法性）、composer archive（打包不含 dev 文件的 zip）、composer show --no-ansi（确认当前版本号是否匹配 tag）
示例 Action 片段（关键校验步骤）：
run: |
composer validate --no-interaction --strict
composer archive --format=zip --dir=dist/ --file=${{ github.event.repository.name }}-${{ github.head_ref }}
echo "Version in composer.json: $(composer show --no-ansi | grep 'versions' | cut -d' ' -f2)"
容易被忽略的兼容性陷阱
很多维护者卡在「本地能跑，CI 报错」，问题往往出在环境差异上：
-
composer archive默认包含.git目录 —— 但 GitHub Actions 的 checkout 默认不带 .git，需显式加fetch-depth: 0 - PHP 版本不一致导致
composer validate结果不同：本地用 PHP 8.2，CI 用 8.1，而composer.json中require.php写了^8.2，CI 就会失败 - 私有依赖未配置 token：若
composer.json引用了私有 repo，在 CI 中需提前运行composer config http-basic...或注入COMPOSER_AUTH
最常漏掉的是 tag 名称格式校验——GitHub 的 v1.0.0 和 1.0.0 是两个 tag，而 composer.json 里的 version 字段若写成 "1.0.0"，但 CI 从 ${{ github.head_ref }} 读到的是 v1.0.0，版本比对就失效了。得统一用 ${{ github.head_ref }} | sed 's/^v//' 做清洗。
