keywords应填3–5个精准小写词如["laravel","logging","monolog"]，避免泛化堆砌；更新后需等待Packagist爬虫重索引（几小时至一天），并确保name、description、type等字段协同表达核心功能。
composer.json 里 keywords 字段怎么填才有效
填了 keywords 却没提升包在 Packagist 上的搜索曝光？问题大概率出在“堆砌”或“泛化”。Packagist 的搜索不是全文匹配，而是基于关键词权重 + 包名 + 描述的协同排序，keywords 只起辅助作用，但填错反而稀释相关性。
实操建议：
- 只写 3–5 个最精准、用户真会搜的词，比如一个 Laravel 日志增强包，填
["laravel", "logging", "monolog", "audit"]比填["php", "package", "tool", "dev"]有用得多 - 避免大小写混用或复数/单数不一致（Packagist 不做标准化归一），统一用小写、常用形式，如用
"cache"而非"caching" - 不要重复包名或 vendor 名——
myvendor/laravel-logger里再写"laravel-logger"是冗余，系统已自动提取 - 别塞长尾词或句子，
keywords是字符串数组，不是描述字段，"log to slack"这类无效
为什么改了 keywords 但 Packagist 搜索没变化
不是配置没生效，是 Packagist 不实时索引。关键词更新后需触发重新抓取，而这个动作依赖 packagist.org 的 crawler 周期性扫描（通常几小时到一天），手动刷新无效。
常见错误现象：
- 本地
composer.json改了keywords，直接git push后立刻去 Packagist 搜——搜不到，因为还没 reindex - 在 Packagist 页面点 “Update” 按钮失败，提示 “No new commits”，其实是仓库 webhook 没配好或 token 权限不足
- 用了私有 Packagist 镜像，但镜像源未同步 keywords 字段（部分老旧镜像忽略该字段）
验证是否生效：等 24 小时后，访问 https://packagist.org/packages/{vendor}/{package}，看页面右侧 “Keywords” 栏是否更新；也可用 API 直查：curl https://packagist.org/p2/{vendor}/{package}.json | jq '.packages."{vendor}/{package}"[0].keywords'
keywords 和 description 的分工误区
很多人把 description 当简介，把 keywords 当标签，结果两头都弱。其实 Packagist 搜索时，description 的文本匹配权重远高于 keywords，尤其前 100 字。
正确做法：
-
description开头必须包含 1–2 个核心关键词 + 动词短语，例如："Laravel package for rate limiting API endpoints using Redis"—— “laravel”、“rate limiting”、“api”、“redis” 全部自然嵌入 -
keywords补充 description 里没显式出现、但用户可能搜的变体或上下文词，比如["throttle", "api-limit", "redis-lock"] - 别让 keywords 成为 description 的缩写版，二者应有信息差：description 说“做什么”，keywords 说“谁会搜什么词来找它”
影响搜索权重的其他关键字段（比 keywords 更重要）
盯着 keywords 优化，就像调亮度却不管电源——真正决定能否被搜到的，是这几个字段的组合效果：
-
name：必须含主技术栈或领域，laravel-scout-algolia比algolia-search在 Laravel 圈子中更容易被发现 -
type：设为laravel-package、wordpress-plugin等官方认可类型，能进分类筛选，间接提升曝光 -
require里的约束：声明"illuminate/support": "^10.0"比"php": ">=8.1"更能关联到 Laravel 生态搜索场景 - GitHub 仓库的
topics：Packagist 会抓取，且 topics 支持空格和短横线（如laravel-10），比 keywords 更灵活，别忽略
keywords 是拼图最后一块，不是地基。地基是 name + description + type + require 的协同表达——写清楚你服务谁、解决什么具体问题，比塞十个词管用得多。
