Elasticsearch数据写入后无法立即查询，因默认1秒refresh间隔，数据先存内存缓冲区，需refresh后才生成可搜索段；Webman同步调用index()成功不等于可搜，常见误判为空结果。
为什么 Webman + Elasticsearch 组合容易卡在“写入后搜不到”
因为 Elasticsearch 默认 refresh_interval 是 1 秒，数据写入内存 buffer 后不会立刻可查；而 Webman 是同步 HTTP 框架，client->index() 返回成功 ≠ 文档已可搜索。很多开发者在插入文档后立刻调用 search()，结果返回空，误以为写入失败。
常见错误现象："hits": {"total": {"value": 0, "relation": "eq"}, "hits": []}，但用 GET /my_index/_doc/1 能查到文档 —— 这说明文档已存，只是没刷新进可搜索段。
- 临时解决：写入后手动触发
POST /my_index/_refresh（仅限开发/测试） - 生产环境别这么干：频繁 refresh 会生成大量小 segment，拖慢查询和 merge 压力
- 更合理做法：前端加 loading 状态，或业务逻辑接受「最多 1 秒延迟」——这是 ES 近实时的正常表现
- 若真需要强一致性（如订单状态页），应把关键字段存在 MySQL，ES 只做非核心检索
Webman 中如何正确配置 Elasticsearch 客户端
直接用官方 elasticsearch-php 客户端即可，但要注意两点：连接池复用和超时设置。Webman 是常驻内存的 Swoole 应用，不能每次请求都 new 一个 client，否则会快速耗尽 TCP 连接或触发 Too many open files。
推荐做法是在 config/container.php 中注册单例：
use Elasticsearch\ClientBuilder;
return [
'elasticsearch' => function () {
return ClientBuilder::create()
->setHosts(['http://127.0.0.1:9200'])
->setRetries(2)
->setConnectionPool('\Elasticsearch\ConnectionPool\StaticNoPingConnectionPool')
->build();
}
];
- 必须设
setRetries(2)：避免单个节点临时不可用导致整个请求失败 - 禁用 ping（
StaticNoPingConnectionPool）：Swoole 下 ping 会阻塞协程，且 ES 集群健康状态应由外部监控保障 - 不要设
setTimeout()过短（如 100ms）：ES 查询可能因 segment merge、冷热分片调度等临时变慢，建议设为500–1000ms - 如果启用了 HTTPS 或 Basic Auth，记得加
->setSSLVerification(false)和->setBasicAuthentication('elastic', 'xxx')
中文分词失效？检查 IK 插件是否真正生效
装了 IK 插件，但 match 查询还是分不出“搜索引擎” → “搜索”、“引擎”，大概率是索引创建时没指定 analyzer，或者用了默认 standard 分词器。
Webman 2.2.0版本强化了 TCP/UDP 服务支持，优化路由组管理，并增强异步任务处理能力。结合协程与连接池技术，Webman 能轻松应对高并发场景，适用于网站、接口服务、即时通讯、物联网及游戏开发，兼具高性能、灵活扩展与稳定可靠，是多场景 PHP 服务开发的理想选择。
关键点不在插件安装，而在 mapping 定义。例如创建索引时必须显式声明：
PUT /articles
{
"settings": {
"analysis": {
"analyzer": {
"ik_smart_analyzer": {
"type": "custom",
"tokenizer": "ik_smart"
}
}
}
},
"mappings": {
"properties": {
"title": { "type": "text", "analyzer": "ik_smart_analyzer" },
"content": { "type": "text", "analyzer": "ik_max_word_analyzer" }
}
}
}
- IK 提供两个 tokenizer：
ik_smart（粗粒度，适合标题）、ik_max_word（细粒度，适合正文）——混用会导致 query 和 index 分词不一致 - 切忌对同一个字段同时设
analyzer和search_analyzer却不保持一致；默认情况下，search_analyzer会继承analyzer - 验证是否生效：用
POST /articles/_analyze测试分词输出，别只看插件列表里有没有 ik - Webman 中调试时，可先用 curl 手动建索引，确认分词 OK 后再交由 PHP 代码自动创建
高并发下搜索变慢，先看是不是用了 highlight 或 script_fields
一个 highlight 字段在 10k 文档中匹配，可能让响应时间从 20ms 拉到 800ms —— 因为它要逐字段重排片段、计算偏移、渲染 HTML 标签，且无法缓存。
真实压测中发现，关闭 highlight 后 QPS 提升 3–5 倍。这不是配置问题，而是功能代价本身。
- 只对用户当前浏览的前 10 条结果开启高亮，其余用
highlight: {"require_field_match": false}降低精度换速度 - 避免在聚合查询中嵌套
highlight：聚合本身已很重，再加高亮等于双重开销 -
script_fields同理：每个文档都要执行一次 Painless 脚本，CPU 密集型，且无法利用倒排索引加速 - 如果业务真需要动态计算字段（如“距离当前城市多少公里”），应提前在写入时算好存为普通字段，而非运行时脚本
ES 的毫秒级响应不是靠堆参数调出来的，而是靠克制地用功能。Webman 的协程优势，很容易被一个重量级 highlight 拖垮整条链路 —— 这点比 JVM GC 更隐蔽，也更常被忽略。
