必须显式推送Tag：git push默认不推Tag，CI中需用git push origin v1.2.0或--tags；私有Packagist需主动调用更新接口，且composer.json不能含version字段，Tag须带v前缀，URL须以/结尾。

CI脚本里打Tag必须显式推送，git push 不够用

很多人在 GitHub Actions 里写了 git tag v1.2.0 就以为完事了，结果 Packagist 根本收不到。因为 git push 默认不推 Tag，必须加 --tags 或 --follow-tags。

• git push origin --tags：推所有本地 Tag（慎用，可能把测试用的临时 tag 也推上去）
• git push origin v1.2.0：只推指定 Tag，更安全，推荐 CI 中使用
• 用 actions/checkout@v4 时，默认 fetch-depth: 1，查不到远端已有 Tag —— 必须设 fetch-depth: 0 才能做重复校验
• 没推送成功？去 GitHub 仓库页面点开 Tags 标签页，确认 v1.2.0 是否存在且指向正确 commit

私有 Packagist 不认 GitHub Webhook，得靠主动通知

官方 Packagist 支持 Webhook 自动拉取，但私有 Packagist（比如 Satis、Private Packagist 或自建服务）通常不监听 GitHub 的 push event，也不能直接复用 https://packagist.org/api/github 这类 endpoint。

Discussion Composer

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

下载

• 必须在 CI 中显式调用私有 Packagist 的更新接口，例如：curl -X POST https://your-private-packagist.com/update?package=vendor/name
• 接口通常需要认证，把 token 存进 GitHub Secrets，用 ${{ secrets.PACKAGIST_TOKEN }} 注入请求头
• 私有源 URL 必须以 / 结尾，否则 Composer 请求会 404；CI 脚本里 curl 测试时也要带尾斜杠
• Satis 要求 Git 仓库本身有语义化 Tag（v1.2.0），且该 commit 下的 composer.json 必须合法（含 name、type、autoload）

composer.json 里不能写死 version 字段

私有 Packagist 同样只靠 Git Tag 解析版本，不是读 composer.json 的 version。如果写了，会导致解析冲突或静默失败。

• CI 打 Tag 前，检查 composer.json 中是否残留 "version": "1.2.0" —— 必须删掉或注释掉
• Monorepo 场景下，子包路径如 packages/foo，其 composer.json 的 name 必须是完整小写格式（vendor/foo），且 repository.url 在 Packagist 后台录入时要精确匹配（如 https://github.com/vendor/monorepo/tree/main/packages/foo）
• Tag 名必须带 v 前缀（v1.2.0），不加前缀时私有 Packagist 可能无法识别，除非你额外配 "no-api": true

验证更新是否生效，别只看 CI 成功就收工

CI 显示 “Push tag” 和 “Call update API” 都 green，不代表私有 Packagist 真的刷新了元数据。常见断点在中间层。

• 手动 curl 私有 Packagist 的包 JSON 接口：curl -s https://your-private-packagist.com/p/vendor/name.json | jq '.packages."vendor/name"' | grep '"time":'，确认时间戳已更新
• 本地执行 composer clear-cache，再跑 composer require vendor/name:v1.2.0 —— 如果报 Could not find package，大概率是私有源没生效或包名拼错
• 检查 auth.json 是否配置了私有源凭证，CI 环境和本地环境可能用不同 auth 方式（如 COMPOSER_AUTH 环境变量 or auth.json 文件）
• 私有 Packagist 页面上看不到新 Tag？回看该 Tag 对应的 commit 是否包含合法 composer.json，少一个字段（比如缺 autoload）就会被跳过，还不报错

Packagist 同步逻辑本身简单，但私有场景下每层都可能静默失效：Git Tag 推送漏掉、Webhook 配置错路径、composer.json 缺字段、私有源 URL 少斜杠、auth 凭证没透传……验证必须落到真实安装行为，而不是日志里的一行 success。