java stream中间操作延迟执行，仅构建sink责任链节点而不处理数据；终端操作触发时才通过spliterator拉取元素并依次经sink链处理，无状态操作可优化融合，有状态操作则形成屏障。
Java Stream API的中间操作并不立即执行，而是通过构建一条延迟连接的操作链，为后续终端操作做准备。真正关键的不是“做了什么”，而是“怎么组织这些操作”——它不靠遍历数据，而靠组装Sink责任链和抽象流水线节点。
中间操作只是“登记指令”，不碰数据
每次调用filter、map、sorted等方法，Stream并不会去处理元素，而是创建一个代表该操作的StatelessOp或StatefulOp节点，并把它链接到当前流水线末尾。这个过程只涉及对象创建和引用拼接，几乎零开销。
- 比如
stream.filter(p).map(f)，实际生成的是Head → FilterOp → MapOp这样的节点结构 - 所有节点都持有对下游节点的引用，但此时数据源尚未被打开，也没有任何元素被读取
- 即使链很长（如连续5个map），也只构建了5个轻量对象，不会触发任何计算
流水线本质是Sink链的预装配
终端操作触发时，Stream才从源头拉取数据，并把每个元素依次推入一个由Sink构成的处理管道。每个中间操作对应一个Sink实现，它们按顺序调用accept()，形成“处理→转发”模式。
- filter的Sink：判断是否满足条件，满足则调用下游
accept()，否则跳过 - map的Sink：转换元素后，把新值传给下游
accept() - sorted这类有状态操作，其Sink会先缓存全部数据，等
end()被调用时再排序并逐个下发
无状态 vs 有状态操作影响流水线结构
中间操作是否需要看到全部数据，决定了它在流水线中如何参与融合与优化：
- 无状态操作（如filter、map）可自由重排、合并，甚至被编译器内联优化
- 有状态操作（如distinct、sorted、limit）必须等待上游完成，会打断流水线融合，通常作为“屏障”存在
- 例如
stream.sorted().filter(...)中，sorted必须先收完所有元素，才能开始filter，无法边读边筛
源头与Spliterator决定执行粒度
流水线最终如何消费数据，取决于底层Spliterator的特性（如ORDERED、SIZED、CONCURRENT）。它提供tryAdvance()接口，让Sink链以“拉取式”方式逐个处理元素，同时支持并行拆分（trySplit()）。
- 串行流使用单个Spliterator，元素按序进入Sink链
- 并行流将Spliterator递归切分，每段独立走自己的Sink子链，最后合并结果
- 像
limit(10)这种短路操作，会在第10次accept()后通知上游停止拉取，避免冗余处理
大量免费API接口：立即使用
涵盖生活服务API、金融科技API、企业工商API、等相关的API接口服务。免费API接口可安全、合规地连接上下游，为数据API应用能力赋能！
