Java设计模式是应对对象职责划分、依赖变化等共性问题的可复用结构方案，非语法糖或强制模板；误用比不用更危险，需结合Java运行机制（如ClassLoader、final限制、JVM内存模型）审慎落地。
Observer，反而让逻辑变晦涩。
为什么不能直接照搬 UML 类图写代码？
UML 图描述的是理想协作关系，但 Java 实际运行受制于：final 字段初始化时机、ClassLoader 可见性、子类重写对 template method 流程的破坏。例如 AbstractFactory 模式中，若具体工厂类被不同 ClassLoader 加载，即使类名相同，instanceof 也会返回 false。
- 画图时假设“所有类都可自由继承”，但生产代码常有
final class或private构造器（如java.time.LocalDate） -
Strategy接口若定义了默认方法，JDK 8+ 才能编译通过，老项目可能卡在接口升级上 -
Proxy模式用java.lang.reflect.Proxy时，目标类必须实现接口；想代理普通类得切到CGLIB，但会触发net.sf.cglib.core.CodeGenerationException
Singleton 的双重检查锁为什么需要 volatile？
不加 volatile 时，JVM 可能将 new Singleton() 拆成三步：分配内存 → 初始化对象 → 将引用赋值给静态变量。线程 A 执行到第三步前被调度，线程 B 看到非 null 引用但对象尚未初始化，调用方法会触发 NullPointerException 或未定义行为。
public class Singleton {
private static volatile Singleton instance;
private Singleton() {}
public static Singleton getInstance() {
if (instance == null) {
synchronized (Singleton.class) {
if (instance == null) {
instance = new Singleton(); // 这行必须保证原子可见
}
}
}
return instance;
}
}
何时该用 Builder 而不是重载构造器？
当构造参数超过 4 个，且存在布尔开关、可选字段、类型相近（如多个 String）时，重载构造器极易出错。但 Builder 不是银弹：
- 如果对象创建后从不修改（
immutable），Builder是合理选择；若后续频繁setXxx()，说明设计违背了“构建与使用分离”原则 -
Builder类本身可能成为性能瓶颈：每次构建都新建实例，高并发日志场景下易触发 GC - JDK 14+ 可用
record+ 静态工厂方法替代简单Builder，如Person.of("Alice", 30)
if-else 分支是否已悄悄长成一个 State 模式，或者一段复制粘贴的回调逻辑其实该抽成 Command。模式的价值不在“用了没”，而在“删掉它会不会让下次改需求变得更痛”。 
