packagist不会自动发现包，必须手动提交公开仓库url并配置github webhook；name须为小写vendor/name格式且vendor与账号一致，tag必须带v前缀（如v1.0.0），composer.json需在根目录且含合法autoload映射。
直接发到 Packagist 就能被全球 Composer 项目 require，但前提是包已托管在 GitHub/GitLab 等公开 Git 仓库、打了带 v 前缀的语义化标签（如 v1.0.0），且 composer.json 中的 name 字段格式正确（vendor/name）——缺一不可。
怎么让 Packagist 自动发现你的包
Packagist 不爬代码，只认“注册请求”或“Webhook”。最稳的方式是手动提交：访问 https://www.php.cn/link/20a1f94e0e45384e8e08872de5a5e545，粘贴你的 Git 仓库 URL（必须是 HTTPS，且公开可读）。提交后，Packagist 会立刻抓取该仓库的 composer.json，并索引所有带 v 前缀的 Git tag。
- URL 必须指向根目录含
composer.json的仓库，不能是子目录或裸 Git URL（如git://） - 第一次提交后，后续新 tag（如
v1.0.1）会自动同步，无需再点提交——前提是 Webhook 已配置（GitHub/GitLab 页面里连上 Packagist 账号即可） - 如果提交后显示 “Package not found”，先检查：
git tag -l是否真有v1.0.0这样的 tag；git push --tags是否已推送到远端
为什么 composer require vendor/name 找不到包
不是 Packagist 没收录，就是本地环境卡在中间层。常见断点：
-
composer.json里name写成myname/mylib，但 Git 仓库地址是https://github.com/myname/my-lib—— 名字不一致，Packagist 拒绝关联 - 打了
1.0.0标签，没加v前缀；Packagist 只认v1.0.0、v2.1.3这类 - 本地运行了
composer clear-cache，但没跑composer update或composer require vendor/name:dev-main—— 缓存清了，但 lock 文件和 vendor 没更新 - 公司网络拦截了
packagist.org，而你又没在composer.json里显式声明"packagist.org": false和私有源兜底
发布前必须验证的三件事
别等别人 require 失败才回头查。本地就能快速验：
- 用
composer validate检查composer.json语法和字段合规性（比如autoload是否映射到真实存在的目录） - 删掉本地
vendor/和composer.lock，执行composer install --no-dev—— 看是否真能干净装进 vendor 并自动加载类 - 写个最小测试文件（如
test.php）：require 'vendor/autoload.php'; echo class_exists('Vendor\Name\SomeClass') ? 'OK' : 'FAIL';，直接运行确认类存在
私有包不能走 Packagist，但流程一样
想只给内部项目用？把“发布”换成“接入私有 Packagist”（如 Satis 或 Private Packagist）。操作几乎一致：Git 仓库照常打 v1.0.0 标签 → 私有服务扫描该仓库 → 主项目 composer.json 加 repositories 指向内网地址 → require。唯一关键差异是：私有服务不会自动监听 Webhook，得手动触发 rebuild 或配定时任务拉取新 tag。
最容易被忽略的是权限和路径匹配——autoload 里的命名空间必须和 src/ 下实际文件路径严格一致，哪怕大小写错一个字母，class not found 就立刻出现，跟发布平台无关。
