接口写完立刻回查列表，文档数还是 0，隔一秒再查就有了。索引 settings 里 refresh_interval 写的是 30s，测试环境同一个接口却能马上查到。第一次遇到会往复杂处想，其实漏掉的多是个小前提。
PUT orders/_settings
{"index": {"refresh_interval": "1s"}}
POST orders/_refresh
GET orders/_doc/10086
写入只进了 translog 和内存 buffer，refresh 之后才形成可搜索的段。刷新间隔调到 30 秒，可见性就跟着变成最长 30 秒。测试环境数据量小，默认 1s 的间隔看起来像实时。这一点先确认清楚，后面就不用反复试。
「refresh_interval 写入延迟」相关的日志我一般连着看前后五分钟，单看一条报错经常判断不出是哪一步失败。把这次用到的命令存进笔记，比记住结论有用，换个环境还能照着走。
改完隔一天再看一次，当场正常不代表能稳住。
具体做法是，写后必须立刻可见的接口 单独调 _refresh；或者把该索引 refresh_interval 调回 1s 评估写入压力；批量导入时反过来调大间隔 导完再刷一次；业务上别用 search 做写后校验 改用 GET by id。
改完照着核一遍，写入后紧接着 GET _count 就能看到新文档，连续十次请求结果一致。