我先给结论，再说明它在项目里解决什么问题。比较 from-size、search_after、PIT、scroll 的成本和适用场景。from + size 很大时，每个分片都要收集足够多候选并由协调节点全局排序，CPU 和内存成本高。连续向后翻页应使用 searchafter，并配合 PIT 固定索引视图；全量离线遍历可使用 scroll，但不适合实时用户翻页。 searchafter 是无状态游标思路，下一页携带上一页最后一条结果的完整排序值。

核心机制我会按一次真实执行过程来讲。沿着「固定排序与查询快照 → 首次查询得到最后 sort 值 → 携带 searchafter 请求下一页 → 各分片从游标后继续 → 协调节点合并并返回新游标」观察输入、状态与输出，这些阶段都可以从日志、指标或源码里验证。 固定排序与查询快照 from+size 要求每个分片保留前 from+size 条候选，页越深内存和 CPU 越高。

实现细节只抓关键入口，不会整段背源码。SearchAfterBuilder：sort 游标解析。 PointInTimeBuilder：固定 Searcher 视图。 我会先确认请求实际走到了哪条路径，再用运行数据验证，不会只看类名或配置猜测。

放到生产使用时，我会关注参数和验证数据。并发 refresh 下遍历十万文档，核对重复遗漏并统计每页成本。 固定输入和基线 先在没有故障注入的环境执行上述配置，固定数据规模、并发度、运行时版本和预热时间。以「每页 scanned/returned」为主基线，记录值应满足「记录稳态基线」；同时保存 每页 took 与扫描数、PIT 上下文数量，使后续变化能够回到同一时间轴比较。

最后补充常见误区和使用边界。只按 timestamp 排序，大量日志同毫秒，searchafter 边界无法唯一定位；同时未使用 PIT，刷新改变结果集。加入 timestamp+sharddoc 或业务唯一 ID，并绑定 PIT 后稳定。 排序字段不唯一：每页 took 与扫描数：排序加入唯一 tie-breaker。 方案：更适合的场景：主要收益：代价与边界。 from/size：浅页和随机跳页：使用简单：受 maxresultwindow 与深页放大。 searchafter + PIT：在线连续深翻页：性能稳定、一致视图：游标有状态，不能随意跳页。 异步导出任务：全量大结果：隔离资源、可断点：延迟、任务状态和文件治理。 选型至少带上 文档规模、分片数、字段基数、查询并发和写入速率，并用上面的量化基线验证；