代理模式重在控制访问，装饰模式重在动态增强功能；代理强调替代性与单一控制点，装饰强调叠加性与正交增强，二者目的、场景及UML依赖关系均不同。
代理模式和装饰模式在 Java 中都属于结构型设计模式，表面看都用“包装”对象的方式扩展行为，但目的和使用场景截然不同：代理模式重在**控制访问**（比如权限校验、延迟
代理模式的核心是“替别人做事”，不是“帮别人加功能”
代理类与被代理类实现同一接口，代理类持有真实对象引用，在调用前后可插入逻辑，但不改变原有接口语义。常见错误是把代理写成“功能叠加器”，结果混淆了职责。
-
Proxy类必须和RealSubject实现同一个Subject接口，否则无法透明替换 - 静态代理需为每个被代理类手写一个代理类；动态代理（
java.lang.reflect.Proxy）则通过InvocationHandler统一拦截 - Spring AOP 默认使用 JDK 动态代理（要求目标类实现接口），若无接口则退化为 CGLIB 代理（生成子类），二者代理机制不同，
final类或方法无法被 JDK 代理
public interface Service {
void execute();
}
public class RealService implements Service {
public void execute() { System.out.println("real work"); }
}
public class LoggingProxy implements Service {
private final Service target;
public LoggingProxy(Service target) { this.target = target; }
public void execute() {
System.out.println("before");
target.execute();
System.out.println("after");
}
}
装饰模式的关键是“同类型层层包裹”，支持运行时组合
装饰类与被装饰类实现同一接口，且持有被装饰对象引用，通过构造函数传入——这是它和代理最直观的代码相似点；但装饰模式的意图是让多个装饰器像俄罗斯套娃一样自由堆叠，每层只专注单一职责增强。
- 装饰器必须继承/实现与被装饰对象相同的类型（通常是抽象类或接口），否则无法继续被下一层装饰
- 不能出现“装饰器直接 new 具体实现类”的硬编码，应始终通过构造参数接收被装饰对象
- Java I/O 包是经典案例：
BufferedInputStream装饰FileInputStream，而它本身又可被DataInputStream装饰——顺序影响行为（如先缓冲再读数据，不能反过来）
public interface Coffee {
String getDescription();
double getCost();
}
public class SimpleCoffee implements Coffee {
public String getDescription() { return "Simple coffee"; }
public double getCost() { return 2.0; }
}
public class Milk implements Coffee {
private final Coffee coffee;
public Milk(Coffee coffee) { this.coffee = coffee; }
public String getDescription() { return coffee.getDescription() + ", milk"; }
public double getCost() { return coffee.getCost() + 0.5; }
}
别把代理写成装饰，也别把装饰当成代理
一个典型误用：用装饰器做权限检查。这看似可行，但破坏了装饰的“正交增强”原则——权限不是业务功能的自然延伸，而是横切关注点，该由代理或 AOP 承担。反之，若用代理去实现多层日志+压缩+加密，就违背了代理“单一控制点”的定位，代码会迅速僵化。
- 代理适合处理与目标对象无关的通用逻辑（如事务、监控、RPC 序列化），且通常只有一层
- 装饰适合业务相关的、可选的、可叠加的功能扩展（如格式化、过滤、缓存），且层数由运行时决定
- 两者都依赖“接口一致”，但代理强调“替代性”，装饰强调“叠加性”；从 UML 类图看，代理是代理类→被代理类的单向依赖，装饰是装饰类→组件接口→被装饰类的环形依赖
真正难的是在需求模糊时判断：这个“包装”是为了管控访问，还是为了丰富能力？一旦方向错了，后续每加一层都会让维护成本翻倍。
