packagist不托管代码且不自动扫描github，包必须满足三个硬条件才能被正常安装：公开仓库根目录有合法composer.json、name字段为小写vendor/package格式且与账号一致、打了带v前缀的语义化git tag（如v1.0.0）。
Packagist 不托管代码，也不自动扫描 GitHub；你提交的包必须同时满足三个硬条件才能被正常安装：公开仓库根目录下有合法 composer.json、name 字段格式正确、打了带 v 前缀的语义化 Git tag（如 v1.0.0），缺一不可。
composer.json 必须在公开仓库根目录且字段合法
Packagist 只读取默认分支（main 或 master）根目录下的 composer.json，且首次抓取仅校验 name、type、autoload 三项。常见错误包括：
-
name含大写字母（MyOrg/http-client❌）、下划线（myorg/http_client❌）或 vendor 名与 Packagist 账号不一致（你在 Packagist 注册的是myorg，但写成yourorg/my-package❌） -
type留空或误设为project（普通库必须是library） -
autoload.psr-4映射末尾漏反斜杠（"MyOrg\Http": "src/"✅，"MyOrg\Http": "src"❌） - 本地验证用
composer validate，报错就别提交——Packagist 不会告诉你哪一行错，只显示Invalid package information
Git tag 必须带 v 前缀且显式推送
Packagist 完全忽略 composer.json 中的 version 字段，只认 Git tag 名。没 tag 就只有 dev-main，用户执行 composer require myorg/my-package 会直接报 Could not find package。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- tag 名必须符合语义化版本规范：
v1.0.0✅，1.0.0❌，v1.0.0-beta❌（不稳定版默认不被拉取） - 打完 tag 后必须显式推送：
git push origin v1.0.0，不是git push --tags（可能混入旧 tag 干扰解析） - 打 tag 的 commit 里，
composer.json必须已提交且合法，否则 Packagist 抓到的是空配置
GitHub webhook 必须配对且生效
2023 年底起 Packagist 彻底关闭自动发现，手动 Submit 只触发一次抓取。之后你推新 tag，Packagist 不会自动感知——除非 webhook 已生效。
- 进 GitHub 仓库 →
Settings→Webhooks→Add webhook - Payload URL 填
https://packagist.org/api/github（注意不是旧地址） - Event 类型勾选
Tag push events（仅推 tag 时触发，更精准） - 去
Recent Deliveries查状态码，200才算通；若失败，只能手动点 Packagist 包页右上角Update补救
最易被忽略的一点：首次提交失败后，Packagist 不会自动重试——哪怕你改了 composer.json 或打了新 tag，也得去包页点 Update 才能重新抓取。别等用户反馈“装不了”，先自己点一下。
