以下是对您提供的博文内容进行深度润色与结构重构后的技术文章。我以一位资深搜索架构师 + Spring Boot 实战派博主的身份，摒弃模板化表达、AI腔调和教科书式罗列，用真实项目中的思考节奏、踩坑经验与系统直觉重写全文——不讲“是什么”，只说“为什么这么干”和“不这么干会怎样”。
一次搜索请求背后：Spring Boot 如何把 Elasticsearch 变成你手边的“搜索扳手”
“不是所有搜索都叫搜索。”
——某电商中台凌晨三点的告警群里，一位运维发了这样一句话。
那晚，用户搜“AirPods Pro”，返回结果里混进了“苹果手机壳”；运营后台批量上架商品后，搜索延迟飙升到 2.3 秒；日志平台查个 ERROR 关键词，Kibana 页面卡住半分钟……
这不是 ES 不行，是我们没把它当成一个需要被“驯服”的分布式系统来对待。
Spring Boot 让集成变得简单，但也正因太简单，很多人在application.yml里填完spring.elasticsearch.rest.uris就以为万事大吉。而真正的搜索服务，从来不是“连上就能用”，而是在数据建模、查询语义、资源水位、故障边界之间持续做权衡的艺术。
这篇文章，就带你从一次真实的搜索请求出发，拆解 Spring Boot 与 Elasticsearch 协同工作的真实脉络——不堆概念，不列参数，只讲你在上线前夜最该问自己的那几个问题：
- 为什么中文分词总不准？真的是 IK 插件的问题，还是 mapping 设计埋了雷？
- 为什么加了
@Query还是慢？DSL 写对了，但有没有人告诉你track_total_hits默认是 true？ - 为什么滚动索引后新数据搜不到？别急着骂集群，先看 alias 指向对不对。
- 为什么压测时连接池爆满？不是配置小了，是你根本没理解
RestHighLevelClient的连接复用模型。
我们不造轮子，也不复述手册。我们只还原一个有经验的工程师，在面对搜索功能交付压力时，真正会做的决策链。
一、别急着写 Repository：先想清楚你的“文档”长什么样
很多团队一上来就extends ElasticsearchRepository<Product, String>，然后发现搜索结果乱序、高亮错位、甚至字段根本搜不到。问题往往不出在代码，而在对 Lucene 文档模型的理解偏差。
Elasticsearch 不是数据库。它没有“行”和“列”的概念，只有Document → Field → Term这一条链路。而每个Field的行为，由三样东西共同决定：
| 组件 | 作用 | 常见陷阱 |
|---|---|---|
type（字段类型） | 决定该字段能否被搜索、排序、聚合 | 把price设为text→ 无法 range 查询；把status设为keywo |
