在 Java 中，使用 = 赋值对象变量时仅复制引用，导致多个变量指向同一实例；要确保对象独立，必须通过构造器、拷贝方法或克隆机制创建新实例，而非简单赋值。
在 java 中，使用 `=` 赋值对象变量时仅复制引用，导致多个变量指向同一实例；要确保对象独立，必须通过构造器、拷贝方法或克隆机制创建新实例，而非简单赋值。
Java 中的对象赋值默认是引用传递：ComplexNumber c = a; 并未创建新对象，而是让 c 指向 a 所引用的同一块堆内存。因此对 c 的修改（如 c.setX(...)）会直接影响 a —— 这是语言机制决定的，无法“禁止”该语法本身，但可通过设计约束和开发规范防止意外共享状态。
✅ 正确做法：始终显式创建独立副本
最直接、安全且推荐的方式是使用拷贝构造器（Copy Constructor），如示例中已实现的 ComplexNumber(ComplexNumber c)：
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"
⚠️ 注意：此构造器执行的是浅拷贝（Shallow Copy）。对于 ComplexNumber 这类仅含基本类型字段（int x, y）的类，浅拷贝完全等价于深拷贝，语义安全。若类中包含可变引用类型（如 List
coefficients），则需升级为深拷贝（递归复制嵌套对象）。
❌ 错误认知：试图“禁止” = 赋值？
Java 语言层面不允许禁用 = 对对象的引用赋值——这是其基础语义，任何运行时拦截（如代理、字节码增强）既不可行也不合理。所谓“防止”，实则是引导开发者主动选择复制行为，而非依赖语言限制。
因此，关键在于：
- API 设计上不暴露可变内部状态（例如避免返回 private List 的直接引用）；
- 文档明确标注“此对象不可变”或“请使用拷贝构造器”；
- 团队约定 + 静态检查工具（如 SonarQube 规则）识别高风险赋值（如 var x = y; 后紧接 x.mutate()）。
? 补充方案：实现 Cloneable 与重写 clone()
若需更通用的复制接口，可实现标准克隆协议：
class ComplexNumber implements Cloneable {
// ... 字段与构造器同前 ...
@Override
public ComplexNumber clone() {
try {
return (ComplexNumber) super.clone(); // 对基本类型字段，super.clone() 即满足需求
} catch (CloneNotSupportedException e) {
throw new AssertionError("Clone not supported for ComplexNumber", e);
}
}
}调用方式：ComplexNumber d = a.clone(); —— 效果与拷贝构造器一致，但语义更泛化，适合需要统一复制入口的场景。
✅ 最佳实践总结
| 场景 | 推荐方式 | 说明 |
|---|---|---|
| 简单值对象（如 ComplexNumber, Point, Money） | 拷贝构造器 | 类型安全、意图明确、无需异常处理、支持 final 字段初始化 |
| 需统一复制接口的继承体系 | clone() + Cloneable | 注意必须重写 clone() 并声明为 public，且需处理深拷贝逻辑 |
| 不可变对象设计 | 移除所有 setter，字段 final，构造器完成初始化 | 从根本上消除“被意外修改”的可能，= 赋值反而成为优势 |
最终，预防对象间意外共享的核心不是对抗语法，而是以面向对象的设计原则驱动行为：明确对象职责、控制状态可变性、提供清晰的复制契约。这样，ComplexNumber c = a; 的代码虽仍合法，但因缺乏业务意义且易引发 bug，自然会在 Code Review 中被拒绝——这才是可持续的“预防”。
