description字段是纯文本元信息，仅用于packagist页面、composer show输出和ide提示，不参与依赖解析；需以动词开头，含技术锚点，120字内精准传达功能、对象与约束。
description 字段不是可有可无的装饰，不填或乱填会导致 Packagist 搜索结果里根本没人知道你的包是干啥的——尤其当 name 是缩写（比如 laravel-uuid）时，空 description 等于扔进冷门区。
description 字段怎么写才有效
一句话说清「这个包解决什么问题」，别写「一个基于 XXX 的工具」这种无效信息。真实例子：
- ✅ 好的：
"Generates and validates ULID and UUID v4, zero framework dependencies" - ❌ 差的：
"A PHP library for generating UUIDs"（太泛，没区分度） - ❌ 错的：
"The best, fastest, zero-config UUID generator!"（Packagist 不渲染格式，营销话术纯占字数）
长度必须控制在 120 字符以内，超长会被截断；composer show 这类 CLI 工具通常只显示前 80 字左右，所以关键信息往前放。
keywords 字段为什么不能随便填
keywords 不校验格式，但 Packagist 用它加权搜索排序——填错等于主动降低曝光。常见错误：
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 重复包名或 vendor 名，比如
acme/http-client还填"acme"或"http-client" - 填无效泛词：
["php", "library", "tool"]—— 用户不会搜这些 - 漏掉真实搜索场景词，比如 HTTP client 类项目该填
["http", "psr-7", "guzzle", "curl", "async"] - 含空格或符号的词没加引号，比如
psr-7写成psr-7而非"psr-7"，JSON 直接解析失败
homepage 和 extra 字段怎么配合 description
homepage 是用户点击「详情」后最先看到的跳转地址，建议直接链向 GitHub 主页、文档首页或在线 README；extra 则适合放机器可读的扩展说明：
-
homepage必须是完整 URL，如"https://github.com/acme/http-client"，不能是相对路径或git@地址 -
extra不影响 Packagist 展示，但 CI/CD 或安装脚本可能读取，例如："extra": {"readme": "README.md", "support": {"issues": "https://github.com/acme/http-client/issues"}} - 如果
description无法承载定位说明（比如是某官方包的兼容替代），应在description里明确写「drop-in replacement for vendor/legacy-package」，再用replace字段声明关系
改完 description 后要验证和同步
改完 composer.json 不代表 Packagist 页面立刻更新：
- 先本地运行
composer validate --strict，检查 JSON 格式和字段层级是否合规（description必须和其他字段同级，末尾逗号不能多也不能少） - Packagist 只在你 push 新 tag 或手动触发 sync 时读取该版本的
composer.json，改完不打 tag = 白改 - 如果项目已发布，旧版本页面不会变；新 tag 对应的页面才会刷新
description和keywords
最容易被忽略的是：description 改了，但 keywords 还是默认的 ["php","library"]，或者 homepage 指向一个 404 页面——这些细节比字段是否存在更影响实际使用体验。
