stream api 不自动拆箱是因java泛型不支持基本类型，故需显式用maptoint或boxed()转换；intstream等特化流绕过泛型、避免装箱开销，但要求手动转换。
Stream API 不会自动执行装箱或拆箱操作，哪怕你传入的是 Integer 列表、想算一个 int 总和，也必须显式调用 mapToInt 或 boxed()。这不是疏忽，而是设计使然——为性能可控而放弃“隐式便利”。
为什么 Stream 不自动拆箱？
核心限制来自 Java 泛型：泛型参数只能是引用类型，不能是 int、double 这类基本类型。所以 Stream<int></int> 语法非法，只能写 Stream<integer></integer>。但包装类型带来装箱/拆箱开销，尤其在大量数值计算时明显拖慢性能。
于是 Java 8 引入了特化流：IntStream、LongStream、DoubleStream。它们绕过泛型，直接用原始类型存储和运算，彻底避免对象创建与 GC 压力。
但这也意味着：从 Stream<integer></integer> 到 IntStream，必须由你明确写出转换逻辑，比如 mapToInt(Integer::intValue)；反过来，IntStream 要变回对象流，也得手动 boxed()。
什么时候必须手动转换？
- 要对数字列表求和、取最大值、平均值等聚合操作 → 优先走
mapToInt().sum()，别用reduce(0, Integer::sum)（后者每步都拆箱） - 用
IntStream.range()或IntStream.of()生成数据后，想转成List<integer></integer>→ 必须先boxed()，再collect(Collectors.toList()) - 方法参数要求
Stream<t></t>（如某些工具方法），但你手头只有IntStream→ 不加boxed()直接传会编译失败 - 使用
Collectors.groupingBy+summingInt统计分组数值总和 →summingInt内部已处理拆箱，无需额外 map
常见误用与优化对比
假设有 List<dish> menu</dish>，每个 Dish 有 getCalories(): int 方法：
❌ 低效写法（隐式拆箱，反复创建 Integer 对象）：int total = menu.stream().map(Dish::getCalories).reduce(0, Integer::sum);
✅ 高效写法（全程原始类型，无装箱开销）：int total = menu.stream().mapToInt(Dish::getCalories).sum();
✅ 若后续还需对象操作（如过滤、映射为字符串），可分段处理：menu.stream().mapToInt(Dish::getCalories).filter(x -> x > 200).boxed().map(String::valueOf).collect(Collectors.toList());
装箱拆箱只在特定上下文生效
Java 的自动装箱/拆箱仅发生在以下场景：
- 赋值（
Integer i = 100;） - 方法传参（
someMethod(int x)接收Integer实参） - 二元运算（
Integer a = 5; int b = a + 3;）
但 Stream 的中间操作（如 map、flatMap）不属于这些上下文，编译器不会插入自动转换代码。所以 Stream<integer>.map(x -> x + 1)</integer> 返回的仍是 Stream<integer></integer>，不是 IntStream，更不会加速。
大量免费API接口：立即使用
涵盖生活服务API、金融科技API、企业工商API、等相关的API接口服务。免费API接口可安全、合规地连接上下游，为数据API应用能力赋能！
