name字段必须为vendor/package格式且vendor须与packagist账号一致，package全小写并用短横线分隔；autoload.psr-4命名空间前缀须严格匹配src/路径；tag需推送至远程且符合语义化版本规范；本地应先运行composer validate和require dev-main验证。
name 字段必须是 vendor/package 格式，且 vendor 要和 Packagist 账号一致
Packagist 不认人，只认 name 字段——它就是你在整个 PHP 生态里的“身份证”。写错就搜不到、装不上，连提交都会被拒。
-
vendor通常是你的 GitHub 用户名（比如myname），不能是邮箱、项目名或随便起的代号 -
package必须全小写，用短横线分隔单词（json-helper✅，JsonHelper❌） - 整个字段只能含小写字母、数字、短横线（
-）、下划线（_）、点号（.）和斜杠（/），不能有空格、大写、@、# 等 - 如果
name是myname/my-awesome-package，但你在 Packagist 注册的是myname2，那别人composer require myname/my-awesome-package就会失败——Packagist 不会帮你做映射
autoload 配置错，require 成功但一调用就 Class not found
这是发布后最常被反馈的问题：用户说“装上了”，但 new MyPackageHelper() 直接报错。根本不是 Composer 没装，而是自动加载没对上。
-
autoload.psr-4的命名空间前缀必须和src/下实际类文件路径严格对应，比如："MyName\MyAwesome\": "src/"，那src/Helper.php就得声明namespace MyNameMyAwesome; - 别漏掉末尾反斜杠（
）——"MyName\MyAwesome"（少一个）和"MyName\MyAwesome\"（多一个）都会失效 - 本地验证最快方式：
composer dump-autoload -d ./test-project，再在测试项目里require后var_dump(class_exists('MyName\MyAwesome\Helper'))
打 tag 不推，Packagist 就永远看不到“正式版”
Packagist 不看分支，只认 Git tag。你 push 了代码、也提交了仓库 URL，但页面一直显示 No releases found，八成是忘了这步。
- tag 名必须是语义化版本，推荐带
v前缀：v1.0.0、v2.1.3-beta.1（1.0.0也能识别，但不保险） - 命令要两步都执行：
git tag v1.0.0→git push origin v1.0.0（只git push不带--tags或指定 tag，远程就没有） - GitHub 页面上点开 “Releases” 标签页，必须能看到
v1.0.0这个 tag，且能点进去看到对应 commit —— 这才是 Packagist 能抓到的信号
别跳过 composer validate 和本地 require dev-main 测试
很多人卡在 Packagist 提交失败却不知原因，其实错误早藏在本地。等提交完再查，来回折腾更耗时。
- 运行
composer validate，它会检查 JSON 语法、必填字段缺失、name格式、license 是否合法等，比 Packagist 报错更早、更具体 - 别等 Packagist 同步完才测安装，先建个空目录：
mkdir test && cd test && composer init -n && composer require yourname/your-package:dev-main，立刻验证 autoload 和基础调用 - 如果
dev-main都加载失败，v1.0.0更不会好——版本只是标签，底层结构没变
Packagist 本身不托管代码，也不校验逻辑，它只做三件事：读 composer.json、找 tag、暴露接口。真正决定“能不能用”的，是你本地那一份配置是否经得起推敲。最容易被忽略的，其实是把 src/ 和命名空间对齐这件事——写错一个反斜杠，用户就得翻源码找 bug。
