1. 一个看似简单却让代码越来越乱的“加日志”需求

先从一个真实的工作场景说起。你手头有一个用户服务，负责保存用户、查询用户，代码长这样：

public class UserServiceImpl { public void createUser(String name) { System.out.println("创建用户：" + name); // 真实的业务逻辑，比如插入数据库 } public String queryUserById(Long id) { System.out.println("查询用户：" + id); // 真实的查询逻辑 return "用户数据-" + id; } }

上线一段时间后，产品提了一个看起来不起眼的需求：所有用户操作的调用，都要求记录日志，方便后续排查问题。你会怎么改？

我相信不少人的第一反应是：直接在业务方法里加一行日志代码。比如在createUser和queryUserById里各加一行System.out.println("调用了createUser方法")。如果你真的这么干，短期内确实解决了问题，但用不了多久你就会被自己坑到——项目里二三十个业务类，每个类里六七个方法，每个方法都要手动加一遍日志，这其中的重复代码量相当可观。更麻烦的是，日志逻辑和业务逻辑全揉在一起，哪天日志格式要从文本改成 JSON，你得把所有业务类全翻出来改一遍，谁改谁知道有多酸爽。

这就引出了一个非常核心的问题：我们能不能在不改动业务类源码的前提下，给它附加一层额外的控制逻辑？答案就是本文要讲的代理模式，具体来说，是它的入门形态——静态代理。

代理模式这个词，很多刚学设计模式的人听到会觉得玄乎，其实道理特别朴素。我举个例子：你租房子，不会直接跑去找房东谈，而是通过中介。房东的房子还是那套房子，中介的存在给你提供了额外的服务——帮你筛选房源、处理合同、协调看房时间，而且很多时候你还不知道真正的房东是谁。在这个过程里，房东不用被各种租客骚扰，你也不用挨个房东联系，中介在中间做了一层转发和控制。这个中介，本质上就是一种代理。

静态代理，就是“代理”思想在代码里最直观、最原始的落地方式。它要求你在编译之前就手写一个代理类，声明好自己代理谁、增强什么逻辑、怎么把请求转发给真实对象。虽然现在有很多更“高级”的动态代理方案（比如 Spring AOP），但静态代理是理解一切代理方案的基础，绕不开。

这篇文章适合谁看？我觉得有两类人。一类是刚学设计模式、准备面试的 Java 后端开发，你需要把静态代理的代码结构、实现步骤、优缺点吃透，这是面试高频题；另一类是项目里拆过业务代码、被横切逻辑搞得焦头烂烂的工程师，你看完之后至少能想到一种更清爽的重构思路，而不是继续在业务方法里堆System.out.println。

2. 静态代理结构拆解：接口、目标对象、代理对象的三角关系

静态代理的结构并不复杂，它由四部分组成。你把这个三角关系（实际上加客户端是四角）在脑子里刻住，后面写代码就不会乱。

为什么非要一个接口？这是静态代理里很多人第一眼不理解的地方。有人会说：我直接让代理类继承UserServiceImpl不也一样能调用它吗？能调用是能调用，但问题很大。

接口在这里扮演的其实是一个“共同契约”的角色。它明确了目标类和代理类都遵守同一套方法签名，保证代理类能“装得像”真实对象。客户端只依赖接口，而不是依赖某个具体实现类，这样一来，你可以在不改动客户端代码的前提下，把代理类替换成另一个代理类，或者去掉代理、直接用真实对象。这种替换能力恰恰是代理模式的核心价值。如果你用继承，代理类和目标类绑死在继承树上，扩展性和替换性都会大打折扣。

然后看代理类的关键设计。它做三件事：

第一，持有目标对象的引用。这个引用是构造函数传进来的，也就是所谓的“组合”。组合优于继承，在代理模式里体现得很典型——代理类并不修改目标类的行为，只是在外面再包一层。

第二，调用目标对象的同名方法。代理类和目标类实现同一个接口，方法名一样，代理类在方法体内部调用target.someMethod()，完成真正的业务逻辑转发。

第三，在转发前后插入增强逻辑。这是代理存在的意义所在。比如方法调用前打印日志、检查权限、开启事务，方法调用后记录耗时、关闭资源、提交事务。这些逻辑你在业务类里写也能实现，但写在代理里，就能做到“业务类只关注业务，代理类只关注杂务”，职责分离。

说白了，静态代理的逻辑就是三句话：对外暴露同样的接口，对内持有目标对象，调用前后做增强。

期间有个非常容易被忽略的点：代理类转发调用时，方法的参数和返回值要原封不动地传出去。有些新手写代码时会在代理层对返回值做手脚，这在特定场景下（比如装饰器模式）是合理的，但纯粹的代理模式不应该篡改核心业务结果，否则调用方会拿到和真实执行结果不一致的数据，排查问题的时候会非常困惑。

3. 零基础也能跑通的静态代理完整实现（Java 代码）

光说不练假把式，我们把上文的租房中介例子翻译成代码。用一个最经典的“用户服务 + 日志增强”案例，一步步带你把它跑起来。

第一步：定义抽象接口

/** * 用户服务接口，约定目标类和代理类的共同行为 */ public interface UserService { void createUser(String name); String queryUserById(Long id); }

第二步：实现真实业务对象（目标类）

/** * 真实业务对象：只关心用户创建和查询，不掺杂任何附加逻辑 */ public class UserServiceImpl implements UserService { @Override public void createUser(String name) { System.out.println("[业务] 往数据库插入用户：" + name); // 模拟耗时操作 try { Thread.sleep(100); } catch (InterruptedException e) { e.printStackTrace(); } } @Override public String queryUserById(Long id) { System.out.println("[业务] 根据ID查询用户：" + id); return "用户姓名-张三，ID-" + id; } }

注意这里我特意把业务方法里的日志写成[业务]前缀，目的是和后面代理层添加的日志区分开，让你能清楚看到哪些日志来自业务层、哪些来自代理层。

第三步：手写代理类（静态代理的核心）

/** * 代理对象：在调用真实业务方法前后，附加日志增强 */ public class UserServiceProxy implements UserService { // 持有目标对象的引用 private final UserService target; // 通过构造函数传入目标对象 public UserServiceProxy(UserService target) { this.target = target; } @Override public void createUser(String name) { // 调用前增强 System.out.println("[代理] 准备调用 createUser，入参：" + name); long start = System.currentTimeMillis(); // 转发真实调用 target.createUser(name); // 调用后增强 long end = System.currentTimeMillis(); System.out.println("[代理] createUser 调用完成，耗时：" + (end - start) + "ms"); } @Override public String queryUserById(Long id) { System.out.println("[代理] 准备调用 queryUserById，入参：" + id); long start = System.currentTimeMillis(); // 转发真实调用，保留返回值 String result = target.queryUserById(id); long end = System.currentTimeMillis(); System.out.println("[代理] queryUserById 调用完成，耗时：" + (end - start) + "ms，返回：" + result); return result; } }

第四步：客户端调用

/** * 客户端：只面向接口编程，感知不到真实对象 */ public class Client { public static void main(String[] args) { // 创建目标对象 UserService target = new UserServiceImpl(); // 用代理对象包一层 UserService proxy = new UserServiceProxy(target); // 客户端调的是代理 proxy.createUser("张三"); System.out.println("------------------------"); String result = proxy.queryUserById(1L); System.out.println("查询结果：" + result); } }

运行结果如下：

[代理] 准备调用 createUser，入参：张三 [业务] 往数据库插入用户：张三 [代理] createUser 调用完成，耗时：101ms ------------------------ [代理] 准备调用 queryUserById，入参：1 [业务] 根据ID查询用户：1 [代理] queryUserById 调用完成，耗时：0ms，返回：用户姓名-张三，ID-1

到这里一个完整的静态代理就跑通了。你可以从输出里清晰地看到调用链：客户端 → 代理类 → 目标类 → 返回 → 代理类 → 返回 → 客户端。代理层没有修改任何业务代码，却成功插入了耗时统计。

这里我想特别强调一个实操原则：代理类的名字后缀建议统一用Proxy或Handler，并且放在和业务接口相同的包或者 commmon 层，千万别随手放在某个业务模块内部。我见过不止一次团队里静态代理类散落在各个微服务里，命名也各不相同，比如UserServiceWrapper、UserServiceDelegate、UserServiceInterceptor，维护起来相当混乱。代理类本身属于“横切关注点”，在工程上应该集中管理。

4. 静态代理的经典落地场景：权限校验、延迟加载与远程调用

日志记录只是静态代理的饭后甜点，真正让它出彩的是下面这几个场景。每个场景我在实际项目里都见过对应代码，而且理解它们之后，你自然就能看懂 MyBatis、Feign、Hibernate 这些框架里某些让人困惑的设计。

4.1 权限校验：把“有没有资格做这件事”从业务里剥离

用户管理系统里，删除用户、修改角色这类操作属于敏感操作，必须校验当前登录用户是否有权限。最常见的坏味道是每个操作入口都写一遍“判断用户是否管理员，不是就抛异常”，重复代码满天飞。更好看的是用静态代理统一做权限拦截。

public class UserServiceAuthorizationProxy implements UserService { private final UserService target; private final String currentUserRole; public UserServiceAuthorizationProxy(UserService target, String currentUserRole) { this.target = target; this.currentUserRole = currentUserRole; } @Override public void createUser(String name) { // 判断当前用户角色 if (!"ADMIN".equals(currentUserRole)) { throw new RuntimeException("无权限创建用户，当前角色：" + currentUserRole); } target.createUser(name); } @Override public String queryUserById(Long id) { // 查询接口是所有登录用户都能访问的，不校验，直接转发 return target.queryUserById(id); } }

你看，敏感操作的权限判断在代理层完成，业务代码完全感知不到“权限”这回事。哪天权限规则变了，你只需要改代理类，业务类一行不用动。这在实际项目里意义巨大——权限逻辑往往是集中变动的热点需求，把它独立封装远比散落各处好维护。

4.2 延迟加载：大对象的“假构造”

有一种很常见的性能问题：某个对象构造非常昂贵，比如要从数据库加载配置、初始化连接池、读取大文件，但应用启动后可能根本用不上它。如果用静态代理，可以在真正调用方法时才去创建真实对象。

public class LazyLoadProxy implements UserService { private UserService target = null; private final String configPath; public LazyLoadProxy(String configPath) { this.configPath = configPath; } private UserService getTarget() { if (target == null) { // 第一次使用时才初始化真实对象 System.out.println("[代理] 首次调用，开始初始化真实对象..."); target = new UserServiceImpl(); } return target; } @Override public void createUser(String name) { getTarget().createUser(name); } @Override public String queryUserById(Long id) { return getTarget().queryUserById(id); } }

延迟加载的思想在很多 ORM 框架里都有影子。比如 MyBatis 的关联查询就支持延迟加载：主查询先把结果返回，关联对象等到真正访问时才发起第二次查询。虽然框架层面的实现比这个静态代理精致得多，但底层“占位 + 第一次访问时替换成真实对象”的思想是一致的。理解静态代理的延迟加载实现，对你阅读框架源码会有很大帮助。

4.3 远程代理：你调的是代理，干活的在另一个进程

分布式系统里，服务 A 要调用服务 B 的方法，但两者不在同一个 JVM 进程里。怎么让调用方觉得就像调用本地方法一样舒服？远程代理就是干这个的。调用方持有的只是一个潜在的“代理对象”，代理内部把方法名、参数序列化成网络请求发过去，然后接收响应、反序列化、把结果返回给调用方。

这一点在 RPC 框架和 Spring Cloud OpenFeign 里体现得淋漓尽致。Feign 的@FeignClient接口，你在业务代码里调用它的方法，感觉就是一个普通 Java 接口，但真正执行时 Feign 会用代理机制把请求转成 HTTP 调用发到远端服务。虽然 Feign 底层用的是动态代理，不是本文的静态代理，但你想想，如果没有“代理对象在本地静态转换请求”的场景，这个概念就不可能推广开来。静态代理是这个思想的“手工版”，远程代理则是它在分布式世界的工程化产物。

4.4 缓存代理：查缓存 + 回源的一层壳

读多写少的场景下，你希望在查询方法前先查本地缓存，命中就返回，没命中再查数据库，然后把结果放回缓存。这个逻辑如果在业务代码里写，每个查询方法都得重复来一遍。

用静态代理就干净得多了。

public class CacheProxy implements UserService { private final UserService target; private final Map<Long, String> cache = new HashMap<>(); public CacheProxy(UserService target) { this.target = target; } @Override public void createUser(String name) { target.createUser(name); // 创建用户后清空缓存，保持一致性 cache.clear(); } @Override public String queryUserById(Long id) { if (cache.containsKey(id)) { System.out.println("[缓存] 命中 ID=" + id); return cache.get(id); } String result = target.queryUserById(id); cache.put(id, result); return result; } }

这类代码在很多系统里直接以“手动封一层 service”的形式存在。你如果用过 Spring Cache 的@Cacheable注解，本质上也差不多——通过 AOP 代理拦截方法调用，先查缓存再回源。静态代理就是理解这一切的最短路径。

5. 静态代理的“七宗罪”：为什么有大佬说别乱用

我不是让你看完上面的落地场景就到处去写静态代理。它在学习价值上意义重大，但在工程中也有不可忽视的瓶颈。面试官问你“静态代理的缺点”，你必须能一口气说出几个来。

5.1 一个代理类只能服务一类接口，容易“类爆炸”

你的接口有UserService、OrderService、ProductService、PaymentService……每个接口都要写对应的静态代理类，每个代理类里面又都是差不多的日志/权限/缓存模板代码。系统里有 20 个业务接口，你就可能维护 20 个代理类，还不算各种不同配置的变体。代理类的数量和接口数量线性增长，工程膨胀得很快。

这一点在项目里尤为真实。我见过一个小型后台管理系统，因为给每个 Service 接口都手动加了静态代理，光 proxy 类就 60 多个，其中大量代码长得一模一样，只是接口名字不同。从第 30 个接口开始，继续写代理类就是在复制粘贴。

5.2 接口加方法，代理类必须同步改

如果接口新加了一个方法，目标类要实现，代理类更必须实现——因为代理类也实现了接口。这个“同步改动”是很反直觉的麻烦：你改业务接口，明明只是想加个新功能，结果还要记得去改对应的代理类，把新方法里的增强逻辑也补上。改漏了，编译直接报错；用反射硬编过，运行时就会在代理类这里静默失败。不管是编译期还是运行期，这个负担都在。

从代码维护的角度看，凡是“改 A 必须同步改 B”的设计，都隐藏在等待爆发的炸弹。接口是系统中变动最频繁的部分之一，静态代理把这种联动性放大到了一个不可忽略的程度。

5.3 增强逻辑没法复用，本质还是代码重复

虽然静态代理把“增强”从业务代码里抽出来了，但只是把重复从业务类转移到了代理类。你给UserService写了日志代理，给OrderService再写一个日志代理，你仔细观察会发现，两个代理类里的日志代码几乎一模一样，只是调用的接口和方法不同。真正的代码复用，应该是“日志逻辑写一次，任何接口都能套用”，静态代理做不到，动态代理（尤其是 AOP）才能做到。

所以说白了，静态代理解决的是“业务的职责分离”，但没解决“增强的复用”。它把脏活从业务代码里挪到了代理代码里，好了一些，但没完全好。这也是为什么 Spring 框架会选择动态代理而非静态代理作为 AOP 的底层实现。

5.4 和装饰器模式的边界容易被混淆

还有一个容易踩晕的点——静态代理和装饰器模式长得太像了，都是“包一层”，都要实现相同接口，都有增强逻辑。有面试官就喜欢拿这个区分来考候选人。

我的理解是：代理模式侧重的是“控制访问”，装饰器模式侧重的是“增强功能”。代理模式中客户端通常不直接接触真实对象，真实对象可能不在本地、需要延迟加载、需要权限拦截；而装饰器模式中客户端知道自己在使用被装饰后的对象，装饰器的目的是给对象叠加能力（比如给输入流加缓冲、加密）。从代码结构上说两者几乎相同，关键看设计意图。你在写静态代理前，先想清楚自己是“为了控制访问”还是“为了增强能力”，这决定了类的命名和职责定位。

5.5 静态代理别扭的第三个点：多级代理会绕晕

如果既要权限校验，又要日志，又要缓存，你必须写多个代理类，然后按顺序组合：new CacheProxy(new AuthorizationProxy(new LogProxy(target)))。链一旦拉长，调用关系和执行顺序就不直观了。而且如果代理之间相互调用的顺序有讲究（比如必须先鉴权再走缓存），你必须自己维护这个嵌套顺序，这对后续接手代码的人来说是一场阅读理解考试。

5.6 静态代理的性能优势也别忽略

如果说缺点说了这么多，老实讲静态代理也有它的生存空间。它最大的一个优点就是：没有反射调用，性能开销几乎为零。

动态代理无论 JDK 还是 CGLIB，最终都绕不开反射或字节码生成带来的性能代价。虽然现代 JVM 对反射已经做了很多优化，但在极高频调用路径上（比如每秒钟几十万次的方法调用），动态代理的开销会产生可见的损耗。静态代理就是一次普通的方法调用，没有额外机制介入，对性能极度敏感的场景，静态代理并未被淘汰。

5.7 使用静态代理的取舍判断

到底什么时候用静态代理？我的建议是这么判断的：

• 只有一个或极少数接口需要增强，且增强逻辑简单（比如就加一行日志）——静态代理完全够用。
• 你明确知道这个代理类永远不会有太多变体——手写一两个成本很低，何必引入动态代理机制。
• 性能要求极其苛刻，方法调用频率极高——静态代理的开销最可控。
• 接口数量多、变动频繁、增强逻辑复杂——直接上动态代理或者 AOP 框架，别在静态代理里挣扎。

这套取舍逻辑，面试的时候讲出来，比单纯背“静态代理缺点”要加分很多，因为这确确实实是基于工程经验总结出来的判断。

6. 静态代理和动态代理的分界线：什么时候该转向动态方案

说到静态代理，几乎绕不开动态代理这个话题。面试官即使不主动问，也很可能拐弯抹角地问“AOP 底层实现是什么”“JDK 动态代理的原理是什么”。这节我把对比讲透，你就知道静态代理在这张地图里处于什么位置。

6.1 动态代理的核心差异：代理类是在运行时生成的

JDK 动态代理的核心类是java.lang.reflect.Proxy。你不用手写任何代理类，而是传入接口、InvocationHandler，在运行时动态生成代理类的字节码。

import java.lang.reflect.InvocationHandler; import java.lang.reflect.Method; import java.lang.reflect.Proxy; public class JdkDynamicProxyExample { public static void main(String[] args) { UserService target = new UserServiceImpl(); UserService proxy = (UserService) Proxy.newProxyInstance( target.getClass().getClassLoader(), new Class[]{UserService.class}, new InvocationHandler() { @Override public Object invoke(Object proxy, Method method, Object[] args) throws Throwable { System.out.println("[动态代理] 调用方法：" + method.getName()); Object result = method.invoke(target, args); System.out.println("[动态代理] 方法调用结束"); return result; } } ); proxy.createUser("李四"); String user = proxy.queryUserById(1L); System.out.println("查询结果：" + user); } }

运行结果：

[动态代理] 调用方法：createUser [业务] 往数据库插入用户：李四 [动态代理] 方法调用结束 [动态代理] 调用方法：queryUserById [业务] 根据ID查询用户：1 [动态代理] 方法调用结束 查询结果：用户姓名-张三，ID-1

从获取增强效果的角度来说，动态代理和静态代理殊途同归，但关键的差异已经显现：代理类的数量不再随接口数量线性增长。你写一个 InvocationHandler，就可以代理所有接口，只要它们通过Proxy.newProxyInstance要求生成代理。

当然，JDK 动态代理有一个硬性约束——被代理的类必须实现了至少一个接口。如果目标类没有接口，就需要用 CGLIB，通过生成目标类的子类来代理，这个原理本质上就是继承的用法。Spring AOP 能同时兼容这两种，你大概能猜到那是怎么回事了。

6.2 静态代理反而是理解动态代理的跳板

很多人直接去啃 JDK 动态代理源码，一上来就被InvocationHandler、Proxy.newProxyInstance、getClassLoader这些东西绕晕。我觉得路线完全可以反过来：你先把静态代理的知识结构吃透——接口、目标对象、代理对象、客户端四个角色的协作关系都清楚了，再去看动态代理，你会发现动态代理就是“不再手写代理类，而是用 JDK 在运行时照着接口生成一个代理类”，然后你来写这个代理类的方法体（也就是 InvocationHandler 里的invoke方法）而已。

这样理解，动态代理的神秘感一下就没了。它并没有发明新的代理思想，只是把“手写代理类”这个环节自动化了。

6.3 选择一张务实的决策表

实际项目里该怎么选？我的建议是分三档：

• 项目就一个地方要用代理，简单顺手，手写静态代理；
• 项目里接口多、增强逻辑统一，优先上 Spring AOP（内部自动选 JDK 或 CGLIB）；
• 项目用到 RPC、缓存这类框架级功能，不用自己纠结——框架底层已经帮你做好了，你只需要理解它们背后的代理思想，以便出了问题能排查。

6.4 为什么不建议一上来就绕过静态代理

现在网上很多教程一讲到“代理模式”就直接上动态代理，甚至直接上 Spring AOP，把静态代理一笔带过。我觉得这对初学者是不太友好的。静态代理虽然代码“土”，但它把代理模式的骨架完整地暴露在你面前，没有任何魔法。

学习设计模式这件事，我一直觉得核心不在于记那几个类图和名词，而在于建立“抽象和封装”的直觉。你去读 Spring 源码，真正读懂之后发现很多东西都是把一些非常朴素的理念施加了工程化包装。静态代理就是你练手感的地方：它小、简单、可以完整跑通，让你在没有框架帮忙的情况下，亲手实现一次“控制访问”的思想。

等你有天接手一个遗留系统，看到里面到处散落着“业务逻辑与日志权限耦合”的代码，你脑子里能立刻浮现出一个静态代理类的雏形，知道该在哪一层去拆解，那这篇文章的目的就算真正达到了。

我个人在实际写代码的时候，静态代理用得其实不算多，因为大多数情况下 Spring 已经把 AOP 这类动态方案融入框架了。但每次排查框架相关的诡异问题时，我都习惯先在草稿纸上画一下“谁在代理谁、调用链是怎么走的”，而这张图的原型，恰恰就是在理解静态代理的时候刻进脑子里的那套三角关系。所以我还是建议你亲手敲一遍本文的代码，体会一下代理类“一手接请求、一手转目标”的感觉，再去看动态代理，会顺畅很多。