由 dawei 漏洞修复后，索引状态可能已偏离预期：字段映射错乱、文档缺失、分词器失效或倒排索引损坏，导致搜索结果不准、响应变慢甚至返回空集。此时简单重启服务或等待自动刷新无法恢复数据一致性，必须主动重建索引。
重建并非粗暴删除重导，而是采用滚动重建策略：新建一个同结构但命名不同的索引（如orders_v2），将旧索引（orders_v1）中有效数据重新索引，同时通过别名机制平滑切换。整个过程对线上搜索无感知，用户始终查询同一别名，后台完成底层索引替换。
AI生成的趋势图，仅供参考
数据迁移阶段需校验完整性。启用reindex API时开启refresh_interval为-1、number_of_replicas设为0，加速写入；完成后立即恢复副本与刷新间隔，并执行forcemerge优化段文件。关键一步是对比新旧索引的doc_count、checksum及随机采样关键词检索结果，确保语义与数量双重一致。
重建期间同步修复漏洞根源：若因映射类型冲突（如string误设为text导致keyword缺失），须在新索引模板中明确定义multi-fields；若因分词器配置错误引发搜索失焦，则需验证analyzer输出，加入synonym、ICU等增强组件，并通过_analyze接口实时调试。
切换完成后，持续监控15–30分钟内的搜索延迟P95、失败率及缓存命中率。若发现聚合不准或高亮异常，大概率源于脚本字段未适配新映射或query DSL未更新。此时不应回滚，而应快速补丁发布——用update_by_query批量修正问题文档，避免二次重建。
索引重建本质是质量校准过程，而非单纯技术操作。每一次重建都应沉淀为可复现的CI/CD流水线步骤：从模板版本管理、数据校验脚本到别名切换原子命令，全部纳入GitOps流程。这样既保障每次漏洞修复后的搜索稳定性，也使团队摆脱“救火式运维”，转向可控、可测、可追溯的搜索治理模式。