变量别名本身不是错误，但它是多个引用意外共享同一对象的根源；关键在于区分值拷贝与引用拷贝，对对象赋值时=仅复制地址，需显式深拷贝或使用不可变设计来确保状态独立。
变量别名本身不是错误，但它是多个引用意外共享同一对象的根源。真正要规避的，是“以为复制了对象，实际只是多了一个名字”这种认知偏差。关键不在于消灭别名，而在于让别名行为变得可预期、可控制。
看清赋值本质：区分值拷贝与引用拷贝
Java 中 = 运算符对基本类型复制值，对对象只复制地址。这意味着：
-
int a = 5; int b = a;→ 修改b不影响a（两个独立整数） -
Person p1 = new Person("Tom", 20); Person p2 = p1;→p2不是副本，是p1的另一个名字；调用p2.setName("Jerry")后，p1.getName()也会返回"Jerry"
主动创建副本：拒绝隐式别名
所有需要独立状态的场景，必须显式构造新实例，而不是依赖赋值：
- 优先使用拷贝构造器：
Person p2 = new Person(p1);（内部逐字段复制） - 对含嵌套对象的类，确保深拷贝（如
this.address = new Address(src.address)），而非简单引用传递 - 更彻底的方案是设计为不可变类：字段
final，无 setter，所有修改方法返回新对象（如p1.withAge(25)）——此时即使共享引用也无副作用
代码审查时重点盯防的危险信号
这些写法表面正常，实则埋下共享修改隐患：
- 直接赋值语句：
Person backup = original;→ 应改为new Person(original) - 方法参数接收对象后未做防御性拷贝，就存入集合或返回给外部
- 返回私有可变对象引用（如
public List<item> getItems() { return items; }</item>）→ 应返回new ArrayList(items)或Collections.unmodifiableList(items)
调试阶段快速验证是否真独立
当怀疑两个变量是否指向同一对象时，不用猜，用 == 直接验证：
if (a == b) { System.out.println("共享同一实例"); }- 配合日志，在关键修改前后打印
System.identityHashCode(obj)，相同值即为同一对象 - 在 IDE 调试器中观察变量的内存地址（如 IntelliJ 的 Variables 窗口显示
@6a38e578），地址一致即为别名
