不能直接同时安装elasticsearch-php、meilisearch-php和algolia-search，因三者客户端在连接管理、查询构造、错误处理及序列化方式上完全不兼容，硬集成会导致业务层反复适配不同返回格式（如meilisearch返数组、algolia返对象、es需取'hits'），且迁移引擎时须全局重构调用链与结果解析逻辑。
为什么不能直接装 elasticsearch-php + meilisearch-php + algolia-search 一起用？
因为三者客户端设计哲学完全不同：连接管理、查询构造、错误处理、序列化方式都不兼容。硬凑会导致业务层反复做适配，比如 search() 方法在 Meilisearch 返回数组，在 Algolia 返回对象，在 Elasticsearch 又得先调 search() 再取 ['hits']['hits']。更麻烦的是，一旦要切搜索引擎（比如从 Algolia 迁到 Meilisearch），就得全局改调用链和结果解析逻辑。
spatie/laravel-search 或 laravel/scout 真能抽象掉差异？
Scout 是 Laravel 官方方案，但只抽象「写入」和「简单搜索」，对聚合、高亮、同义词、自定义排序等高级能力基本不碰——这些功能每个引擎的参数名、结构、语义都不同，强行统一反而容易出错。Spatie 的包更轻量，但同样回避了复杂查询场景。它们适合「全文关键词匹配+分页」这种基础需求，一旦业务要求 filter 嵌套、facets 动态聚合、或 highlight.pre_tags 自定义高亮标签，你就得绕过抽象层直连原生客户端。
自己封装抽象层，关键要守住哪几条线？
不是把所有方法名重命名一遍就叫抽象，重点是隔离三类变化点：
- 连接初始化：用工厂模式，根据配置加载对应客户端，
config('search.engine')控制实例类型，避免 new 出来就耦合 - 查询输入：统一用数组描述意图，比如
['query' => 'foo', 'filters' => [['status' => 'published']], 'aggregations' => ['category']]，再由各 adapter 转成MeiliSearch\Client::index()->search()或Algolia\Search\Client::search()所需格式 - 结果归一化：强制返回标准结构，如
['items' => [...], 'total' => 123, 'aggregations' => [...]]，不暴露底层_source、hits、facetDistribution等字段名
别试图抽象 updateSettings() 或 dumpIndex() 这种运维操作——它们本就不该出现在业务代码里。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
Composer 依赖怎么组织才不会翻车？
主项目 composer.json 里只声明抽象层包（比如你自己写的 acme/search-contract），不直接 require 任何具体引擎 SDK。真实客户端作为 require-dev 或单独部署时安装：
"require": {
"acme/search-contract": "^1.0"
},
"require-dev": {
"meilisearch/meilisearch-php": "^1.0",
"algolia/algoliasearch-client-php": "^4.0",
"elasticsearch/elasticsearch": "^8.0"
}
这样 CI 构建时不会因某个 SDK 版本冲突失败；生产环境也能按需装一个引擎，而不是把三个 SDK 全拖进去吃内存。另外，所有 adapter 必须实现同一接口，且接口方法参数类型用 PHP 8.0+ 原生类型声明（array, string, int），别用 mixed 或注解模拟类型——否则 IDE 和静态分析工具根本没法帮你发现传参错误。
真正难的不是写完抽象，而是每次引擎升级后检查它是否还守住了那三条线：连接没泄露、查询没漏转、结果没多字段。这点很容易被忽略。
