description字段应一句话说清包用途，如“生成并验证ULID和UUID v4的轻量工具，无框架依赖”，控制在120字符内，避免营销话术与空描述。
composer.json 里 description 字段怎么填才有效
description 字段只影响 Packagist 页面展示和搜索匹配，不参与依赖解析或安装逻辑。它不是必填项，但空着会让包在搜索结果里缺乏上下文，尤其当包名缩写较多（比如 laravel-uuid）时，别人根本猜不出用途。
- 用一句话说清「这个包是干什么的」，别写「一个基于 Laravel 的 UUID 工具」这种废话，直接写「生成并验证 ULID 和 UUID v4 的轻量工具，无框架依赖」
- 避免营销话术：删掉「最强大」「零配置」「业界领先」——Packagist 不会渲染加粗，也不支持 Markdown
- 长度控制在 120 字符内，超长会被截断，且部分 CLI 工具（如
composer show）只显示前 80 字左右
name 字段命名不规范会导致 autoload 失败
Composer 用 name 字段推导 PSR-4 自动加载的根命名空间，不是随便起个名就行。比如你写 "name": "mytool/core"，但 autoload 配置的是 "MyTool\Core\": "src/"，那 Composer 就会报错 Class MyToolCoreSomething not found —— 因为它默认按 name 拆解命名空间，mytool/core → MytoolCore（注意大小写），而你写了 MyTool，首字母大写不一致就对不上。
- 确保
name全小写、用短横线分隔，比如"name": "acme/http-client" - 对应
autoload中的命名空间必须严格匹配转换规则：acme/http-client→AcmeHttpClient（驼峰，短横线变大驼峰，斜杠变反斜杠） - 本地开发时如果改过
name，记得删掉vendor/重装，否则旧 autoload 文件仍保留错误映射
keywords 字段影响 Packagist 搜索排序但不校验格式
keywords 是纯字符串数组，Composer 不做任何语法检查，但 Packagist 会用它加权搜索结果。填错关键词等于主动把自己埋进冷门区。
- 选 3–5 个真实用户可能搜的词，比如 HTTP client 场景下填
["http", "curl", "psr-7", "guzzle", "async"]，而不是["php", "library", "tool"]这种无效泛词 - 不要重复包名或 vendor 名，
acme/http-client再写"acme"或"http-client"是冗余 - 大小写不影响，但建议全小写保持统一；含空格的词（如
"psr-7"）必须带引号，否则 JSON 解析失败
type 字段填错会让项目无法被正确归类
type 决定 Packagist 上的分类标签（比如 “library”、“wordpress-plugin”、“metapackage”），也影响某些工具链行为。填成 "type": "project" 看似合理，但这是给根项目（如 Laravel 应用）用的，你的可复用包必须填 "library"，否则 Packagist 不会把它当可安装组件展示。
- 绝大多数通用包用
"type": "library"，这是默认值，可省略，但显式写出更稳妥 - WordPress 插件必须填
"wordpress-plugin"，且需配合extra.wordpress-install-dir才能被 WP-CLI 正确识别 - 填了不存在的 type（比如
"foo-bar"）不会报错，但 Packagist 会标为 “unknown”，失去分类优势
description 和 keywords 看似只是“面子工程”，但 Packagist 搜索没高级筛选，用户就靠这两项判断要不要点进来。name 和 type 则是底层绑定点，一错就导致 autoload 失效或包不可见——这些地方改起来快，但排查时最容易卡在“为什么类找不到”“为什么搜不到我的包”这种模糊问题上。
