不适合。Stream.builder()专为动态拼接少量确定值设计，需严格按获取builder→add→build三步操作，build只能调用一次，且需显式声明泛型，不适用于大规模元素构建。
Stream.builder() 适合构建小规模、已知元素的流吗？
不适合。虽然 Stream.builder() 看起来像“手动添加元素”的便捷入口，但它本质是为**动态拼接少量确定值**设计的，不是替代集合转流的通用方案。它内部使用可变数组缓冲，构建完成后调用 build() 才生成真正不可变的流；如果中途频繁 add、或元素量大（比如上千），不如直接用 List.of() 或 Arrays.asList() 再调 stream()，更直观且无额外开销。
正确调用 Stream.builder() 的三步操作
必须严格按顺序：获取 builder → 调用 add() 添加对象 → 必须调用 build() 得到流。漏掉 build() 会拿到 builder 实例，不是流，后续 map/filter 都会编译报错。
-
Stream.builder()返回的是Stream.Builder<t></t>，不是Stream<t></t> - 每个
add()只接受一个元素，不能传集合或数组 -
build()只能调用一次，重复调用会抛IllegalStateException
示例（Java 17+）：
Stream<User> userStream = Stream.builder()
.add(new User("Alice", 28))
.add(new User("Bob", 32))
.add(new User("Charlie", 25))
.build(); // 这行不能少
为什么 builder() 不支持泛型推断？得显式写
因为 Stream.builder() 是静态方法，JVM 在类型擦除后无法从后续 add() 参数反推泛型——add() 方法签名是 void add(T t)，而 builder 实例本身没有类型锚点。不写 <user></user>，编译器可能推成 Stream<object></object> 或报错。
- 错误写法：
Stream.builder().add(new User(...))→ 类型不明确 - 正确写法：
Stream.<user>builder().add(...)</user>或Stream<user>.builder().add(...)</user> - IDE 通常能补全，但手写时漏掉会导致下游
map(u -> u.getName())编译失败
builder() 构建的流是否支持并行？
支持，但没意义。调用 build() 后得到的流默认是串行的；你可以链式调用 .parallel()，比如 Stream.<user>builder().add(...).build().parallel()</user>。不过由于 builder 本身只用于少量元素，强行并行反而引入线程调度开销，性能更差。真要并行处理大量业务对象，请用 ForkJoinPool 或从 Collection.parallelStream() 入口开始。
真正容易被忽略的一点：builder 构建的流是**短路友好**的（比如 findFirst() 会提前终止），这点和 Stream.of() 一致，但和某些自定义 Spliterator 实现有差异——如果你依赖短路行为做条件判断，builder 是安全的。
