我不会直接画架构图，会先确认目标、规模和一致性要求。掌握 text 和 keyword、动态映射、全文查询与精确查询的设计方法。

容量有了以后，再把入口、核心处理和数据落点串起来。沿着「识别字段业务语义 → 定义 Mapping 与 Analyzer → 写入并建立索引结构 → 选择 Query/Filter 上下文 → 聚合排序并返回」观察输入、状态与输出，这些阶段都可以从日志、指标或源码里验证。 识别字段业务语义 字段类型决定可用查询、存储格式和内存结构，动态映射方便但可能把 ID、日期或数值识别错误。 MapperService：Mapping 合并与字段类型。 fieldcaps：跨索引字段能力。 我会先确认请求实际走到了哪条路径，再用运行数据验证，不会只看类名或配置猜测。

关键参数要从峰值流量和资源上限反推。写入数字、前导零、数组对象和未知字段，验证 strict 模板与 nested 语义。

正常链路之外，还要设计失败补偿和可验证的恢复流程。测试样本全是数字，动态映射把订单号识别为 long，后续带字母数据写入失败，精确格式也无法保留。通过索引模板显式定义 keyword 并版本化 alias 后，数据契约才稳定。 字段爆炸触发 mapping limit：字段总数：核心字段显式 Mapping。 数组对象误用 object 导致跨对象匹配：mapping 冲突数：限制 totalfields。 固定输入和基线 先在没有故障注入的环境执行上述配置，固定数据规模、并发度、运行时版本和预热时间。以「mapping 冲突」为主基线，记录值应满足「记录稳态基线」；同时保存 字段总数、mapping 冲突数，使后续变化能够回到同一时间轴比较。

最后再讲扩容、成本和方案边界。方案：更适合的场景：主要收益：代价与边界。 显式 Mapping：生产核心索引：类型可控、错误前置：演进需模板与重建。 动态模板：字段模式可预测的大量日志：减少手工定义：规则优先级错误会污染索引。 runtime field：临时派生或历史兼容：无需立即重建：查询时计算成本高。 选型至少带上 文档规模、分片数、字段基数、查询并发和写入速率，并用上面的量化基线验证；未知数据应明确为待测假设。