Go mod 好菜系列 - 0x1D meilisearch-go 这盘搜索菜不一定非得上大铁锅
详细聊 meilisearch-go 在站内搜索和轻量全文检索场景里的定位、它和数据库模糊查询的差别，以及什么时候没必要一上来就冲 Elasticsearch。
很多业务一开始的搜索都很朴素：数据库里来个 LIKE %keyword%，能跑就先跑。可只要数据量慢慢上来，搜索体验要求变高，大家就会很快发现数据库并不是天生的全文搜索选手。这个时候很多人第一反应是 Elasticsearch，但其实有些项目并不需要一上来就扛那口大铁锅。meilisearch-go 这类轻量方案就很适合先上桌。
它适合什么场景
- 博客和文档站站内搜索
- 中小型商品或内容搜索
- 后台管理系统的全文检索增强
- 对搜索体验有要求，但运维复杂度不想太重
它特别适合那些“搜索已经重要了，但还没重要到值得上一整套重型平台”的项目。
它和数据库模糊查询差在哪
不只是快一点，而是心智模型不一样。数据库更擅长结构化过滤，搜索引擎更擅长相关性、分词、排序和搜索体验。你一旦开始关心拼写容错、结果排序、关键词高亮，这条线就已经开始偏向搜索引擎了。
为什么 meilisearch 会被喜欢
- 接入相对轻
- 体验上手快
- 对很多中小场景已经够用
- 不像重型搜索平台那样一上来就全套运维负担
对很多产品来说，搜索能力不是没有价值，而是“不值得为了第一版搜索系统就背太重的成本”。
它最适合放在哪一层
通常作为检索侧基础设施存在。业务系统负责把需要检索的数据同步进去，查询时再从搜索系统拿回结果。也就是说，别把它看成数据库替代品，而要把它当成“搜索视图系统”。
建立索引和查询的参考代码
client := meilisearch.New("http://127.0.0.1:7700", meilisearch.WithAPIKey("masterKey"))
index := client.Index("posts")
_, err := index.AddDocuments([]map[string]any{
{"id": 1, "title": "Go mod 好菜系列", "content": "对象存储和任务调度"},
{"id": 2, "title": "Golang 从入门到放弃", "content": "切片和 map"},
})
if err != nil {
log.Fatal(err)
}
result, err := index.Search("对象存储", &meilisearch.SearchRequest{
Limit: 10,
})
if err != nil {
log.Fatal(err)
}
fmt.Println(result.Hits)这种例子最能说明 meilisearch 的定位：数据还是你的业务系统在管，搜索系统负责建立索引和返回更像搜索结果的答案。
什么时候别急着上 Elasticsearch
- 索引规模还不大
- 查询模型还比较单纯
- 团队没有太多搜索系统运维经验
- 只是需要一个明显好于 LIKE 的搜索体验
这类时候，先用更轻的方案往往更明智。不是因为 Elasticsearch 不好，而是很多团队的问题规模还没大到要它那整套武器。
什么情况下它又可能不够
如果你的搜索需求已经涉及非常复杂的聚合、分析、超大规模索引、多维查询和深度定制相关性，那轻量方案就会开始吃力。技术选型最怕的不是“选轻了”，而是还没到那个复杂度就先把自己压垮了。
小结
meilisearch-go 这盘菜很适合收尾这一阶段：
- 它适合中小型全文搜索和站内搜索
- 比数据库模糊查询更像真正的搜索体验
- 比重型搜索平台更轻巧，接入成本更友好
- 但大规模复杂搜索场景下也别勉强它