在 Java 中，对象赋值（=）默认是引用复制，会导致多个变量指向同一内存地址；要确保独立对象实例，必须通过构造器或克隆机制创建深拷贝，而非简单赋值。

在 java 中，对象赋值（`=`）默认是引用复制，会导致多个变量指向同一内存地址；要确保独立对象实例，必须通过构造器或克隆机制创建深拷贝，而非简单赋值。

Java 中的变量赋值行为对对象类型和基本类型有本质区别：对基本类型（如 int、boolean），= 执行值拷贝；而对对象引用类型，= 仅复制引用（即内存地址），不会创建新对象。这意味着 ComplexNumber c = a; 后，c 和 a 指向同一实例——任何通过 c 修改状态的操作（如 c.setX(5)）都会直接影响 a。这并非 bug，而是 Java 引用语义的固有特性。

要彻底避免“意外共享”，核心思路是强制要求显式创建独立副本。最直接、可控且推荐的方式是：禁用隐式引用传递，只允许通过拷贝构造器（copy constructor）或工厂方法初始化副本。

以下为优化后的实践方案：

✅ 使用拷贝构造器确保独立实例
为 ComplexNumber 添加参数为同类对象的构造器（已存在），并在所有需要副本的场景中显式调用 new ComplexNumber(original)：

ComplexNumber a = new ComplexNumber(1, 2);
ComplexNumber b = new ComplexNumber(a); // ✅ 真正的独立副本
b.setX(b.getX() + 3);
System.out.println(a); // 输出 "1 + 2i" —— 未被修改
System.out.println(b); // 输出 "4 + 2i"

⚠️ 关键注意事项

• ❌ ComplexNumber c = a; 永远不等于“复制对象”，它只是多了一个别名，应视为危险操作，在生产代码中应严格规避；
• ✅ 拷贝构造器内部必须逐字段复制原始值（本例中 this.x = c.x; this.y = c.y;），对含嵌套可变对象的类，还需递归深拷贝（如 c.nestedObj.clone() 或新建实例）；
• ? 若需更高安全性，可将类设计为不可变（immutable）：移除所有 setX/setY 方法，用 final 修饰字段，并在构造后禁止状态变更——此时即使共享引用也无副作用，但灵活性降低；
• ?️ 进阶防护：可通过静态代码分析工具（如 SonarQube）配置规则，警告 AssignmentToNonFinalField 或自定义检查 ObjectReferenceAssignment，辅助团队规范编码。

总结：防止对象引用共享不是靠“记住不用 =”，而是靠设计约束 + 编码约定 + 工具保障。优先采用拷贝构造器实现显式、清晰、可审计的对象复制逻辑，让“独立性”成为 API 的契约，而非开发者的记忆负担。