不少Java开发者在使用Stream API时，都遇到过一个“反直觉”的场景：明明用Stream筛选出了一个新集合，修改新集合里的对象属性后，回头一看原始列表的对象居然也跟着变了。第一次遇到这事时，我反复检查代码，甚至怀疑是不是Stream API有bug——直到搞懂背后的原理，才发现是自己对“集合”和“对象”的关系理解不到位。今天就把这个坑掰开揉碎，讲清楚为什么会这样，以及怎么避免踩坑。

一、先看个反直觉的现场：代码跑出来的结果和想的不一样
先从一个真实的业务场景说起：我需要处理一批订单，先筛选出“未完成”的订单，把这些订单的状态改成“已完成”，最后统计原始列表里各状态的订单数量。原本以为筛选后的集合是“独立”的，结果统计时发现，原始列表里的“未完成”订单居然变少了——问题出在哪？先看可复现的代码（用Order订单类举例，逻辑和实际业务一致）：

import java.util.ArrayList;
import java.util.List;
import java.util.stream.Collectors;

// 订单实体类
class  Order {
    private  Long orderId;
    private  String status; // 状态：未完成/已完成

    // 构造器、getter、setter
    public  Order(Long orderId, String status) {
        this.orderId = orderId;
        this.status = status;
    }
    public  Long getOrderId() { return  orderId; }
    public  String getStatus() { return  status; }
    public  void  setStatus(String status) { this.status = status; }

    @Override
    public  String toString() {
        return "Order{orderId=" + orderId + ", status='" + status + "'}";
    }
}
public class  StreamModifyPitfall {
    public  static  void  main(String[] args) {
        // 1. 初始化原始订单列表：2个未完成，1个已完成
        List<Order> originalOrderList = new   ArrayList<>();
        originalOrderList.add(new   Order(1L, "未完成"));
        originalOrderList.add(new   Order(2L, "已完成"));
        originalOrderList.add(new   Order(3L, "未完成"));

        System.out.println("修改前原始列表：");
        originalOrderList.forEach(System.out::println);
        // 输出：
        // Order{orderId=1, status='未完成'}
        // Order{orderId=2, status='已完成'}
        // Order{orderId=3, status='未完成'}

        // 2. Stream筛选：获取所有“未完成”的订单，存入新集合
        List<Order> unfinishedOrders = originalOrderList.stream()
                .filter(order -> "未完成".equals(order.getStatus()))
                .collect(Collectors.toList());

        // 3. 修改新集合里的订单状态为“已完成”
        for (Order order : unfinishedOrders) {
            order.setStatus("已完成");
        }
        // 堆代码 duidaima.com
        // 4. 再次打印原始列表：发现未完成的订单没了！
        System.out.println("\n修改后原始列表：");
        originalOrderList.forEach(System.out::println);
        // 输出：
        // Order{orderId=1, status='已完成'}
        // Order{orderId=2, status='已完成'}
        // Order{orderId=3, status='已完成'}
    }
}

这段代码的逻辑很简单：筛选未完成订单→修改新集合的订单状态→查看原始列表。但结果完全反直觉：明明只改了unfinishedOrders，原始的originalOrderList里的订单状态居然也被改了。如果你第一次遇到这个情况，大概率会和我一样困惑：Stream的collect不是返回一个新的ArrayList吗？新集合和原始集合没关系，怎么会互相影响？

二、不是Stream的坑，是你没搞懂“引用传递”的本质
其实问题和Stream API没关系，根源在于Java的“引用传递”特性——我们对“集合”和“对象”的关系存在认知偏差。先明确一个核心知识点：Java中集合存储的不是对象本身，而是对象的引用（即对象在内存中的地址）。

可以这么理解：集合就像一个“地址簿”，里面记的不是“人”（对象），而是“人的住址”（引用）。当你用Stream筛选时，相当于从原始地址簿里，把符合条件的“住址”抄到了一个新的地址簿里——新地址簿是新的，但里面的“住址”和原始地址簿里的是同一个。

具体到上面的代码，过程是这样的：
1.初始化originalOrderList时，我们创建了3个Order对象，内存中会有3块空间存储这3个对象（比如地址分别是0x001、0x002、0x003）；
originalOrderList这个集合里，存的是0x001、0x002、0x003这三个地址；
2.Stream筛选时，filter会判断每个地址对应的对象是否符合“未完成”条件，然后把符合条件的地址（0x001、0x003）抄到unfinishedOrders这个新集合里；
3.当我们调用order.setStatus("已完成")时，实际上是通过unfinishedOrders里的地址（0x001、0x003），找到内存中的Order对象，修改了对象的status属性；
4.最后看originalOrderList时，它里面存的还是0x001、0x002、0x003这三个地址，只不过0x001和0x003对应的对象属性已经被改了——所以原始列表的状态自然会变。
一句话总结：新集合和原始集合是两个不同的“地址簿”，但里面记的是同一个“住址”，修改“住址”对应的“人”，两个地址簿查看到的“人”自然会变。

三、为什么会反直觉？因为我们混淆了“集合独立”和“对象独立”
之所以觉得反直觉，本质是我们把“集合的独立性”和“对象的独立性”搞混了。很多开发者会默认一个认知：“只要是新创建的集合，里面的内容就和原始集合没关系”。这个认知只对了一半——新集合本身是独立的（比如你给新集合加个元素，原始集合不会加），但集合里的“内容”（引用）指向的对象，未必是独立的。

举个例子：你有一本地址簿A，抄了里面两个人的地址到新地址簿B。你在B上划掉一个地址，A里的地址不会变（集合独立）；但你根据B的地址找到那个人，把他的名字改了，再根据A的地址找他，名字也会是改后的（对象不独立）。Stream的collect方法确实创建了新集合，但它只保证“地址簿是新的”，不保证“地址对应的人是新的”——这就是反直觉的根源。

四、踩坑后怎么解决？两种场景对应两种方案
搞懂原理后，解决问题就很简单了。关键看你的业务需求：是想修改后影响原始列表，还是不想影响？
场景1：就想修改原始列表（比如批量更新状态）
这种场景下，其实代码本身没问题，但需要注意两点：
明确注释：在筛选和修改的代码旁加注释，说明“此修改会影响原始列表”，避免后续维护者误解；
避免多线程风险：如果有多个线程同时操作原始列表和筛选后的列表，可能会出现并发修改异常，建议加锁或用线程安全的集合（如CopyOnWriteArrayList）。
场景2：不想影响原始列表（比如筛选后做临时处理）
这种场景的核心是：给筛选后的每个对象创建“副本”（深拷贝），让新集合存副本的引用。
具体怎么做？有两种常见方式：

方式1：手动创建对象副本（简单直接）
在Stream的map方法里，为每个符合条件的对象new一个新对象，把原始对象的属性复制过去。修改后的代码如下：

List<Order> unfinishedOrders = originalOrderList.stream()
        .filter(order -> "未完成".equals(order.getStatus()))
        // 关键：创建新的Order对象，复制原始属性
        .map(order -> new   Order(order.getOrderId(), order.getStatus()))
        .collect(Collectors.toList());

// 再修改新集合的订单状态
for (Order order : unfinishedOrders) {
    order.setStatus("已完成");
}

// 此时原始列表不会变
System.out.println("\n修改后原始列表：");
originalOrderList.forEach(System.out::println);
// 输出：
// Order{orderId=1, status='未完成'}
// Order{orderId=2, status='已完成'}
// Order{orderId=3, status='未完成'}

这种方式的好处是简单可控，缺点是如果对象属性多，手动复制会很繁琐。

方式2：用工具类实现深拷贝（适合复杂对象）
如果Order类有很多属性，或者属性里有引用类型（比如Order里有User对象），手动复制太麻烦，这时候可以用工具类实现深拷贝。常用的工具类有Apache的commons-beanutils或Spring的BeanUtils，但要注意：BeanUtils默认是浅拷贝，如果对象里有引用类型属性（比如User），需要手动处理嵌套属性的拷贝（深拷贝）。

以Spring的BeanUtils为例，修改代码如下：

import org.springframework.beans.BeanUtils;

// 深拷贝工具方法（如果有嵌套属性，需要递归处理）
private  static  Order copyOrder(Order source) {
    Order target = new   Order();
    BeanUtils.copyProperties(source, target);
    // 如果Order里有User属性，需要额外拷贝User：
    // User newUser = copyUser(source.getUser());
    // target.setUser(newUser);
    return  target;
}

// Stream筛选时调用拷贝方法
List<Order> unfinishedOrders = originalOrderList.stream()
        .filter(order -> "未完成".equals(order.getStatus()))
        .map(StreamModifyPitfall::copyOrder) // 调用深拷贝方法
        .collect(Collectors.toList());

这里要注意：如果对象有嵌套的引用类型（比如Order→User→Address），BeanUtils的浅拷贝会导致嵌套对象还是共享引用，此时需要实现真正的深拷贝（比如递归拷贝嵌套对象，或用序列化/反序列化的方式）。

五、实战案例：我是怎么因为这个坑差点出生产事故的
最后分享一个我踩坑的真实案例，让大家更重视这个问题。之前做电商订单系统时，有个需求：筛选出“待支付”的订单，生成支付链接后，把这些订单的“临时状态”改成“待确认”，但原始的“待支付”订单列表不能动（要留给定时任务去关单）。一开始我没注意引用的问题，直接用Stream筛选后修改了状态，结果定时任务查询“待支付”订单时，发现数量少了——因为原始列表的订单状态被改了，导致很多待支付订单没被关单，差点造成用户超期支付的问题。

后来排查了半天才发现，是Stream筛选后修改对象影响了原始列表。最后用深拷贝的方式解决，同时在代码里加了注释，避免后续同事踩坑。这个案例告诉我们：看似反直觉的问题，本质都是基础知识点没吃透。理解Java的引用传递、集合与对象的关系，不仅能避免这类坑，还能在写代码时更有底气。

总结

回到开头的问题：Stream筛选后修改对象，原始列表为什么会变？答案很简单——集合存的是引用，筛选只是复制引用，不是复制对象。这个“反直觉”的坑，其实是Java基础的“照妖镜”：如果能理解引用传递、对象内存模型，就能一眼看穿问题；如果理解不到位，就容易踩坑。

最后给大家两个建议：

1.写代码时多问自己：“这个集合里存的是对象还是引用？修改后会不会影响其他地方？”；
2.遇到反直觉的问题时，别先怀疑API有问题，先从基础原理入手——大部分坑都是基础没吃透导致的。
希望这篇文章能帮你搞懂这个问题，下次再用Stream时，再也不用为“原始列表变不变”纠结了。