Composer包无人安装的主因是自动加载配置错误、Packagist同步失败（需合规tag与绑定账号）、require-dev/suggest被误用，以及README缺乏首行安装命令和可运行示例。
为什么你的 Composer 包没人 install
常见现象：composer require vendor/name 执行失败，或装上了却报 Class not found、Cannot declare class。根本原因往往不是配置写错，而是自动加载没对上 PSR-4 的预期路径结构。
实操建议：
- 确保
composer.json中"autoload"指向真实目录，例如"src/"，且该目录下有对应命名空间的子目录（如src/Http/Client.php对应Vendor\Package\Http\Client） - 运行
composer dump-autoload -o后再测试，避免因 autoload 未刷新导致类找不到 - 不要在
src/外另建lib/或classes/目录——Composer 默认不扫描它们，除非显式声明
packagist.org 同步失败的三个硬性条件
你 push 到 GitHub 后，Packagist 没自动更新？不是 webhook 失效，而是它只认三种触发方式：
- GitHub/GitLab 仓库设为 public，且包含合法
composer.json - Packagist 账户已绑定对应平台账号，并手动 submit 过一次该仓库 URL
- 新 tag 必须符合语义化版本格式，如
v1.0.0、1.2.3；dev-master或latest不会被识别为有效版本
注意：composer.json 里的 "version" 字段已被弃用，Packagist 完全忽略它——版本完全由 Git tag 决定。
require-dev 和 suggest 的真实作用被严重误读
"require-dev" 不是“开发时才需要”，而是“只有在你 clone 这个包源码、准备改它时才需要”。下游项目 composer require vendor/name 时，里面定义的 phpunit、mockery 全部不会装。
"suggest" 更不是推荐依赖——它是纯文本提示，Composer 不解析、不安装、不校验。比如 Laravel 包写 "symfony/console": "For CLI command support"，只是给人看的说明。
真正影响下游使用的，只有 "require" 下列出的运行时依赖。少写一个 "ext-json": "*"，就可能让 PHP 7.4 用户直接报错退出。
“爆款”的关键其实是 README.md 里的一行命令
用户打开你的 GitHub 页面，3 秒内没看到清晰的 composer require + 两行调用示例，大概率关闭页面。这不是文案问题，是注意力经济学。
实操建议：
- README 第一行必须是
composer require vendor/name，别加任何前缀（如 “Install via:”） - 紧接着给一个最小可运行片段，比如
$client = new \Vendor\Name\Http\Client(); $client->get('https://api.example.com');，且确保命名空间和类名与 autoload 严格一致 - 删掉所有“欢迎贡献”“感谢支持”类话术——开源项目的信任感来自可立即验证的行为，不是礼貌用语
最常被忽略的一点：你的包是否真的解决了别人 vendor/bin/phpunit 运行失败时的某个具体错误？还是只是又一个“我觉得挺好”的轮子？
