Packagist 官方不支持自定义 Webhook，所谓“Webhook”实为 GitHub/GitLab 在 push 后主动调用 Packagist 更新接口；常见问题包括 404/403 错误、Last updated 显示 never，需检查仓库公开性、Packagist 账户授权及 GitHub Webhook 配置是否正确。
Packagist Webhook 为什么收不到推送？
Packagist 官方不支持自定义 Webhook，所谓“Packagist Webhook”本质是误传——它只在包被提交或更新时向 composer.json 中声明的 source（如 GitHub、GitLab）触发回调，而非直接推送到你的服务器。你看到的“自动更新”，其实是 GitHub/GitLab 在收到 push 后，主动调用 Packagist 的 https://packagist.org/api/update-package 接口完成的。
常见错误现象：404 Not Found 或 403 Forbidden 返回；Packagist 页面显示 “Last updated: never”；手动点击 “Update” 才生效。
- 确认你的
composer.json中repositories没有硬编码为vcs类型并指向私有地址——这会绕过 Packagist 自动发现逻辑 - 确保 GitHub 仓库是公开的，或已按 Packagist 提交指南 正确关联了账户（需登录 Packagist 并授权 GitHub）
- 检查 GitHub 的 Webhook 设置：Payload URL 必须是
https://packagist.org/api/update-package?username=xxx&apiToken=yyy，Content type 选application/json，Trigger 选 “Just the push event”
如何用 GitHub Action 替代 Packagist Webhook？
如果你用的是私有包、内部 GitLab、或需要更可控的更新时机（比如只在 tag 推送后更新），就得绕过 Packagist 的自动机制，改用 CI 触发更新请求。
关键点在于：Packagist 不验证 token 权限，只校验 username 和 apiToken 是否匹配你账户页面显示的值（Profile → API Token）。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- GitHub Action 中不要把
apiToken写死，用${{ secrets.PACKAGIST_API_TOKEN }}注入 - 请求必须带
User-Agent头，否则会被拒绝（Packagist 要求非空且含字母） - 推荐在
push事件的tags分支上触发，避免每次 commit 都调用接口
on:
push:
tags: ['v*.*.*']
jobs:
update-packagist:
runs-on: ubuntu-latest
steps:
- name: Notify Packagist
run: |
curl -X POST \
-H "User-Agent: my-deploy-script" \
-d '{"repository":{"url":"https://github.com/yourname/yourpkg.git"}}' \
"https://packagist.org/api/update-package?username=yourname&apiToken=${{ secrets.PACKAGIST_API_TOKEN }}"
Composer install 时为什么没拉到最新版？
即使 Packagist 显示 “Last updated: 2 minutes ago”，composer install 仍可能装旧版本——这不是 Webhook 问题，而是 Composer 的本地缓存和版本约束共同作用的结果。
-
composer install严格按composer.lock安装，不会查 Packagist；要更新必须先composer update vendor/package或删 lock 文件 - 如果
composer.json中写的是"vendor/package": "^1.2"，而新 tag 是v1.3.0，它会装；但如果是v2.0.0，默认不升级（语义化版本规则） - Packagist 的元数据同步有延迟，通常几秒到一分钟；可访问
https://repo.packagist.org/p/vendor/package.json直接看是否已更新
私有包怎么实现类似效果？
私有包无法提交到 Packagist，也就没有它的 Webhook 流程。真正可行的是搭建最小化镜像服务，或用 composer config repositories 指向 Git 地址 + 配合 CI 更新。
- 最轻量方案：在 Git 仓库根目录放一个
packages.json，内容为 Packagist 兼容格式，再用 Nginx 指向该目录；然后composer config repositories.myprivates vcs https://your-git.example.com/pkg - 别依赖
dist下载：私有 Git 仓库若未配置 SSH key 或 token，composer install会卡在Cloning failed；建议统一用https+auth.json管理凭证 - CI 中执行
composer update --no-interaction --with-dependencies并提交新composer.lock，比“自动更新 Packagist”对私有场景更可靠
Webhook 这个词在 Composer 生态里容易引发误解——它从来不是 Packagist 对外开放的入口，而是 GitHub/GitLab 单向通知 Packagist 的通道。真正要控制更新节奏，得从源头（代码仓库）和下游（项目 lock 文件）两端动手，而不是盯着那个不存在的“Packagist Webhook 设置页”。
