不能靠Iterator+Stream做海量文本检索，因其本质仍是O(n×m)线性扫描；真正高效需构建倒排索引实现O(log n)检索，再用Stream处理预筛选结果。
泛型流（stream）和 iterator 本身是两种不同层级的遍历机制，不能“配合使用”来实现文本检索——因为 stream 的底层迭代已封装了 iterator，调用 stream() 时集合会自动通过 iterator() 获取元素。所谓“不依赖下标”，本质是放弃 get(i) 或数组索引访问，转而用声明式或迭代式逻辑处理数据。真正高效、平滑的文本关键词检索，关键不在是否用 iterator，而在于是否避开线性扫描、是否构建合适的数据结构。
为什么不能靠 Iterator + Stream 做海量文本检索
Iterator 是单向、顺序、一次性的游标；Stream 的 filter()、map() 等操作在无索引支持时仍是逐元素遍历。哪怕写成：
list.stream()
.filter(s -> s.contains(keyword))
.collect(Collectors.toList());
这仍是 O(n×m) 时间复杂度（n 为文档数，m 为单文档平均长度），无法满足“平滑”——即低延迟、可响应、可中断、支持模糊/前缀/高亮等交互需求。
真正不依赖下标、又保持平滑的实践路径
- 用倒排索引替代遍历：把“对每个文档查关键词”转为“对关键词查哪些文档包含它”。Lucene、Elasticsearch、SQLite FTS5 都内置该能力，建索引后检索是 O(log n) 或近似常数时间
-
用 Stream 处理预筛选结果：索引返回 ID 列表后，再用
ids.stream().map(id -> docMap.get(id))加载并做轻量加工（如高亮、排序），此时 Stream 才发挥声明式优势 -
泛型确保类型安全，但不提升性能：声明
Stream<Document>或Iterator<String>只避免运行时强转，不影响检索路径。泛型是编译期契约，不是执行优化手段
若必须纯内存+无索引，可小幅优化的技巧
- 用
Pattern.compile(keyword, CASE_INSENSITIVE).matcher(text).find()替代String.contains()，支持正则且复用编译对象 - 对长文本提前截断或分块：用
CharBuffer.wrap(text).subSequence(0, 10000)控制单次匹配长度 - 用
Iterator.forEachRemaining()（Java 8+）替代 while+hasNext+next 组合，代码更紧凑，语义更清晰 - 避免在循环中反复创建正则 Pattern 或分词器——提取为 static final 字段复用
不复杂但容易忽略：平滑检索的瓶颈从来不在语法层面，而在数据组织方式。Iterator 和泛型是工具，不是解法；索引结构才是让“不依赖下标”真正可行的基础设施。
