github仓库必须满足：根目录含composer.json且含合法name字段（vendor/name格式），有语义化版本tag（如v1.0.0），不提交vendor/、node_modules/或composer.lock。
想让别人通过 composer require 安装你的 PHP 包，核心就两步：把代码托管到公开 Git 仓库（如 GitHub），再在 Packagist 上提交这个仓库地址——Packagist 不托管代码，只索引和分发。
你的 GitHub 仓库必须满足什么条件？
Packagist 要能自动抓取并解析你的包，仓库得符合基本规范：
-
composer.json必须存在于仓库根目录，且包含至少name（格式为vendor/name，比如myname/http-client）、version或autoload字段 - 推荐使用语义化版本标签（如
v1.0.0、v2.1.3），Packagist 会自动识别带v前缀的 tag 作为版本 - 不要把
vendor/、node_modules/或composer.lock提交进仓库——它们对使用者无意义，还可能引发冲突 - 如果你用私有仓库（如 GitLab 私有项目或 Bitbucket 私有库），Packagist 无法直接索引，需手动配置 OAuth 或改用私有仓库管理器（如 Satis、Private Packagist）
如何在 Packagist 上提交并自动更新？
登录 Packagist 后，点击右上角 “Submit” 按钮，粘贴你的 GitHub 仓库 URL（如 https://github.com/yourname/my-package）。成功提交后，Packagist 会立刻抓取一次，并建立 webhook：
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 后续你 push 新 tag（如
git tag v1.2.0 && git push --tags），Packagist 会自动触发更新，无需人工干预 - 如果没自动更新，检查 GitHub 仓库 Settings → Webhooks 是否存在 Packagist 的 hook（URL 类似
https://packagist.org/api/github），缺失则手动重连（在 Packagist 包页点 “Update”） - 首次提交失败常见原因是
composer.json缺少name或格式错误，错误提示会直接显示在 Packagist 表单下方，注意看红字
国内用户要不要配镜像？怎么配才真正生效？
Packagist 官方源（https://packagist.org）在国内偶尔不稳定，但镜像只是加速下载，并不参与包的注册与发现流程：
- 镜像（如阿里云、腾讯云、华为云的 Packagist 镜像）只缓存已存在于 Packagist 上的包，你自己的新包不会“同步过去”，必须先在官方源上线
- 全局启用镜像只需一条命令：
composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ - 切勿在项目中同时配置多个镜像源（如既改 global 又在
composer.json写repositories），容易导致版本解析混乱或跳过自动更新 - 验证是否生效：运行
composer config --list | grep repo.packagist，输出应为镜像 URL，而非packagist.org
最关键的细节常被忽略：Packagist 不是上传平台，它不接受 zip 或 tar 文件；你每次修改 composer.json 后，必须打新 tag 并 push，否则用户 require 到的还是旧版本。别只改了文件却忘了发版。
