composer不提供打包功能，发布的是符合psr-4规范的git仓库；关键步骤为：写好composer.json（含合法name、autoload等）、推送到公开仓库、打v开头语义化tag（如v1.0.0）、提交url至packagist并启用自动更新。
Composer 本身不提供“打包”功能，它只是依赖管理器；你要发布的不是 zip 包，而是符合 PSR-4 自动加载规范的 Git 仓库，并通过 Packagist 做元数据索引。关键动作是：写好 composer.json、推到公开 Git 仓库、再提交给 Packagist。
确保项目结构和 composer.json 符合 Packagist 要求
Packagist 不拉取代码，只抓取你 Git 仓库根目录下的 composer.json，并据此索引包名、版本、自动加载规则等。常见失败原因就是这个文件缺失或字段不合法。
-
"name"必须是vendor/package格式（如"myorg/my-plugin"），且全小写、仅含字母数字、连字符和下划线 -
"type"建议设为"library"（非应用），Packagist 会据此分类，但非强制 -
"autoload"必须正确映射命名空间到目录，例如："autoload": { "psr-4": { "MyOrg\MyPlugin\": "src/" } } - 不要在
composer.json中写"require": { "php": "..." }以外的运行时依赖——除非你真要限制 PHP 版本；开发依赖（如 phpunit）应放在"require-dev"里
用 Git 管理版本，打带语义化标签的 release
Packagist 通过 Git 标签识别版本。它不读 composer.json 里的 "version" 字段（该字段会被忽略），只认 tag 名，比如 v1.0.0、v2.1.3。没有 tag 就没有稳定版。
- 确保 Git 仓库公开可访问（GitHub / GitLab / Gitee 等均可，但需允许 Packagist 抓取）
- 每次发布前，先提交全部变更，再执行：
git tag v1.0.0
- 推送 tag 到远程：
git push origin v1.0.0
（注意不是git push --tags，避免误推未审核的临时 tag） - Tag 名必须以
v开头（如v1.0.0），否则 Packagist 可能无法识别为稳定版本
提交到 Packagist 并启用自动更新
首次提交需手动操作，后续靠 webhook 自动同步。Packagist 不托管代码，只存元数据指针。
- 登录 packagist.org，点击右上角 “Submit”
- 填入你的 Git 仓库 URL（如
https://github.com/myorg/my-plugin），Packagist 会自动抓取最新composer.json并校验格式 - 提交成功后，在包页面点击 “Edit”，勾选 “Enable auto-updates”，然后按提示在 GitHub/GitLab 后台添加 Packagist Webhook（事件选
Pushes和Tag creation） - 之后每次
git push origin v1.0.1，Packagist 会在几分钟内自动拉取新 tag 并索引
本地测试安装是否正常
别等用户报错才验证。发布前务必用真实 Composer 命令模拟安装流程，重点检查自动加载和依赖解析。
- 新建空目录，运行：
composer require myorg/my-plugin:dev-main
（用dev-main测试默认分支） - 若报
Could not find package myorg/my-plugin，说明 Packagist 还没索引，或名字拼错；用composer clear-cache清缓存再试 - 安装成功后，进
vendor/myorg/my-plugin/检查文件结构是否完整，src/下类能否被MyOrgMyPluginSomeClass::class正确引用 - 如果类找不到，90% 是
autoload配置路径与实际目录不一致，或命名空间声明（namespace）和composer.json中定义不匹配
最容易被跳过的环节是：没打 tag 就去 Packagist 提交，或者打了 tag 却忘了 git push origin <tag></tag>。Packagist 页面显示 “No releases” 就是这个原因。另外，composer.json 里写错 vendor 名，会导致整个包无法被 require——因为名字一旦注册，就不能改，只能删包重来。
