packagist 认出 github 仓库需满足：根目录有 composer.json，且 name 字段为小写短横线格式（如 myorg/laravel-helper）；打语义化版本 tag（如 v1.0.0）才能被安装；autoload 必须正确配置 psr-4 或 files 并运行 composer dump-autoload。
怎么让 Packagist 认出你的 GitHub 仓库
Packagist 不会自动扫描 GitHub，它只认你手动提交的仓库地址，而且必须满足两个硬条件：composer.json 存在、且 name 字段格式合法（形如 vendor/name，不能带下划线或大写字母）。
常见错误现象：Package not found 或提交后显示 “This package is not auto-updated”，本质是 Packagist 根本没解析成功。
- 确保
composer.json在仓库根目录，不是子文件夹里 -
name必须全小写、用短横线分隔，比如myorg/laravel-helper合法，MyOrg/LaravelHelper或myorg_laravel_helper都会被拒 - 如果之前提交失败过，改完
composer.json后得去 Packagist 页面点 “Update” 手动触发重抓，不会自动轮询
为什么 composer install 装不到你刚发布的包
刚提交到 Packagist 并不等于立刻能装——Packagist 默认只索引 stable 版本，而新仓库首次发布时，所有 tag 都默认被识别为 dev-main（或 dev-master），不属于稳定版本。
使用场景：你在本地 composer require myorg/mypackage 报错 Could not find package myorg/mypackage，其实它已在 Packagist 列表里，只是没标 stable。
- 必须打一个符合语义化版本规范的 tag，比如
v1.0.0、v0.5.2，不能是1.0或release-1 - tag 推送到 GitHub 后，等 Packagist 自动抓取（通常几分钟），或手动点 “Update”
- 临时调试可用
composer require myorg/mypackage:dev-main，但生产环境别这么干
如何避免 autoload 失效导致类找不到
发布后 composer require 成功，但一调用就 Class not found，八成是 autoload 配置没对上——Composer 不会自动猜你源码在哪。
参数差异：用 "psr-4" 还是 "files"？取决于你的结构。PSR-4 要求命名空间与目录严格对应；files 适合单文件函数库，每次加载都 include。
- 如果代码在
src/目录下，且命名空间是MyOrgMypackage，autoload得写："psr-4": {"MyOrg\Mypackage\": "src/"} - Windows 下路径斜杠方向不影响，但反斜杠在 JSON 里要双写：
"MyOrg\Mypackage\" - 改完
composer.json后，本地测试前必须运行composer dump-autoload，否则缓存还是旧的
私有包或非 GitHub 仓库怎么处理
Packagist 只支持公开的 GitHub、GitLab、Bitbucket 仓库，且必须能被公网访问。如果你用 Gitee、自建 Git 服务，或想限制安装权限，Packagist 就不适用了。
性能 / 兼容性影响：绕过 Packagist 意味着用户得手动加 repositories 配置，还可能遇到 HTTPS 证书、SSH key、token 权限等问题。
- 最简方案：在项目
composer.json的repositories里加一条 typevcs的记录，指向你的 Git 地址 - 企业级方案：搭私有 Packagist（如 Private Packagist）或 Satis，但维护成本明显上升
- 别把敏感配置（如 API key）写进
composer.json，它会被所有人看到——用config.json或环境变量替代
最容易被忽略的是版本号和 autoload 命名空间的一致性：tag 是 v1.0.0，但 src/ 下的文件命名空间写成 MyOrg\V1\Helper，Composer 就找不到类——它不看 tag，只认 composer.json 里写的映射关系。
