Spring Boot原型Bean代理创建异常：类型冲突与排查方案

我在Spring Boot项目里排查过一个特别典型的报错配置了原型作用域的Bean启动时一切正常等真正调用的时候Spring容器直接甩出一个Proxy创建异常提示类型不匹配。那是一个多商户跨境商城的后台服务用Spring Boot加MyBatis做的某个订单状态机处理器为了隔离状态数据特意把处理器设计成了原型作用域然后配合AOP切面做了权限拦截启动成功、注入也成功偏偏在第一次请求进来的时候炸了。当时第一反应是代理配置写错了翻来覆去核对Scope的取值和proxyMode最后发现真正的问题出在Spring对原型作用域Bean创建代理的机制上里面藏着一个非常容易踩的设计冲突。这个问题的本质是原型作用域本身的生命周期语义和Spring AOP代理对象的创建机制两者之间天然存在张力。单例Bean的代理是容器启动时一次性创建并缓存的而原型Bean每次获取都要新生成一个目标实例再基于这个新实例去创建代理。听起来没什么问题但当你把proxyMode设置为ScopedProxyMode.TARGET_CLASS或INTERFACES时Spring会尝试创建一个代理对象而代理对象的类型规则和原型Bean实际暴露出来的类型经常对不上。这个冲突一旦触发轻则强转异常重则Bean初始化失败而且报错信息往往会把你引向错误的方向。这篇文章我会把原型作用域Bean代理创建异常这件事拆开讲清楚包括异常产生的完整链路、两类代理模式的差异、最典型的几种报错形态、一套可以复用的排查思路以及四种能直接落地的解决方案。如果你是Spring Boot开发用过原型作用域或者踩过AOP代理和Bean作用域相互纠缠的坑这篇文章应该能帮你省下不少排查时间。1. 为什么有人会在原型作用域上挂代理一个合理但危险的配置先讲清楚这个组合是怎么来的。在Spring Boot项目里绝大多数字段注入都是单例Bean单例的好处是容器管理生命周期、状态共享、性能开销小。但有些场景下Bean本身必须携带独立的运行状态比如一次请求专属的上下文对象、一个不能并发共享的解析器、或者像上面提到的订单状态机处理器每次处理都要有独立的内部状态否则并发请求会互相污染数据。这时候最直接的办法就是把Bean声明成原型作用域Scope(prototype)让Spring每次获取时都new一个新实例。问题在于如果你的代码里到处都用Autowired去注入这个原型BeanSpring会陷入一个经典的“单例吞掉原型”陷阱——单例Bean在初始化时注入一次原型Bean之后这个原型Bean就被固定在单例内部了下次再拿拿到的还是同一个实例原型作用域彻底失效。为了让原型Bean在每次注入时都能获得新实例Spring官方给出了一个看起来很优雅的解法给原型Bean加一个代理。配置长这样Service Scope(value prototype, proxyMode ScopedProxyMode.TARGET_CLASS) public class OrderStateHandler { public void handle(OrderEvent event) { // 业务逻辑 } }加了proxyMode之后Spring容器里实际存放的是一个代理对象外部通过这个代理去调用每次调用都会从容器中重新获取一个新的目标实例再委托给这个新实例执行。这样一来单例内部持有的是代理代理帮你每次换新原型语义就保住了。这个设计思路本身没问题但它把Bean的创建过程从“直接new目标类”变成了“创建目标类创建代理类”两步。问题就出在第二步尤其是当你的目标类、你的接口设计、你的代理配置三者之间出现不匹配时。这个配置之所以“危险”是因为很多开发者只知道加上proxyMode能让原型生效却不知道Spring创建代理时对目标类型有严格的限制条件。一旦目标类不满足限制Spring的ProxyFactory抛出的异常信息非常绕比如“Bean named orderStateHandler is expected to be of type xxx but was actually of type jdk.proxy1.$Proxy123”这句话看起来像是类型不匹配实际上是在告诉你代理创建走了JDK动态代理路线而你的注入点用的是类类型而不是接口类型。我遇到的那次异常就是典型的JDK代理类型错位。目标类实现了一个接口Spring判断它满足JDK动态代理的条件于是生成了一个实现了该接口的代理对象但我的业务代码里注入的是OrderStateHandler这个具体类而非接口代理对象压根不是OrderStateHandler的子类强转失败容器启动阶段直接报错。从这个角度说原型Bean的代理异常本质上是一个类型系统冲突而不是什么神秘的黑盒故障。2. 代理创建异常的真实源头JDK动态代理与CGLIB在原型场景下的设计冲突要真正理解这个异常得把Spring创建代理的底层逻辑摊开看。Spring AOP也好Scope的proxyMode也罢底层都是通过ProxyFactory来生成代理对象的。ProxyFactory在创建代理时会做一次关键决策使用JDK动态代理还是CGLIB代理。2.1 代理模式的选择逻辑你的Bean走的是哪条路线Spring的默认决策规则很简单参考DefaultAopProxyFactory的实现可以概括成一句话如果目标类暴露了接口且你配置的代理目标针对的是接口比如proxyTargetClassfalse或者proxyModeScopedProxyMode.INTERFACESSpring就优先走JDK动态代理如果你明确要求代理目标类本身proxyTargetClasstrue或者proxyModeScopedProxyMode.TARGET_CLASSSpring会走CGLIB。这里有个容易忽视的细节。ScopedProxyMode.TARGET_CLASS确实会强制Spring使用CGLIB但CGLIB不是万能的。CGLIB通过生成目标类的子类来实现代理这意味着目标类必须能被继承。如果目标类被final修饰或者目标方法被final修饰CGLIB直接无能为力。JDK动态代理则相反它要求目标必须实现至少一个接口它生成的是一个实现了相同接口的独立代理类和原来的目标类之间没有任何继承关系。很多人的Spring Boot项目里大量使用Service、Component这些类通常不实现额外接口所以平时遇到的代理大多是CGLIB。这养成了一个惯性以为加了proxyMode ScopedProxyMode.TARGET_CLASS就一定能生成CGLIB代理。但实际上如果你的目标类实现了接口且某些继承链路导致Spring判定需要走JDK代理最终生成的代理对象类型和你注入的类型就会对不上。2.2 原型作用域叠加代理的“三次new”链路理解原型代理的创建链路是整个问题排查的钥匙。一个原型Bean加代理之后Spring容器在获取这个Bean时会经历三个步骤根据Bean定义创建原始目标实例相当于执行new OrderStateHandler()。根据proxyMode创建对应的代理工厂基于目标实例生成代理对象。将这个代理对象返回给调用方并放入当前获取周期的上下文如果有的话。没有代理时每次获取就是直接new一个简单直接。有代理时每次获取都变成“new一个目标再new一个代理”而代理对象会持有目标类的类型信息。问题就在于代理对象声称自己是什么类型和真实目标实例是什么类型未必一致。JDK代理声称自己是“实现了某些接口的对象”不声称自己是目标类的子类CGLIB代理声称自己是“目标类的子类”但它要求目标类可继承。原型作用域在这个链路上起到的作用是放大问题。单例Bean创建代理整个过程在容器启动时执行一次出错了启动阶段就能暴露错误信息相对清晰。原型Bean创建代理Spring默认走延迟创建逻辑很多校验被推迟到第一次获取时才触发于是你在启动时看不到异常等到线上第一个请求进来突然抛出一大串BeanCreationException排查时还以为是业务代码的问题。我那次线上事故就是这么来的启动日志干干净净压测脚本一发请求后台瞬间刷出几十条异常堆栈。2.3 CGLIB对原型Bean的隐形限制final类与不可继承陷阱CGLIB代理对目标的限制不止final类这一条。它要求目标类必须有可访问的无参构造器或者至少有一个Spring可以调用的构造器因为CGLIB生成子类时默认会调用父类的构造器。如果你的原型Bean只在构造器中通过参数完成初始化没有无参构造器CGLIB就会在创建代理时失败。Spring Boot 2.x之后Spring对CGLIB构造器的处理有所放宽但底层依赖的Objenesis在某些环境下依然可能踩坑。对于原型Bean来说还有一个更隐蔽的问题原型Bean的目标实例每次都是新的而代理对象往往是复用的。当Spring用CGLIB创建代理时代理对象本身绑定的是“如何获取目标实例”的逻辑。CGLIB代理内部通过AdvisedSupport持有目标实例的引用。Spring在生成原型Bean的代理时处理方式是对每次方法调用重新获取目标Bean。这个重获取的动作依赖目标Bean的targetSource而targetSource的创建过程会再一次触发目标类的实例化。如果你在目标类的构造器里写了复杂逻辑比如初始化连接池、加载远程配置每调用一次代理方法就要走一遍构造器性能问题和大规模异常就会被放大。这已经不是单纯的代理创建异常而是架构设计上的隐患。3. 三种典型异常形态从报错信息反推故障根因不同项目遇到的异常表现形式不同但核心原因大同小异。我整理了三种最高频的异常形态结合实际的报错信息来分析根因这种“从报错反推问题”的方式排查效率最高。3.1 类型不匹配异常JDK代理伪装失败的典型症状这是最经典的一种。报错信息长这样org.springframework.beans.factory.BeanCreationException: Error creating bean with name orderStateHandler: Bean named orderStateHandler is expected to be of type com.example.handler.OrderStateHandler but was actually of type jdk.proxy1.$Proxy124翻译一下就是Spring容器想要给你一个OrderStateHandler类型的Bean结果实际创建的Bean是jdk.proxy1.$Proxy124类型两者之间没有继承关系Spring在最后一步类型校验时当场拒绝。这个异常的根因链条是OrderStateHandler实现了某个接口比如IOrderHandler配置了proxyMode ScopedProxyMode.INTERFACES或Spring根据某种条件选择了JDK动态代理代理对象只实现了IOrderHandler接口没有继承OrderStateHandler类。如果注入点声明的类型是接口这个代理完全能用如果注入点声明的是具体类就会触发异常。在我那个商城项目里问题出现在MyBatis的Mapper代理和Service类之间的接口设计上。OrderStateHandler实现了IOrderHandler接口但业务代码里注入时用的是具体类类型。开发者的本意是“类内部有额外方法接口里没暴露”但这种设计遇到JDK代理直接崩了。3.2 无法继承final类异常CGLIB强制代理时的硬性失败再来看CGLIB路线的典型报错org.springframework.aop.framework.AopConfigException: Cannot subclass final class com.example.handler.OrderStateHandler看到这个报错基本可以断定你配置了proxyMode ScopedProxyMode.TARGET_CLASS或者EnableAspectJAutoProxy(proxyTargetClass true)强制Spring走CGLIB但目标类的定义里带了final关键字。CGLIB要生成目标类的子类final类禁止继承只要碰到就直接抛异常。我遇到过的情况是原型Bean的类本身没有final但它的某个父类是final的。CGLIB代理生成子类时不一定要继承整个父类链路但如果目标类直接继承了一个final父类Spring的CglibAopProxy在判断可继承性时一样会失败。这种情况容易迷惑人表面上看“我的类没被final修饰啊”实际上一查继承链父类被锁死了。还有一种类似的报错是No default constructor found。CGLIB创建代理子类时需要调用父类构造器如果你的原型Bean只有一个带参构造器而且没有通过Spring的Autowired构造器注入优化处理好CGLIB在实例化代理类时会直接报构造器不存在。这类异常在Spring Boot 2.4之前比较常见因为那之前Spring对CGLIB的构造器选择逻辑相对简单。3.3 序列化与强转异常代理类型带来的运行时陷阱第三种形态更难排查因为它不在Bean创建阶段报错而是在运行时通过反射或序列化访问代理对象时触发。比如java.lang.ClassCastException: class jdk.proxy1.$Proxy125 cannot be cast to class com.example.handler.OrderStateHandler或者在使用Redis缓存、消息队列序列化时报出NotSerializableException。原型Bean代理对象的序列化是一个常见盲区。JDK代理生成的类实现了接口但默认不实现SerializableCGLIB代理的类继承自目标类如果目标类没实现Serializable代理对象同样不能序列化。当你的原型Bean被放进缓存、写入Redis、经过消息队列传输就会在序列化环节炸掉。我之前排查过一个跨服务的订单事件投递问题原型Bean里注入了ApplicationContext在序列化时直接爆掉因为ApplicationContext本身就是不可序列化的而代理对象持有它的引用序列化整个对象时就像打包一个里面装着炸弹的箱子。这类异常的核心就是代理不等于原对象。代理对象在外壳上伪装成目标类的样子但它的内部结构、父类关系、序列化行为都和真实目标类不同。你必须在设计阶段就意识到这个加了代理的原型Bean它的类型语义已经被Spring修改了。4. 从报错到定位一套完整的排查链路与最小化复现排查这类问题最忌讳的是看到一个异常就直接改配置把proxyMode改来改去靠猜来解决问题。我整理了一套实际验证过的排查链路按这个顺序走基本能在半小时内定位根因。4.1 第一步核对Bean定义确认作用域和代理模式的真实配置拿到异常后第一件事不是看堆栈而是回到Bean定义本身。有几个关键信息必须确认清楚Scope的value到底是prototype还是sington有些人写着写着作用域没写对导致代理创建逻辑完全变了。proxyMode是ScopedProxyMode.TARGET_CLASS还是ScopedProxyMode.INTERFACES这决定了走CGLIB还是JDK代理。类上有没有同时标注Aspect、Transactional、Async等会触发AOP注解的标记这些注解同样会创建代理和proxyMode的代理叠加后会生成多层代理异常更容易出现。可以写一段代码在启动时打印Bean的实际类型直接确认走的是哪条代理路线Bean public CommandLineRunner proxyTypeChecker(ApplicationContext context) { return args - { Object bean context.getBean(orderStateHandler); System.out.println(Bean class: bean.getClass().getName()); System.out.println(Is JDK proxy: java.lang.reflect.Proxy.isProxyClass(bean.getClass())); System.out.println(Is CGLIB proxy: org.springframework.cglib.proxy.Enhancer.isEnhanced(bean.getClass())); }; }这段代码能帮你把迷雾拨开如果Is JDK proxy打印为true说明走了JDK动态代理如果是CGLIBEnhancer.isEnhanced会返回true。拿到这个信息后面的判断就快很多。4.2 第二步区分“接口注入”和“类注入”确认类型冲突是否成立排查链路里最核心的一步是确认注入点的类型声明。我遇到不止一次开发者抱怨Spring报类型不匹配最后发现原因是注入点用了具体类。Spring的代理对象类型规则是这样的注入点类型声明JDK代理实现接口CGLIB代理继承目标类接口类型正常注入正常注入具体类类型注入失败类型不匹配正常注入Object类型正常注入正常注入所以当你看到类型不匹配异常时优先检查所有注入这个Bean的地方看它们的字段类型是接口还是具体类。如果是具体类JDK代理基本必炸如果目标是接口JDK代理能正常运作。这个检查用IDE的全局搜索就能完成CtrlShiftF搜一下类名所有引用点一目了然。4.3 第三步最小化复现把问题从业务上下文里剥离如果上一步还没定位到根因建议做一个最小化复现工程。不要直接在大型业务项目里调试因为上下文的干扰太多了各种AOP配置、事务管理器、MyBatis插件都可能改变代理行为。我给你一个极简的复现模板// 接口与实现类 public interface IOrderHandler { void handle(String event); } Component Scope(value prototype, proxyMode ScopedProxyMode.INTERFACES) public class OrderStateHandler implements IOrderHandler { Override public void handle(String event) { System.out.println(handle: event); } } // 一个单例Bean注入具体类类型 Component public class OrderService { Autowired private OrderStateHandler orderStateHandler; }这个工程只要启动就能复现类型不匹配异常。把代码简化到这种程度再配合第一步的打印代码你就能非常清晰地看到Spring在哪个环节拒绝了你。我曾经用这个模板验证了三种不同代理模式下的行为差异花的时间不超过十分钟。4.4 第四步检查继承链与构造器排除CGLIB的隐蔽限制如果走的是CGLIB路线问题还没解决那就需要检查目标类的继承链和构造器。按这个顺序检查目标类本身是否被final修饰目标类的父类链路里有没有final类目标类是否声明了自定义构造器如果是有没有配置无参构造器有没有Autowired构造器注入如果只有一个带参构造器Spring能不能正确识别我实际遇到过一个诡异的场景目标类本身没问题父类也被Spring管理得很好但父类里有个final方法。CGLIB代理对final方法的处理方式是跳过增强也就是说方法照常可以调用只是不走代理逻辑。但如果你把“代理必须拦截所有方法”作为前提去写代码就会出现某个方法的行为和其他方法不一致看起来像是“时灵时不灵”。这类问题虽然不是创建异常但会诱导你往代理创建方向排查浪费不少时间。5. 四种可落地的解决方案从改配置到重构设计定位到根因之后下一步就是选择解决方案。没有绝对最优的方案每种方案都有它的适用边界和代价我按推荐程度从高到低逐一说明。5.1 方案一去掉proxyMode改用ObjectProvider延迟获取这是我最推荐的做法尤其是当你的原型Bean主要被少数几个单例组件使用的时候。思路是不创建代理保持原型Bean的纯粹性在注入单例组件时不直接注入原型Bean而是注入一个ObjectProviderT每次需要时调用getObject()手动获取新实例。Service Scope(prototype) public class OrderStateHandler { // 业务逻辑不带代理 } Service public class OrderService { Autowired private ObjectProviderOrderStateHandler handlerProvider; public void process(OrderEvent event) { OrderStateHandler handler handlerProvider.getObject(); handler.handle(event); } }这个方案的优势是彻底绕开了代理从根上消除了代理创建异常。成本是你必须在每次使用原型Bean的地方调用getObject()不能像Autowired那样字段注入后直接使用。但说实话原型Bean本来就该这样用——每次显式获取语义清晰性能也没有代理开销。对于需要AOP增强的原型Bean这个方案不适用因为AOP本身就要求代理介入。但纯粹为了“每次new一个”的场景ObjectProvider是比代理更优雅的解法。5.2 方案二Lookup方法注入用容器回调换掉字段注入如果不想改业务代码的调用方式又希望保住原型语义Lookup是另一个思路。它是Spring提供的方法级注入在单例Bean里定义抽象方法或具体方法方法内部由Spring容器重写并返回新的原型Bean实例。Service Scope(prototype) public class OrderStateHandler { public void handle(OrderEvent event) { } } Service public abstract class OrderService { public void process(OrderEvent event) { getHandler().handle(event); } Lookup protected abstract OrderStateHandler getHandler(); }Spring启动时会为OrderService生成CGLIB子类重写getHandler()方法每次调用都会从容器获取新的原型Bean。这个方案不需要代理原型Bean而是代理了单例Bean本身代理类型是OrderService的子类不会出现类型不匹配。注意一点Lookup方法不能是private且目标类不能是final因为Spring也要对它生成CGLIB子类。我觉得这个方案适合那些不想改变注入风格、但原型Bean数量不太多的场景。缺点是抽象类和字段注入的风格很多团队会觉得别扭。5.3 方案三手动ApplicationContext.getBean()最朴素也最可控用ApplicationContext手动获取Bean是最直接、最容易理解的方式缺点是耦合了容器。如果你在业务代码里直接注入ApplicationContext每次需要原型Bean时调用context.getBean(OrderStateHandler.class)。我见过一些老项目大量使用这种方式虽然是“不够Spring”的写法但它的好处是出问题的时候你完全清楚Bean是怎么来的代理只在确实需要的地方存在。使用这个方案时要注意一点ApplicationContext直接拿到的原型Bean如果没有配置代理返回的就是真实目标类的实例不存在类型问题如果配置了代理返回的还是代理对象该有的问题照样有。所以使用这个方案时建议把proxyMode去掉只在代码层面控制获取时机。这样能做AOP吗能AOP代理是另一套机制Spring AOP的自动代理依然会生效因为Aspect定义的切面会通过AnnotationAwareAspectJAutoProxyCreator为目标类创建代理和原型作用域本身不冲突。5.4 方案四保留代理但修正类型设计让代理模式与注入点匹配如果因为AOP确实需要代理且原型作用域也必须保留那就该修正类型设计。核心原则很简单走JDK代理就注入接口走CGLIB就严格检查类是否可继承。具体操作是如果使用ScopedProxyMode.INTERFACES确保所有注入点都声明为接口类型不要在字段里写具体类。如果使用ScopedProxyMode.TARGET_CLASS检查目标类和父类是否有final修饰检查构造器是否满足CGLIB要求。把需要AOP增强的方法定义在接口里让切面能够通过接口代理拦截到。我用一个对比表格把各方案的核心特点列出来方便你按场景选择方案是否保留代理类型冲突风险侵入性适用场景去掉proxyMode ObjectProvider否无中单纯需要原型语义无AOPLookup方法注入否无代理单例中不想改调用方式类可继承手动getBean否可配低高小团队、快速实现修正类型设计是受控低必须用AOP切原型Bean按我的经验绝大多数场景用方案一就够了方案四留给那些“没AOP日子过不下去”的模块。6. 工程实战中的三类延伸问题序列化、性能与测试陷阱解决了创建异常不代表原型Bean加代理这件事就万事大吉了。在真实项目里还有三类问题会卷土重来我把它们单独列出来因为这些都是我在实际项目中踩过或者看别人踩过的坑。6.1 代理对象序列化问题缓存与MQ场景下的隐性炸弹原型Bean的代理对象如果被序列化几乎必炸。上面说过JDK代理不默认支持SerializableCGLIB代理的序列化行为取决于目标类但无论哪种代理对象内部持有的状态都不是普通POJO能比拟的。典型的高危场景有三个原型Bean被放入Spring Cache缓存尤其是Redis缓存。原型Bean作为事件对象投递到消息队列。原型Bean被放到Session或分布式缓存中。解决思路是不要在原型Bean里塞不可序列化的依赖比如ApplicationContext、DataSource如果必须持有就把它们标记为transient。更稳妥的做法是把原型Bean设计成纯数据处理器所有依赖都从方法参数传入而不是从内部持有。这句话可以说是原型Bean设计的黄金法则我见过太多人因为图省事在原型Bean里直接注入各种单例组件最后序列化问题层出不穷。6.2 每次调用代理都要new目标实例性能开销容易超预期原型Bean加代理意味着每次方法调用都要触发一次“获取新目标实例”的动作。这个动作的代价不只是new一个对象那么简单Spring的ScopedProxyTargetSource在获取目标实例时需要从容器重新走一遍完整的Bean获取流程包括处理Autowired依赖、执行BeanPostProcessor、初始化回调等等。如果你的原型Bean依赖了复杂的组件每次调用都会被放大。我实测过一个场景某个原型处理器依赖了三个Service每个Service又依赖了数据库连接、Redis连接一次代理方法调用相当于同时初始化了一堆对象。压测时吞吐量直接掉了一半。解决方案是控制原型Bean的粒度尽量让原型Bean只持有轻量状态重量级依赖在构造时从外部传入或者干脆改用方案一通过ObjectProvider控制获取频率不要每次都走到代理方法里才去拿。6.3 单元测试与集成测试的代理陷阱最后说说测试。Spring Boot单测时很多人直接new OrderStateHandler()测得好好的一接上Spring容器就报错原因就是代理行为只在容器里才生效。反过来也有坑集成测试里SpringBootTest加载了完整上下文原型Bean的代理已经创建好了你在测试里断言handler instanceof OrderStateHandler就成为false因为它是JDK代理对象。这个断言失败会误导人让人以为业务代码有Bug实际上是代理类型和原始类的差异。我的建议是测试中使用真实容器获取Bean并在断言前打印bean.getClass()不要想当然地断言具体类类型如果必须断言类型就断言接口类型。另外给原型Bean写单元测试时不需要模拟代理的存在直接测试目标类的行为即可代理逻辑是Spring框架的职责不属于你的业务测试范围。总结一下我踩坑后的几个判断标准在这篇文章的最后我不打算做什么高屋建瓴的总结只想说几个我实际踩完坑之后沉淀下来的判断标准方便你以后遇到类似问题能快速做决策。第一个标准如果你发现自己需要给原型Bean加代理先想一想能不能换一种方式表达“每次获取新实例”。加代理不是唯一解决方案ObjectProvider、Lookup、甚至手动getBean都可能更合适。代理是一种重量级机制不该被当成默认选项。第二个标准如果你必须加代理先检查类型声明。接口注入是JDK代理的前提具体类注入是CGLIB的前提两头都占是异常的高发区。不要认为Spring会智能地帮你搞定一切Spring帮你搞定的前提是配置和类型设计本身一致。第三个标准报错信息的第一句话不一定指向真正的根因。类型不匹配的报错背后可能是作用域配置错误、可能是代理模式选择错误、也可能是继承链设计问题你需要像剥洋葱一样层层往下查而不是看到一个异常就急着搜解决方案。这三个标准陪我排查了不止十次Spring Bean代理相关的故障几乎每次都能在几十分钟内定位到问题。如果你正被Spring Boot原型作用域Bean的代理创建异常困住按照本文的链路走一遍应该能少走不少弯路。