必须先创建公开GitHub仓库并配置合规composer.json，再打合法Git tag（如v1.0.0）推送，最后提交仓库URL至Packagist索引；name需为vendor/name格式、autoload和license必填且正确，否则索引失败。
不能直接“创建包”再“发布到 Packagist”——Packagist 不托管代码，只索引 Git 仓库；你必须先有公开的 Git 仓库（如 GitHub），且该仓库包含合法的 composer.json，Packagist 才能抓取并收录。
怎么写一个可被 Composer 安装的 composer.json
这是整个流程的起点，也是最容易出错的一环。不是随便放个 JSON 就行，Packagist 会校验基础字段是否合规：
-
name必须是vendor/name格式（如myname/my-awesome-package），且全小写、只含字母/数字/-/_；vendor名需与你在 Packagist 的用户名一致 -
type推荐设为library（除非是插件、wp-plugin 等特殊类型） -
autoload必须配置，否则别人require后无法自动加载你的类；最常用的是"psr-4": {"MyName\MyAwesomePackage\": "src/"} -
license必须明确（如"MIT"），空值或模糊值（如"proprietary"）会导致 Packagist 拒绝索引 - 不要写
repositories字段——那是使用者的配置，不是包自身的声明
为什么 GitHub 仓库要公开 + 有 Git tag 才能被 Packagist 正确识别
Packagist 不拉取 main 分支最新代码，它靠 Git tag 版本号（如 v1.0.0、1.0.0）来生成可用版本。没有 tag，Packagist 就只显示 “No releases found”，用户也 install 不到任何稳定版：
- 本地打 tag：运行
git tag -a v1.0.0 -m "First stable release" - 推送到 GitHub：运行
git push origin v1.0.0（注意不是git push --tags，后者可能推送太多旧 tag） - Packagist 默认每 15 分钟轮询一次；也可手动在 Packagist 页面点击 “Update” 强制抓取
- tag 名必须符合 Composer 版本约束规则（如不支持
1.0，要写成1.0.0或v1.0.0）
提交到 Packagist 的实际操作与常见失败原因
登录 Packagist（用 GitHub 账号授权），点击右上角 “Submit” → 粘贴你的 GitHub 仓库 URL（如 https://github.com/myname/my-awesome-package）。接下来不是“上传”，而是“请求索引”：
- 如果提示 “This package is not on GitHub, Bitbucket or GitLab”，检查 URL 是否拼错，或仓库是否设为私有
- 如果提示 “Could not fetch … composer.json”，说明仓库根目录没有
composer.json，或文件语法错误（可用composer validate本地检查） - 如果提交成功但版本为空，大概率是没打合法 tag，或 tag 未推送到远程
- Packagist 不允许重复提交同一仓库；删了再重提前，先去仓库 Settings → Webhooks 删掉旧的 Packagist hook
发布后还要注意什么
很多人以为提交完就结束了，其实后续维护才是关键：
- 每次发新版，必须打新 tag 并推送，否则 Packagist 不会自动更新版本列表
- 修改
composer.json后（比如加依赖），必须重新打 tag —— Packagist 抓取的是 tag 对应快照，不是动态读取主分支 - 若想让别人
composer require myname/my-awesome-package成功，你的autoload路径和命名空间必须与实际 PHP 文件结构严格匹配，否则报Class not found - Packagist 不提供私有包支持；要做内网或私有包，得用 Satis、Private Packagist 或 GitHub Packages 配合自建
repositories
