description 字段是 Packagist 展示包简介的唯一来源且强制要求，必须为120字符内纯文本字符串；keywords 为语义化搜索标签数组，影响 composer search 结果；readme 字段对 Composer 和 Packagist 无效，README 渲染仅依赖根目录文件。
Composer 项目描述信息不是可有可无的装饰，它直接影响 Packagist 显示效果、团队协作理解成本，以及某些自动化工具（如 composer show、composer search）的行为。关键字段必须手动写进 composer.json，没有自动生成机制。
description 字段：唯一强制要求的描述项
这是 Packagist 展示包简介的唯一来源，也是 composer show vendor/name 输出的第一行。不填则显示为空白或 “No description provided”，且 Packagist 拒绝同步（v2 起强制校验）。
- 必须是字符串，长度建议控制在 120 字符以内（Packagist 截断显示）
- 不能含换行符或 Markdown；纯文本，用于快速传达“这个包是干什么的”
- 示例：
"description": "A lightweight PSR-14 event dispatcher with no dependencies"
keywords 字段：影响搜索与归类的关键标签
它不参与 Packagist 主描述展示，但决定用户能否通过 composer search 或 Packagist 网站搜索到你的包。不是 SEO 关键词堆砌，而是语义化分类标签。
使用四维度框架评估任意 GitLab MR 或 GitHub PR 的复杂度：规模（20%），认知负荷（30%），审查工作量（30%），风险/影响（20%）...
- 数组类型，每个元素是小写、短词（如
"psr-14"、"event"、"dispatcher"） - 避免泛义词（如
"php"、"library"），优先选领域内公认术语 - 最多 5–6 个，过多会稀释相关性；顺序无关
- 示例：
"keywords": ["psr-14", "event-dispatcher", "events"]
readme 字段：不被 Composer 解析，但影响开发者第一印象
Composer 本身完全忽略 readme 字段（无论填什么都不会读取或验证）。Packagist 也只认根目录下的 README.md 文件。但很多人误以为加了这个字段就能控制 README 渲染——实际无效。
- 如果你看到别人写了
"readme": "README.md"，那是历史遗留或自定义工具链需要，对 Composer 和 Packagist 无意义 - 真正起作用的是文件系统中存在
README.md（或README.rst），且编码为 UTF-8 - Packagist 会自动抓取并渲染该文件首屏内容；无需在
composer.json中声明
license、type、homepage 字段：间接支撑描述可信度
它们本身不是“描述”，但在 Packagist 页面和 composer show 输出中紧邻 description 显示，共同构成项目基础画像。缺失任一都让项目显得不完整，尤其 license 是 Packagist 同步硬性要求。
-
license必须是 SPDX 标识符（如"MIT"、"Apache-2.0"），不能写成"MIT License"或自由文本 -
type推荐填写（如"library"、"wordpress-plugin"），影响 Packagist 分类和某些安装器行为 -
homepage应指向项目官网或文档页，而非 GitHub/GitLab 仓库首页（后者由source自动识别） - 示例片段：
"license": "MIT", "type": "library", "homepage": "https://example.com/my-package"
最容易被忽略的是：description 字段内容不会从 README 自动提取，也不会因 README 更新而变更；每次修改都必须手动同步更新 composer.json。很多团队发布后发现 Packagist 上简介还是旧的，根源就在这里。
