Java无@decorator语法，装饰器模式需手动实现：统一接口+组合包装+显式委托调用；适用日志、权限等横切场景；避免继承、静态工具类及非接口方法暴露；Spring@Transactional实为运行时代理而非手写装饰器。
Java 里没有 @decorator，得靠接口 + 组合 + 接口实现类包装
Java 本身不支持 Python 那种 @decorator 语法，所谓“装饰器模式”是手动实现的结构设计：用一个类包装另一个类，两者实现同一接口，通过委托调用增强行为。不是语言特性，是编码约定。
常见错误现象：NullPointerException（忘了初始化被包装对象）、死循环调用（delegate.method() 写成 this.method()）、接口方法漏实现（导致编译失败但容易忽略）。
使用场景：日志、权限校验、缓存、事务代理——所有需要在不改原逻辑前提下加横切行为的地方。
- 必须定义统一接口，比如
Service，原始类和装饰器都实现它 - 装饰器构造函数必须接收该接口类型的参数（即被包装对象），不能直接 new 具体实现类
- 每个方法里显式调用
delegate.xxx()，不是自动转发
为什么不能用继承？继承会破坏开闭原则且无法叠加
继承看似简单，但一旦要加第二个功能（比如既加日志又加缓存），就得写 LoggingAndCachingService extends CachingService，再加一个就爆炸。而装饰器可以链式组合：new LoggingDecorator(new CachingDecorator(new RealService()))。
立即学习“Java免费学习笔记（深入）”；
性能影响：每次调用多一层方法跳转，但现代 JVM 基本内联掉，可忽略；兼容性无问题，纯 Java SE 5+ 就行。
容易踩的坑：RealService 如果有非接口方法（比如 getInternalState()），装饰器无法暴露——这是故意的，装饰器只承诺接口契约。
Spring 的 @Transactional 看起来像装饰器，但它其实是代理（Proxy）
Spring 的 @Transactional 不是手写的装饰器类，而是运行时生成代理对象（JDK 动态代理或 CGLIB）。你写的 UserService 类本身没变，Spring 在容器里替换成一个包装了事务逻辑的代理实例。
关键区别：
- 手写装饰器：编译期确定，类型安全，调试直观，但要自己 new 和传参
- Spring 代理：运行期织入，配置驱动，支持 AOP 表达式，但
this.method()调用会绕过代理（导致事务失效） - 错误现象：
Transaction not active或日志没打出来，大概率是因为在同一个类里调用了本类另一个@Transactional方法
别用静态工具类模拟装饰器——它破坏封装且无法组合
有人写个 LogUtils.wrap(Service s) 返回 Service，看起来简洁，但本质是工厂+匿名内部类，每次都要重复写逻辑，没法复用装饰器状态（比如缓存装饰器要持有一个 Map），更没法嵌套。
正确做法：每个装饰器是独立类，有自己字段、构造逻辑和生命周期。比如 CachingDecorator 持有 ConcurrentHashMap，LoggingDecorator 持有 Logger 实例。
参数差异：装饰器构造函数只接受接口类型，不要塞进具体配置（如缓存大小），那属于装饰器内部策略，应通过 Builder 或构造参数分离。
复杂点在于：多个装饰器嵌套时，执行顺序由 new 的顺序决定，而不是注解顺序——这点和 Spring AOP 完全不同，容易想当然出错。
