webman集成全文检索必须借助elasticsearch或meilisearch等专用引擎，因mysql like无法走索引、fulltext中文支持弱且高并发易拖垮连接池，而laravel scout不适用于webman协程环境。
Webman 本身不内置全文检索能力，直接在 Webman 中调用 Elasticsearch 或 MeiliSearch 是唯一可行的高性能方案；硬套 Laravel Scout 或自己手写 MySQL FULLTEXT 索引，在高并发场景下会迅速成为瓶颈。
为什么不能用 Webman 的事件监听 + MySQL LIKE 做全文检索
很多人试图在 Webman 中监听模型变更、用 INSERT/UPDATE 后触发 LIKE %keyword% 查询，结果很快遇到三个问题：
- MySQL
FULLTEXT对中文支持弱，需额外配置ngram分词器，且最低 MySQL 版本要求 5.7.6+ -
LIKE '%x%'无法走索引，10 万行以上数据查询延迟就超过 300ms - Webman 的协程调度不接管 MySQL 连接池的锁等待，多个
LIKE并发容易拖垮连接池（表现为SQLSTATE[HY000] [2002] Connection refused）
用 MeiliSearch 实现低延迟、零配置中文检索
MeiliSearch 比 Elasticsearch 更适合 Webman 小型服务：启动快、HTTP 接口简洁、默认支持中文分词（基于 tantivy 引擎），且 PHP SDK 调用简单。
实操建议：
Webman 2.2.0
下载
Webman 2.2.0版本强化了 TCP/UDP 服务支持，优化路由组管理，并增强异步任务处理能力。结合协程与连接池技术，Webman 能轻松应对高并发场景，适用于网站、接口服务、即时通讯、物联网及游戏开发，兼具高性能、灵活扩展与稳定可靠，是多场景 PHP 服务开发的理想选择。
- 下载最新版 MeiliSearch（v1.10+），用
./meilisearch --http-addr=127.0.0.1:7700启动，无需额外配置即可处理中文 - 安装官方 PHP SDK：
composer require meilisearch/meilisearch-php - 在 Webman 的
app/Listener/DbSyncToSearch.php中监听数据变更，调用$index->addDocuments()同步，不要在 HTTP 请求中实时同步（避免阻塞协程） - 搜索时用
$index->search('关键词', ['attributesToRetrieve' => ['id', 'title', 'content']])，返回结构原生兼容 Webman 的 JSON 响应
Elasticsearch 配合 IK 分词器的注意事项
若已有 Elasticsearch 集群或需要复杂聚合，必须确认以下几点才能在 Webman 中稳定使用：
- ES 版本 ≥ 8.4，且已安装对应版本的
ik插件（elasticsearch-plugin install https://github.com/medcl/elasticsearch-analysis-ik/releases/download/v8.4.0/elasticsearch-analysis-ik-8.4.0.zip） - PHP 客户端推荐
elasticsearch/elasticsearch，但务必禁用长连接：'connection_pool' => ['sniffing' => false, 'randomize_hosts' => true]，否则协程间 TCP 连接会复用错乱 - Webman 的
onWorkerStart中初始化 ES 客户端，不要每次请求 new Client，否则连接数爆炸 - 避免在
GET /_search中传入未过滤的用户输入——q=*" OR 1=1可能触发 DSL 注入，应在业务层用match_phrase替代query_string
性能压测时最容易被忽略的点
本地跑通不等于线上可用。真实压测中暴露最多的不是代码逻辑，而是基础设施链路：
- MeiliSearch 默认内存限制为 1GB，100 万文档 + 中文分词后实际占用常超 2.5GB，需启动时加
--max-memory=4G - Webman 的
worker_num和 MeiliSearch 的number_of_shards不匹配：单节点 MeiliSearch 建议shards=1，否则多 worker 并发写入会因内部锁竞争导致429 Too Many Requests - ES 集群的
refresh_interval若设为1s，高频写入会导致 segment 太多，查慢；Webman 同步任务应批量提交（addDocuments($batch, ['primaryKey' => 'id'])），而非逐条addDocument()
检索路径越短，延迟越可控。别在 Webman 层做二次过滤，所有条件尽量下推到搜索引擎；同步延迟可接受秒级，就别强求实时——这点比选什么引擎更重要。
