根本原因是Packagist未收到GitHub/GitLab的webhook通知或触发条件不匹配；需正确配置webhook地址、勾选Tag push事件、确保仓库URL一致、删除composer.json中的version字段，并显式推送tag。

为什么 push tag 后 Packagist 没有自动更新？

根本原因通常是 Packagist 没收到你的 GitHub/GitLab 仓库的 webhook 通知，或者 webhook 配置了但触发条件不匹配。Packagist 不轮询仓库，只靠你主动“推”事件过去。

• GitHub 侧必须在 Settings → Webhooks 中添加 Packagist 的 endpoint（https://packagist.org/api/github），且 Which events would you like to trigger this webhook? 要勾选 Just the push event 或至少包含 Tag push events
• GitLab 侧需在 Settings → Webhooks 填 https://packagist.org/api/gitlab，并勾选 Tag push events
• 旧版 Packagist（v1）要求 webhook payload 中 repository.url 和 Packagist 上包的 source URL 完全一致（含 git@ 或 https:// 前缀），不一致会导致静默失败
• 用 curl -X POST https://packagist.org/api/update-package?username=xxx&apiToken=yyy 手动触发时，如果返回 404，大概率是包名或 token 权限不对，不是网络问题

composer.json 的 version 字段要不要写？

不要写。写死 "version": "1.2.3" 是常见误操作，它会覆盖 Git tag 解析结果，导致 Packagist 抓到错误版本号，甚至拒绝更新。

Workflow Decomposer

工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。

下载

• 发布前确保 composer.json 中 version 字段被完全删除，或注释掉
• Packagist 依赖 Git tag 自动推断版本：tag v2.1.0 → 版本 2.1.0；tag 2.1.0（无 v）→ 版本 2.1.0；但 release/2.1 这类非语义化 tag 默认被忽略
• 如果你用 composer require vendor/name:dev-main 测试开发版，那 main 分支的 composer.json 就不能有 version，否则会报 could not determine package version

GitHub Actions 自动打 tag 并触发 Packagist 更新怎么做？

关键不是“自动打 tag”，而是打完 tag 后确保 GitHub Action 能把 tag 推到远端——默认 git push 不推 tag，必须显式加 --tags 或 --follow-tags。

• CI 脚本中打 tag 后，必须执行 git push origin --tags（注意不是 git push）
• GitHub Actions 的 on: push: tags 触发器只响应手动 push tag，不响应 workflow 内部的 git 命令，所以别指望靠它二次触发
• 若想在 CI 中验证 Packagist 是否收到更新，可加一步：curl -s "https://repo.packagist.org/p/vendor/name.json" | grep -q '"time":"[^"]*"，检查最新版本时间戳是否刷新
• 避免在 CI 中用 composer update 修改 composer.lock 后再 commit —— 这类自动提交容易引发循环触发或版本混乱

私有包怎么让 Packagist 同步？

Packagist 官方不支持私有仓库同步。所谓“同步”，其实是你用自己的服务器或 CI 工具模拟 Packagist 的抓取逻辑，或改用私有 Packagist 实例（如 Private Packagist、Satis）。

• 开源包走官方 Packagist，私有包要么托管在 GitLab/GitHub 私有库 + Composer repositories 配置为 vcs 类型，要么部署 Satis（轻量）或 Private Packagist（商业）
• 如果硬要让官方 Packagist “看到”私有库，唯一办法是把仓库设为公开——但这违背私有初衷，且一旦设为公开，所有历史 commit 都暴露
• repositories 中写 "type": "vcs" 时，Composer 会直接 clone 仓库并读取 composer.json，不经过 Packagist，因此也不存在“自动更新”一说；版本仍靠 Git tag，但需手动 composer update 或清理 cache 才能感知新 tag

Packagist 的自动更新链条很短：tag → webhook → Packagist 抓取 → 索引更新。任何一环配置错，比如 webhook 地址少个 /api/，或者 tag 名带空格，都会卡住，而且没有明确报错提示。调试时优先查 GitHub/GitLab 的 webhook delivery logs，比翻 Packagist 日志快得多。