企业官网建设流程全解析

说实话，用了这么多年 Java 8，很多人写 Stream 的时候都是Stream<String>、Stream<Integer>这类对象流走天下，唯独一碰到int[]数组或者连续数值范围就卡壳了。要么在Arrays.stream(arr).boxed()这条路上绕来绕去，要么干脆退回 for 循环，把 Stream 的优势晾在一边。

我这次要聊的IntStream，是专门为原始类型int设计的 Stream 变体。它存在的意义不只是省去装箱那点性能开销，更重要的是它自带一套专门针对数值场景的方法：range、sum、average、summaryStatistics这些直接可用，代码写起来比传统的 for 循环简洁得多，也比Stream<Integer>优雅得多。

这篇文章我会从为什么需要 IntStream 讲起，然后逐个拆解创建方式、中间操作、终止操作，再用几个实际业务场景演示它到底怎么用。无论你是刚接触 Stream API 的新手，还是已经用了几年、但一直没认真研究过 IntStream 的老手，这篇文章都值得认真看一遍。很多细节和坑，是真的要自己在代码里踩过才会注意到的。

1. 为什么需要 IntStream：原始类型流的性能账本

先从一个最直观的问题入手：为什么 Java 8 要单独搞一个 IntStream 出来，而不是统一用Stream<Integer>搞定一切？

1.1 泛型的局限与装箱成本

Java 的泛型有个天生的限制：泛型参数只能是引用类型，不能是原始类型。这意味着Stream<Integer>里的每一个元素，实际上都是一个被装箱后的Integer对象。而IntStream则直接以原始类型int作为流的元素类型，内部存储就是连续的原始 int 值，没有任何包装对象。

这个差异在数据量小的时候几乎感觉不到，但一旦数据量上去，就是质的区别。假设你要对一百万个整数求和：

int[] data = new int[1_000_000]; // 初始化 data 省略 // Stream<Integer> 方式 int sum1 = Arrays.stream(data) .boxed() .reduce(0, Integer::sum); // IntStream 方式 long sum2 = IntStream.of(data).sum();

第一种方式会产生一百万个Integer对象，内存里多出至少 1600 万字节的对象头和数据（取决于 JVM 实现），还要承担相应的 GC 压力。第二种方式直接在原始 int 数组上操作，内存占用极小，速度快好几倍。

1.2 语义上的天然优势

除了性能，IntStream 还让代码的语义更清晰。普通 Stream 想求最大值要写.reduce(Integer.MIN_VALUE, Math::max)这种绕来绕去的表达式，IntStream 直接.max()就结束了。想求平均值，Stream<Integer>得先 map 成 Double 再收集，而IntStream.average()开箱即用。

我做过一次简单的基准测试（数据量 1000 万，随机整数求和）：

当然这个数据受到 JVM 预热、编译优化等因素的影响，不同机器差异很大，但它反映的趋势是真实存在的：原始类型流在数值密集场景下，性能和内存表现确实是压倒性的优势。

2. 创建 IntStream 的六条通道，以及每条通道的适用边界

IntStream 的创建方式和普通 Stream 有很多相似之处，但细节差异很大。我平时用下来，主要就是下面这六种途径。

2.1 静态工厂：of、range、rangeClosed

最基本的创建方式是IntStream.of(...)，它接收一个或多个 int 参数，也可以接收一个int[]数组：

IntStream s1 = IntStream.of(3, 5, 8); int[] arr = {1, 2, 3}; IntStream s2 = IntStream.of(arr);

range和rangeClosed则是专门处理连续整数范围的工厂方法，也是我日常用得最多的：

// [1, 10)，左闭右开 IntStream s3 = IntStream.range(1, 10); // [1, 10]，左闭右闭 IntStream s4 = IntStream.rangeClosed(1, 10);

这两个方法的边界差异非常容易踩坑。range(1, 10)产生的是 1 到 9，不包含 10；rangeClosed(1, 10)产生的才是 1 到 10。如果你要遍历数组下标，一般用range(0, arr.length)，因为数组下标最大就是length - 1，这个写法最自然。如果你要生成包含末尾值在内的数值序列，那就得用rangeClosed。

2.2 iterate 与 generate：无限流的正确用法

iterate是生成无限递增序列的利器：

// 从 1 开始，每次 +2，取前 10 个：1, 3, 5, 7, 9... IntStream.iterate(1, n -> n + 2) .limit(10) .forEach(System.out::println);

注意 Java 8 的iterate只有两个参数：种子和UnaryOperator，没有像 Java 9 那样支持带Predicate的版本。所以在 Java 8 里要限制终止条件，只能配合limit来截断。

generate和iterate有点类似，但它不接受种子，只看IntSupplier每次生成的值：

// 随机生成 5 个整数 IntStream.generate(() -> ThreadLocalRandom.current().nextInt(100)) .limit(5) .forEach(System.out::println);

2.3 从数组和字符串转换

Arrays.stream(int[])是最常见的从数组创建 IntStream 的方式，它其实等同于IntStream.of(arr)，不过用Arrays.stream语义上更贴近"数组转流"的直觉判断：

int[] amounts = {1200, 3500, 2800}; Arrays.stream(amounts).sum();

还有一个容易被忽略的入口：String.codePoints()。这个方法返回一个IntStream，每个元素是字符串对应字符的 Unicode 码点：

String text = "Java 8"; text.codePoints() .forEach(System.out::println); // 输出 74, 97, 118, 97, 32, 56

这种处理方式对中文、表情符号等多字节字符特别友好，因为codePoints()按码点切割，不会把字符截断。

2.4 concat：多个 IntStream 的拼接

IntStream.concat可以把两个 IntStream 连成一个，适合处理多段数据合并的场景：

IntStream s1 = IntStream.rangeClosed(1, 3); IntStream s2 = IntStream.rangeClosed(7, 9); IntStream.concat(s1, s2) .forEach(System.out::println); // 输出 1, 2, 3, 7, 8, 9

它和普通 Stream 的concat类似，有个容易被忽略的点：如果原始流定义了onClose处理器，合并后的流关闭时会按顺序执行两个流的 close 回调。如果你在流上挂资源清理逻辑，要留意这个执行顺序。

3. 中间操作：映射、过滤与类型转换的关键细节

创建完 IntStream，接下来就是流水线上的各种加工操作。这些操作和普通 Stream 大同小异，但在类型转换上有着显著的特殊性，因为 IntStream 的元素是原始类型，转换不能随便找个Function过来就用，必须使用专门的原生函数式接口。

3.1 map、filter、flatMap 的原生接口

map接收的是IntUnaryOperator，即"入参 int，返回 int"的函数式接口：

IntStream.of(1, 2, 3) .map(n -> n * n) .forEach(System.out::println); // 输出 1, 4, 9

它和普通 Stream 的map最大的区别就是参数类型。如果你在 IDE 里硬把IntStream.map的 Lambda 写成一个返回String的方法，编译直接报错。这就是原生流类型的安全保障——编译器强制你遵守原始类型的边界。

filter接收的是IntPredicate，即"入参 int，返回 boolean"：

IntStream.rangeClosed(1, 20) .filter(n -> n % 2 == 0) .forEach(System.out::println); // 输出 2, 4, 6, ..., 20

flatMap稍微复杂一点，它接收IntFunction和IntStream的组合，用于将每个元素映射为零个或多个新元素后展平：

IntStream.of(1, 2, 3) .flatMap(n -> IntStream.rangeClosed(1, n)) .forEach(System.out::println); // 输出 1, 1, 2, 1, 2, 3

这个例子中，元素 1 映射成序列 [1]，元素 2 映射成 [1, 2]，元素 3 映射成 [1, 2, 3]，最后全部合并成一个流。理解flatMap的关键在于：它先对每个元素做一次"一对多"的映射，然后把所有结果拼接起来。

3.2 mapToLong、mapToDouble、mapToObj 的转换边界

IntStream 要转换成其他类型的流，有专门的转换方法：

// 转 LongStream LongStream longStream = IntStream.rangeClosed(1, 10).mapToLong(n -> n * 1000L); // 转 DoubleStream DoubleStream doubleStream = IntStream.rangeClosed(1, 10).mapToDouble(n -> n / 2.0); // 转对象流 Stream<T> Stream<String> stringStream = IntStream.rangeClosed(1, 5) .mapToObj(n -> "第" + n + "个");

mapToLong和mapToDouble的参数分别是IntToLongFunction和IntToDoubleFunction，它们解决的是数值精度和类型匹配的问题。在涉及大数相乘或小数运算时，这两个转换非常重要，否则int溢出会静默破坏你的数据。

mapToObj则是 IntStream 通往对象世界的桥梁。比如你有一组索引，想根据索引去一个List里取对应元素并做一些对象级操作，就需要先用它转成对象流：

List<String> names = Arrays.asList("Alice", "Bob", "Carol", "Dave"); IntStream.range(0, names.size()) .mapToObj(i -> i + " -> " + names.get(i)) .forEach(System.out::println);

3.3 boxed()：为什么说它是逃不掉的那一步

boxed()是 IntStream 特有的方法，作用是把它转换成Stream<Integer>。很多人不理解它和mapToObj的区别，我来解释一下：

• mapToObj(n -> ...)返回的是任意对象流，Lambda 的返回值类型完全由你决定
• boxed()返回的固定是Stream<Integer>，本质上是"装箱"，将原始 int 包装成 Integer

Stream<Integer> boxedStream = IntStream.rangeClosed(1, 3).boxed();

在日常开发中，只要你需要把 IntStream 的结果收集进集合，或者使用Collectors.groupingBy、Collectors.toMap这类基于对象流的收集器，boxed()几乎是必然的一步。举个例子，统计一段文本中每个字符出现的次数：

String text = "abracadabra"; Map<Integer, Long> freq = text.codePoints() .boxed() .collect(Collectors.groupingBy(Function.identity(), Collectors.counting()));

如果不用boxed()，你无法直接用Collectors的收集器做这件事，因为Collectors是面向Stream<T>设计的，IntStream 根本没有对应的原生收集器入口。稍后我会在第 4 节专门讲 collect 的正确打开方式。

boxed()用起来的便捷是有代价的：它把原始类型流的性能优势全部抹掉了。所以一个比较务实的写法是：在 IntStream 阶段做完所有过滤、映射、统计工作，只在最终收集到集合或进入对象流处理时才调用boxed()。千万别一开始就 boxed，那还不如直接用普通 Stream。

4. 终止操作：sum、min、max、average、reduce、toArray、collect 的完整比较

IntStream 最吸引人的地方就在终止操作上。普通 Stream 想求一个数值集合的统计信息，得写一堆繁琐的收集逻辑，而 IntStream 把这些操作全部内置了。

4.1 统计类操作：count、sum、min、max、average

IntStream ints = IntStream.of(3, 1, 4, 1, 5, 9, 2, 6); long count = ints.count(); // 返回 long，8 int sum = ints.sum(); // 返回 int，31，注意溢出风险 OptionalInt min = ints.min(); // 返回 OptionalInt，1 OptionalInt max = ints.max(); // 返回 OptionalInt，9 OptionalDouble avg = ints.average(); // 返回 OptionalDouble，3.875

注意几个细节。min和max返回的是OptionalInt，而不是直接返回 int，因为流可能为空。如果你确定流不为空，可以调用min.getAsInt()；如果流为空，getAsInt()会抛出NoSuchElementException。

average返回OptionalDouble，原因同样是空流问题。执业实际中，很多人因为拿不到double就直接调.getAsDouble()，结果在数据源为空时莫名挂了。最稳妥的做法是用orElse提供一个默认值：

double avg = ints.average().orElse(0.0);

sum()方法返回的是 int，这意味着两个大整数相加可能溢出。如果你的数据量很大，最好先mapToLong再求和：

long total = IntStream.rangeClosed(1, 2_000_000_000) .mapToLong(n -> n) .sum();

不然中间一旦溢出，结果就是负数或错误的数字，这类 bug 在线上排查时非常隐蔽。

4.2 reduce：更灵活的聚合

reduce有三个重载版本，这里逐个区分：

第一个版本，无初始值：

OptionalInt result = IntStream.of(1, 2, 3) .reduce((a, b) -> a + b);

它返回OptionalInt，因为流可能为空。

第二个版本，有初始值：

int result = IntStream.of(1, 2, 3) .reduce(100, (a, b) -> a + b); // 结果是 106

第三个版本，带 combiner（合并器）：

int result = IntStream.rangeClosed(1, 100) .parallel() .reduce(0, Integer::sum, Integer::sum);

这个版本在并行流中真正发挥作用。它的工作机制是：每个线程用前两个参数在自己的分片上执行累加，最后所有分片的结果再用 combiner 合并。combiner 必须与累加器兼容，并且满足结合律，否则并行流会算出错误结果。

我在实际项目中发现过一个典型的错误：有人在并行流里用reduce(0, Integer::sum, Integer::min)，意图是"先并行累加，最后取最小值"。这个思路完全错了，因为分片的累加用的是求和，只有全部求和完成后才应该取最小值，但 combiner 在这里负责合并分片结果，它会把两个分片和用Math.min合并，导致最终结果接近"各分片的前几个数里最小的那个"，而不是总和，也不是全局最小值。这个抽象一旦没有理解透彻，出来的结果会让你怀疑人生。

4.3 toArray 和 collect：怎么变成数组和集合

IntStream 有内置的toArray()，直接返回int[]：

int[] array = IntStream.rangeClosed(1, 5).toArray(); // [1, 2, 3, 4, 5]

但collect没有直接返回List<Integer>的方法，因为Collector接口是基于对象流设计的。这是 IntStream 收集到集合的唯一常见路线：

List<Integer> list = IntStream.rangeClosed(1, 5) .boxed() .collect(Collectors.toList());

如果你不想承担装箱的开销，也可以自定义收集器，用可变容器Stream.Builder<Integer>或者自己写一个Supplier<Set<Integer>>+ObjIntConsumer<Set<Integer>>的组合：

Set<Integer> set = IntStream.of(3, 1, 2, 2, 3) .collect(HashSet::new, Set::add, Set::addAll);

第三种参数Set::addAll用于并行流中将多个子容器合并。这种方式的好处是全程没有装箱，但代码的直观性稍差，一般只有在性能敏感的代码里才有必要这么写。

4.4 IntSummaryStatistics：一次拿到全部统计信息

有些场景需要同时对流做多个统计操作，如果分别取sum、min、max、average，代码必然要重复遍历流。Java 8 提供了IntSummaryStatistics这个容器，一次性收集所有统计指标：

IntSummaryStatistics stats = IntStream.rangeClosed(1, 100) .summaryStatistics(); System.out.println(stats.getCount()); // 100 System.out.println(stats.getSum()); // 5050 System.out.println(stats.getMin()); // 1 System.out.println(stats.getMax()); // 100 System.out.println(stats.getAverage()); // 50.5

这在日常报表类逻辑中非常实用。例如你要统计一批订单金额的总额、均值、峰值，一个流水线就能全部算完，不用反复扫描数据源。

5. 实战场景：索引遍历、素数判断、频率统计、随机数生成

前面讲了一堆 API 细节，现在来看看实际项目中，IntStream 到底能怎么用。我挑了四个频率很高、也很有代表性的场景。

5.1 用 IntStream 替代传统 for 循环

最常见的场景就是"你要遍历一组元素的索引，而不是元素本身"。

假设有一个List<String>，你想打印每个元素以及它前面的序号：

List<String> lines = Arrays.asList("第一行", "第二行", "第三行", "第四行"); // 传统写法 for (int i = 0; i < lines.size(); i++) { System.out.println(i + ": " + lines.get(i)); if (i == lines.size() - 1) { System.out.println("--- 结束 ---"); } } // IntStream 写法 IntStream.range(0, lines.size()) .mapToObj(i -> i + ": " + lines.get(i)) .forEach(System.out::println);

看起来只是换了种写法，但 IntStream 版本在处理"是否需要继续处理下一个索引"这类条件逻辑时，可以借助 Stream 的各种操作自然表达。比如你想间隔输出、过滤特定索引，或者根据索引和值组合出新的对象，IntStream 的组合能力都比 for 循环强很多。

不过有一点必须提醒：在 Lambda 表达式内部，不能修改外面的局部变量，所以如果你需要在循环过程中维护count = i + 1这样的累加状态，Stream 反而不如 for 循环方便。Stream 适合的是"无副作用"的纯计算场景，这个边界要认清。

5.2 素数判断：range 和 noneMatch 的组合

素数判断是演示 IntStream 界限关系的经典题目。判断一个正整数 n 是否为素数，最简单的思路是检查 2 到sqrt(n)之间有没有能整除 n 的数：

public boolean isPrime(int n) { if (n < 2) { return false; } return IntStream.rangeClosed(2, (int) Math.sqrt(n)) .noneMatch(divisor -> n % divisor == 0); }

用rangeClosed而不是range，是因为要覆盖sqrt(n)本身这个边界值。整数 25 的平方根是 5，如果不能整除 2、3、4，还要检查 5，如果 5 不能整除才说明是素数。用range会漏掉恰好等于平方根的情况（比如 4、9、25 这些完全平方数），导致误判。这个坑我在实际教别人时反复被问到，只有真的去算一遍边界值才会意识到。

5.3 频率统计：boxed 配合 groupingBy

前面提到过用boxed()加groupingBy统计字符频率。这里我再展示一个数字场景：统计一批随机整数落在各个区间里的分布情况。

Map<Integer, Long> buckets = ThreadLocalRandom.current() .ints(1000, 0, 100) // 生成 1000 个在 [0, 100) 范围内的随机整数 .boxed() .collect(Collectors.groupingBy(n -> n / 10, Collectors.counting()));

这个流水线短短两行，就把"生成 1000 个随机数并统计每个十位区间的数量"这件事做完了。如果用传统 for 循环，你需要先初始化一个Map<Integer, Integer>，然后逐个判断区间并累加，代码量至少多出一倍。

随机数这里也有一点可以展开：Random.ints()是 Java 8 新增的方法，返回一个无限的IntStream。这里我用的是带三个参数的版本ints(streamSize, origin, bound)，它会一次性生成指定数量的随机整数，范围是 [origin, bound)，也就是下界包含、上界不包含。如果你的业务只需要少量随机数，用这个重载就不需要再limit了。

5.4 并行流下的 IntStream：性能和注意事项

IntStream 天然支持并行，只需要加一个.parallel()：

long sum = IntStream.rangeClosed(1, 10_000_000) .parallel() .sum();

range和rangeClosed生成的流非常适合并行，因为它们的元素天然可按步长切分，不需要额外的拆分逻辑。相比之下，iterate生成的流是顺序依赖的，每下一个元素都依赖上一个元素，强行并行效率不仅不会提升，还可能变慢。

并行流的副作用问题也值得警惕。不要在forEach或peek里对共享的可变对象做写操作。比如下面这个例子看起来很无害，实际上在并行下会出问题：

List<Integer> result = new ArrayList<>(); IntStream.rangeClosed(1, 1000) .parallel() .forEach(result::add);

ArrayList不是线程安全的，多个线程同时往里add可能导致数组越界、数据丢失或者元素顺序错乱。正确做法是用boxed().collect(Collectors.toList())，或者用collect的三参数版本指定好线程安全的容器。

6. 踩坑实录：一批容易让人抓狂的细节

IntStream 的坑，大多不是藏在复杂逻辑里，而是藏在最简单的 API 边界里。这里我把这些年踩过、也帮别人排查过的问题集中整理一下。

6.1 range 与 rangeClosed 的边界混淆

这个坑在上文已经反复提醒过了，但值得再单独拎出来说一次。range(1, 10)生成 1 到 9，共 9 个元素；rangeClosed(1, 10)生成 1 到 10，共 10 个元素。用错了，要么多算一个边界值，要么少算一个。尤其是做分页查询、数据分组这类对边界敏感的场景，少一个数据或多一个数据，排查起来非常痛苦。

我自己的经验是：只要是"从 0 到 length"这种数组下标场景，一律用range；只要是"从 1 到 N"这种数学语义的闭区间场景，优先想一下到底要不要包含 N，再决定用哪个。

6.2 空流上的 OptionalInt 陷阱

int min = IntStream.of().min().getAsInt();

这一行代码会在运行期直接抛出NoSuchElementException。很多人的逻辑是"我确定流里有数据，所以不会空"，但在实际业务中，流的数据源可能是数据库查询结果、外部接口返回值或者用户上传的列表，任何一步返回空集合都有可能。

安全写法永远是：

int min = IntStream.of().min().orElse(Integer.MIN_VALUE);

OptionalInt和OptionalDouble的意义就是强迫你处理空值情况，别偷懒。

6.3 sum 的溢出问题

IntStream.sum()返回 int，这一点很少人注意到。假设数据源是从 1 到 3 亿的所有整数，它们的总和已经超过了 int 的表示范围（21 亿左右），这时sum()会悄悄返回一个溢出的负数或错值。

可靠的做法是先mapToLong再sum()，这样返回值类型变成long，范围足够覆盖绝大部分统计场景。如果数据大到连 long 都不够了，那要考虑改用BigInteger和自定义收集器：

long sum = IntStream.rangeClosed(1, 3_000_000_000L) .mapToLong(n -> n) .sum();

注意rangeClosed的入参是 int 类型，如果上界超过Integer.MAX_VALUE需要使用 long 范围的LongStream，或者用别的方式构造数据源，这也是另一个隐藏边界。

6.4 boxed() 滥用导致的性能回退

有性能洁癖的同学会非常反感boxed()，因为它在 IntStream 和对象流之间的转换中，让前面的原始类型优化前功尽弃。但有些场景也确实绕不开，比如你需要Collectors.groupingBy做分组统计时。

这里的问题不是"能不能用 boxed"，而是"在哪一步 boxed"。我看到过的反面案例：

IntStream.rangeClosed(1, 1000000) .boxed() .filter(n -> n % 2 == 0) .mapToInt(Integer::intValue) .sum();

这个流水线先装箱、再过滤、再拆箱，绕了一大圈，性能和可读性都很差。正确的做法是：

IntStream.rangeClosed(1, 1000000) .filter(n -> n % 2 == 0) .sum();

中间的过滤、筛选、数值转换都留在 IntStream 阶段完成，只有最后一步才boxed()或mapToObj，这样才能让 IntStream 的性能优势真正发挥出来。

6.5 reduce 在并行流中的结合律要求

我前面已经举过reduce里用Math.min当 combiner 的错误案例。这里再补充一个更常见的组合：parallel().reduce(0, Integer::sum, Integer::sum)没问题，但parallel().reduce(0, (a, b) -> a + b, (a, b) -> a - b)就一定有问题。

combiner 存在的意义是合并两个子任务的结果，它必须与累加器的逻辑"一致"并且符合结合律。也就是说，combiner.apply(accumulator.apply(a, b), accumulator.apply(c, d))应该等于accumulator.apply(accumulator.apply(combiner.apply(a, c), combiner.apply(b, d)), ...)这类一致性的条件。

如果你对自己的聚合算法是否满足结合律没有百分百把握，最稳妥的做法就是不要在并行流上使用三参数reduce，或者用collect替代它。collect的语义是对每个元素独立操作，最后合并容器，它的容错性比赛跑式的 reduce 好很多。

6.6 forEach 与外部可变状态

在 IntStream 或者任何 Stream 的forEach里修改外部变量，这在顺序流里可能"碰巧能跑"，但一旦加上parallel()，就可能在看不见的地方制造并发问题。而且退一步说，即使顺序流能跑，代码的意图也变差了——Stream 的设计哲学是"管道内无副作用"，而不是"在管道末尾偷偷改外部状态"。

如果你确实需要根据流的内容构建一个外部集合，请优先使用collect，它才是 Stream 生态中为"收集结果"这个目的设计的操作：

List<Integer> list = IntStream.rangeClosed(1, 100) .filter(n -> n % 2 == 0) .boxed() .collect(Collectors.toList());

forEach更适合的场景是"对流中的每个元素做独立的消费动作"，比如打印日志、调用外部通知接口，而不是修改当前方法作用域里的可变状态。

6.7 peek 在 IntStream 里的调试姿势

peek是一个常被误解的中间操作。它不是为了修改数据，而是为了调试观察：

IntStream.rangeClosed(1, 10) .peek(n -> System.out.println("原始值: " + n)) .filter(n -> n % 2 == 0) .peek(n -> System.out.println("过滤后: " + n)) .sum();

但要注意，如果流没有终止操作，peek中的打印不会发生；如果流有短路操作（如findFirst、limit），peek可能不会对所有元素执行。所以用peek调试时，感知到的是"流水线实际拉取的元素"，而不是"源数据里的全部元素"，这点认知要建立清楚。

7. 我的个人体会

说白了，IntStream 不是一个很炫酷的 API，它更像是一个为数值场景量身定做的工具箱，需要你在正确的地方打开它。经过这些年的实际使用，我自己形成了一条很实用的取舍线：如果数据量在几千到几万这个级别，用Stream<Integer>和 IntStream 的性能差异基本感觉不到，这时候我优先选择可读性更好的写法——通常直接boxed()接收集器就好。一旦数据量上到十万、百万级别，或者是在需要频繁统计、累加的热点路径上，我才会刻意让流水线保持在 IntStream 阶段，把过滤、映射全部用原生类型操作跑完，只在最后一步收集时才转换类型。

还有一个很实用的经验：写代码之前先想清楚"这个流最后要变成什么"——是一个int[]、一个List<Integer>、一个统计值，还是更复杂的 Map。不同的终点决定了中间是走range还是iterate，是mapToObj还是boxed，是reduce还是collect。想清楚了再动手，写出来的流水线逻辑会很顺，几乎不用改。

如果你之前习惯了 Stream 对象流加 Collectors 的组合，我建议这几天找一个业务场景，比如统计某段时间内的日活峰值、计算一批订单的平均金额，或者给一组坐标做区间频次分组，用自己的业务数据把 IntStream 真正跑一遍。跑通之后你会感觉到，数值计算在 Java 8 的 Stream 体系里，其实一直都有一个更本源的解法等着你。