会阻塞协程，因官方SDK基于同步cURL；需替换为Swoole协程HTTP客户端，配置timeout、重试及正确headers与masterKey。
Hyperf里直接用 meilisearch-php SDK 会阻塞协程吗？
会，而且默认就是阻塞的。官方 meilisearch-php SDK 底层用的是 GuzzleHttp\Client，走的是 PHP 的同步 cURL，一旦发请求，整个协程就卡住，失去并发优势。这不是 SDK 写得差，而是它没为 Swoole 协程环境做适配。
为什么不能直接 composer require meilisearch/meilisearch-php 就完事？
能装上，但不等于能用好。常见问题包括：
- 搜索请求耗时突增（比如从 20ms 涨到 300ms+），尤其在高并发下明显
-
MeiliSearch\Client实例被多个协程复用时出现连接复用混乱或超时中断 - 未设置
timeout或connect_timeout，导致单个慢查询拖垮整条协程调度链 - 错误处理缺失，比如
404 Index not found或401 Unauthorized直接抛异常，没兜底重试或降级逻辑
怎么让 Meilisearch SDK 真正跑在协程里？
必须替换 HTTP 客户端为协程友好的实现。推荐方案是用 Swoole\Coroutine\Http\Client + 手动封装请求逻辑，而不是依赖 Guzzle：
- 在
config/autoload/services.php中注册一个自定义的MeiliSearchService类，构造时传入http://localhost:7700和masterKey - 所有方法（如
search()、addDocuments()）内部都用new Swoole\Coroutine\Http\Client()发起请求，并显式调用execute() - 务必设置
$client->set(['timeout' => 3.0])，避免协程无限等待 - 对常见错误码（如
502 Bad Gateway、503 Service Unavailable）做重试（最多 2 次），用co::sleep(0.1)隔开 - 不要把
MeiliSearch\Client实例存成单例全局共享，每次请求 new 一个新 client 更安全
PHP SDK 初始化时最容易漏掉的三个配置项
哪怕你用了协程客户端，这三个点不设好，照样出问题：
-
masterKey：必须和启动 Meilisearch 时的--master-key=xxx严格一致，大小写敏感，缺了直接401 Unauthorized -
requestTimeout：SDK 构造参数里有这个字段，但默认是null，意味着无限等待；建议显式设为3000（毫秒） -
headers：某些部署环境（如 Nginx 反代后）需要加Content-Type: application/json，否则addDocuments可能返回415 Unsupported Media Type
go 就行，HTTP 底层必须换掉。很多人卡在第一个搜索请求就变慢，其实是 Guzzle 在背后默默 blocking 了整个协程栈。 
