装饰者模式实战：用动态包装解决继承类爆炸与功能叠加难题

搞后端这几年，我发现一个特别有意思的现象：凡是在继承这条路上走得太顺的人，迟早会在某一个需求版本里翻车。比如你设计了一个通知类，起初只要发站内信；产品经理说还要支持发短信，于是你加了个子类；下周说还要支持发微信，又加了一个子类。等到某天要求“短信+微信”同时发的时候，你突然发现自己站在一个选择题面前：是给每种组合都建一个子类，还是干脆重构。

而装饰者模式，就是为这类“不断叠加功能、又不希望爆类”的场景准备的。这篇文章不打算搞学术演绎，我会先讲清楚它到底解决了什么难题，再带你把整个模式手写一遍，接着拆几个知名源码里真实的使用案例，最后把容易踩的坑和排查思路整理成清单。无论你是在准备面试，还是手头正好有个“功能叠加型”需求，都值得往下看。

1. “加功能”为什么这么难：装饰者模式要解决的根本问题

1.1 继承扩展功能的三个坑

先回到最直觉的写法：用继承给一个类加功能。

假设有一个Notifier负责发送通知，最初只有站内信功能。产品说要加短信，你新建一个SmsNotifier extends Notifier；说要加微信，再建一个WechatNotifier extends Notifier。目前看起来挺合理，每个子类只做一件事。

问题出在组合需求出现那天。用户可能想收到“短信+微信”，也可能想收到“邮件+短信+微信”。如果继续靠继承，你要创建的类数量是按指数级增长的：3种通知手段，会催生8种组合类；5种通知手段，就是32种组合类。你当然可以辩解“很多组合用不上”，但设计代码的时候，没人能保证哪个组合一定不会出现。

更麻烦的是，继承在语义上是静态的。某个类一旦被extends，它在编译期就绑定了固定的增强方式。想动态决定“今天只发微信，明天微信+短信”，用继承改起来非常痛苦，一不小心就把父子关系搅成一锅粥。这也是很多人吐槽“继承导致类爆炸”的根本原因：不是继承本身罪大恶极，而是用静态手段去解决动态叠加问题，注定会别扭。

1.2 组合优于继承：装饰者模式的核心思想

装饰者模式给出的解法很朴素：不要用子类去穷举组合，而是把一个对象装进另一个对象里，让每个包装层负责一部分增强功能。调用的时候，从外往里逐层传递，每一层都可以在转交之前或之后做自己的事情。

拿刚才的通知需求来说，核心组件是BaseNotifier，它只负责站内信。短信增强、微信增强、邮件增强各自做成独立的包装类。要发“短信+微信”时，就把微信包装在短信里面，再把短信包装在核心通知外面。整条链像套娃一样，最小原型永远是那个BaseNotifier，外面套几层完全由使用者说了算。

这本质上就是“组合优于继承”的实践。一个类不再通过继承固定拓展方向，而是通过持有另一份能力，在运行时动态灵活拼接。这样做的好处有两层：一是组合数量从指数级降回线性级，每加一种新通知方式，只需要新增一个装饰类；二是代码的职责边界更清晰，每个装饰类只关心自己的增强逻辑，不需要知道整条链上还有哪些兄弟。

1.3 一句话定义与适用场景

把话说明白：装饰者模式就是在不修改原有类代码的前提下，通过一层层包装对象，动态地给对象增加新职责。

适合用的场景我列一下：

• 功能需要按不同组合方式叠加，且组合种类无法在设计期穷尽；
• 希望保持接口统一，让调用方无感知地使用被增强后的对象；
• 某个核心对象很稳定，但增强逻辑变化频繁，不想污染核心类。

不适合的场景也有：

• 对象结构本身复杂，内部状态需要大量定制，包装层很难做到透明转发；
• 对极端性能有硬要求的场景，多层包装调用会带来额外栈深和转发开销；
• 增强逻辑高度依赖对象内部私有状态的时候，装饰者模式会显得很费劲，不如直接在类里扩展实现。

2. 手写一个装饰者模式：从组件到装饰者的完整落地

2.1 四个角色先认清楚

模式里的角色，比很多人记忆中的“抽象类+实现类”要多一层。先看这张对应关系表，后面代码全部按这个来写：

很多初学者会跳过抽象装饰者这一步，直接把增强类实现Component接口。不是不行，但每个增强类都要自己写“持有对象+构造器+转发方法”，代码重复严重。抽象装饰者存在的意义，就是把这套转发模板收敛到一处，具体装饰者只需要关心自己新增的那段逻辑。

2.2 用消息推送写一个最小可运行版本

直接看代码，这套实现是我在项目里用过的简化版，足够说明模式的核心骨架。

java复制// Component：抽象组件
public interface Notifier {
    void send(String message);
}

java复制// ConcreteComponent：核心组件，只做站内信
public class BaseNotifier implements Notifier {
    @Override
    public void send(String message) {
        System.out.println("[站内信] " + message);
    }
}

java复制// Decorator：抽象装饰者，持有Component引用并转发调用
public abstract class NotifierDecorator implements Notifier {
    protected final Notifier wrapper;

    public NotifierDecorator(Notifier wrapper) {
        this.wrapper = wrapper;
    }

    @Override
    public void send(String message) {
        wrapper.send(message);
    }
}

java复制// ConcreteDecorator：短信增强
public class SmsDecorator extends NotifierDecorator {
    public SmsDecorator(Notifier wrapper) {
        super(wrapper);
    }

    @Override
    public void send(String message) {
        System.out.println("[短信] " + message);
        super.send(message);
    }
}

java复制// ConcreteDecorator：微信增强
public class WechatDecorator extends NotifierDecorator {
    public WechatDecorator(Notifier wrapper) {
        super(wrapper);
    }

    @Override
    public void send(String message) {
        System.out.println("[微信] " + message);
        super.send(message);
    }
}

调用方组装装饰链：

java复制Notifier notifier = new WechatDecorator(
        new SmsDecorator(
                new BaseNotifier()
        )
);
notifier.send("您的订单已发货");

运行结果：

code复制[微信] 您的订单已发货
[短信] 您的订单已发货
[站内信] 您的订单已发货

注意输出顺序：微信在最外层，所以先执行自己的增强逻辑，再向内层转发；短信在内层，所以等外面微信执行完再执行；最后落到站内信。这个“从外到内”的执行顺序不是偶然，而是装饰者模式的基本行为，后面很多坑都跟它有关。

2.3 关键设计点解析

为什么装饰者要持有Component引用？因为装饰的本质就是“我包着你，你干完我再补刀”。如果装饰类不持有原始对象，那它就不是装饰，而是另起炉灶的独立实现。构造器传入被包装对象，这是装饰者模式最核心的组合方式。

为什么抽象装饰者用抽象类而不是接口？核心原因在于转发行为需要被复用。接口只能定方法签名，没法替你实现“调用内部wrapper对应方法”这段公共逻辑。如果直接让每个具体装饰者实现Notifier接口，意味着每个增强类里都要写一遍构造器、写一遍持有字段、写一遍转发逻辑。抽象类把这些公共样板收拢，具体装饰者只需要重写需要增强的方法就够了。

为什么send里要先输出自己的增强，再调用super.send()？其实顺序可以调整，完全取决于业务语义。如果某个装饰者想在核心行为之后追加处理，把输出放在super.send()后面就行。关键在于，这个顺序会直接影响执行结果，所以写装饰者之前，一定要先想清楚是前置增强还是后置增强。实践里我建议在每个装饰者的注释里标清楚“增强发生在转发前还是转发后”。

2.4 我的编码习惯

写装饰者模式的时候，我有几个朴素的习惯：构造器一律只接收被包装对象，不支持默认构造，从形式上保证必须套着东西；装饰链的组装尽量收敛到工厂方法或者专门配置类里，避免使用方散落着大量new；命名必须带Decorator后缀，像SmsDecorator、SecurityDecorator，这样半年后回看代码能秒懂。

还有一个容易忽略的点：装饰者类不要暴露出不属于Component接口的公开方法。一旦你为了临时方便给装饰者加了独有方法，调用方就需要把类型强转成具体装饰者，模式就退化成半透明状态，链式替换的优势就没了。后面会详细说这个问题。

3. 源码里的装饰者模式：别再以为它只能写在教科书里

3.1 InputStream 家族的经典用法

Java的IO流体系是装饰者模式最出名的案例，也是初学者最容易遇到却未必意识到的地方。很多人第一次写文件读取，接触到的就是这种写法：

java复制InputStream in = new BufferedInputStream(new FileInputStream("data.txt"));

这行代码背后干了两件事：FileInputStream负责从文件读字节，是核心具体组件；BufferedInputStream负责提供缓冲能力，是一个具体装饰者。再往上加一层还能继续包：

java复制InputStream in = new DataInputStream(
        new BufferedInputStream(
                new FileInputStream("data.bin")
        )
);

int value = in.read();

DataInputStream也是装饰者，它让底层的流拥有了读取基本数据类型的能力。三层包装下来，调用方看到的是同一个InputStream接口，根本不需要关心内部怎么组合。

角色映射非常清晰：InputStream是抽象组件，FileInputStream是具体组件，FilterInputStream是抽象装饰者，BufferedInputStream和DataInputStream都是具体装饰者。如果你去翻JDK源码，会发现FilterInputStream里有一个protected volatile InputStream in字段，所有read方法就是转发给这个in，和前面手写版本里的wrapper如出一辙。

3.2 为什么这个链这么设计

如果不用装饰者模式，Java的IO体系会变成什么样子？要么有一个巨型EverythingInputStream，塞满缓冲、数据转换、对象序列化、行读取等等功能；要么靠继承穷举组合，给每种能力组合创建单独的类，数量会爆炸到无法维护。

装饰者模式让每个包装类只负责一个独立能力：BufferedInputStream管内存缓冲，DataInputStream管基本类型解析，ObjectInputStream管对象反序列化，LineNumberInputStream管行号记录。想组合什么能力，就在构造链上叠加大象，灵活度很高。这个设计放到今天看依然很前卫，因为它用统一的接口把“不同粒度的IO能力”组合成了可拼装的积木。

3.3 使用顺序带来的性能差异

同一个装饰链，包装顺序反过来，效果可能天差地别。看这两行代码：

java复制// 推荐：先有缓冲，再解析数据
InputStream in = new DataInputStream(new BufferedInputStream(new FileInputStream("data.bin")));

// 不太推荐：先解析，再缓冲，缓冲失去意义
InputStream in = new BufferedInputStream(new DataInputStream(new FileInputStream("data.bin")));

第一种写法里，DataInputStream每次读一个基本类型，底层都落到BufferedInputStream的内存缓冲区，磁盘IO次数被大幅压缩。第二种写法里，DataInputStream没有缓冲能力，每次读都有可能在底层直接触达磁盘，性能会差很多。所以装饰者模式不只是“套几层而已”，每一层放在哪里、负责什么能力，会直接影响整体质量。

这也是我在评审同事代码时特别看重的点：装饰链的层次一定要和数据处理流程相匹配。底层负责接近数据源的原始能力，高层负责接近使用方的加工能力，顺序错位往往不是功能错误，而是性能问题。

3.4 其他源码里的装饰思想

JDK的java.util.Collections工具类里也有装饰者的影子：

java复制List<String> list = Collections.synchronizedList(new ArrayList<>());
List<String> unmodifiable = Collections.unmodifiableList(list);

synchronizedList包装了一个普通ArrayList，给所有方法加上同步控制；unmodifiableList包装了一份列表，把所有修改操作拦截掉。它们没有直接修改ArrayList的代码，而是用一个包装层，把新的职责动态加进去，这就是装饰者模式在标准库里的现实体现。类似的还有CheckedList、CheckedMap等。

再往大了看，Servlet规范里的Filter、Spring里的AOP通知，虽然底层实现是动态代理或拦截器，不是典型装饰者的类结构，但思想是相通的：在不改核心业务、不侵入内层代码的前提下，把日志、权限、事务这些横切能力一层层套在核心逻辑外面。理解装饰者模式，再去看拦截器链会轻松很多。

4. 装饰者模式 vs 代理模式：别再傻傻分不清

4.1 结构几乎一样，意图完全不同

如果用代码骨架对比，装饰者模式和代理模式看起来非常像：都有一个包装类持有真实对象，都在转发调用前后夹带私货。面试里也经常有人被问“这俩到底有什么区别”，脑子一热就开始背概念，越背越混。

本质区别在意图上：

• 代理模式的核心是控制访问。代理对象决定你是否能调用真实对象、什么时候调用、怎么调用。典型如权限代理、远程代理、延迟加载代理。
• 装饰者模式的核心是增强职责。装饰对象默认会把调用完整转交给被包装对象，只是在这个基础上附加新行为。

一个是在“门卫”，一个是在“厨师的副手”。门卫关心你有没有资格进去，副手关心这道菜上桌前要不要再加一道工序。

4.2 从代码结构上怎么快速分辨

光看结构不好分，但抓住三个点就能快速判断：

第一，谁创建了包装对象。装饰者模式通常由使用方显式地将被装饰对象传入装饰者构造器，比如new SmsDecorator(new BaseNotifier())，链是使用方自己拼的。代理模式往往是代理工厂或容器生成的，真实对象在代理内部被创建或注入，使用方拿到的只是代理引用。

第二，包装类是否直接暴露了“被包裹对象”。装饰者的构造器一定会接收Component类型参数，并且需要保存这个引用。代理模式里，真实对象不一定由外界传入，代理可以完全控制真实对象的生命周期。

第三，调用方能否跳过包装层。装饰者模式下，你可以选择不用任何装饰器，直接用核心组件。代理模式下，调用方一开始拿到的就是代理，没有“不用代理直接用真实对象”的选项。

4.3 常见混淆点：动态代理和装饰者的边界

很多人看到Spring AOP、MyBatis的Mapper都会困惑：这到底是代理模式还是装饰者模式？

我的理解是：它的实现机制是动态代理，也就是在运行时生成代理类，而不是靠继承Component接口逐方法包装。但它承担的功能是横切增强，比如日志、事务、缓存，这更像装饰者模式的目标。换句话说，这是“用代理的手段，实现装饰者的意图”。

技术上它们是交叉的：如果你用JDK动态代理包装了一个对象，在invoke方法里往里层转发调用，并加上增强逻辑，这种代码结构更接近装饰者；如果你在代理里直接拦截所有方法、返回缓存结果，不往真实对象转发，那更接近纯代理。区分主要看一个关键动作：是否有转发给真实对象的核心调用链。有转发就是装饰色调，没转发就是代理色调。

4.4 判断时的“底线思维”

我建议把代理和装饰者的边界当成一道选择题，别当成判断题。具体到业务里，问三个问题就行：

• 这个包装层是为了挡住某些访问，还是为了增加某些能力？
• 被包装对象如果不存在，这个包装层还有存在的意义吗？
• 使用方想把包装层拆掉，直接用原始对象，是否被允许？

第一个问题答案是“挡住”，那是代理；答案是“增加能力”，那是装饰者。第二、第三个问题的答案能帮你确认到底是哪种实现方式，而不是停留在教条里。

5. 实战重构：用装饰者模式写一个订单计价器

5.1 一个容易失控的计价需求

把模式塞进真实项目里，才算是真会了。拿电商订单价格计算举例，这是很多业务系统都会遇到的需求。

订单原价只是一个起点，实际结算价格要经过好几道关卡：满减、会员折扣、优惠券、运费叠加。代码很容易写成一个大方法：

java复制public BigDecimal calc(Order order, User user) {
    BigDecimal price = order.getTotalPrice();
    if (order.getTotalPrice().compareTo(new BigDecimal("300")) > 0) {
        price = price.subtract(new BigDecimal("50"));
    }
    if (user.isVip()) {
        price = price.multiply(new BigDecimal("0.9"));
    }
    // 优惠券判断、运费判断……
    return price;
}

第一阶段没事，第二阶段开始到处打补丁，第三阶段连顺序都开始迷离：满减是在折扣前还是折扣后？优惠券能不能抵扣运费？这种“打补丁式”代码直接导致每次改动都像走雷区。装饰者模式正好适合这类流水线式叠加逻辑。

5.2 先定义核心接口和基础组件

把计价抽象为一个接口：

java复制public interface PriceCalculator {
    BigDecimal calculate(BigDecimal originalPrice);
}

核心组件只做一件事：把原价原样返回，相当于计算链的起点。

java复制public class BasePriceCalculator implements PriceCalculator {
    @Override
    public BigDecimal calculate(BigDecimal originalPrice) {
        return originalPrice;
    }
}

抽象装饰者负责统一持有被包装计算器并转发：

java复制public abstract class PriceDecorator implements PriceCalculator {
    protected final PriceCalculator calculator;

    public PriceDecorator(PriceCalculator calculator) {
        this.calculator = calculator;
    }

    @Override
    public BigDecimal calculate(BigDecimal originalPrice) {
        return calculator.calculate(originalPrice);
    }
}

5.3 每一层策略都用独立装饰器

会员折扣装饰器：

java复制public class MemberDiscountDecorator extends PriceDecorator {
    private final BigDecimal discountRate;

    public MemberDiscountDecorator(PriceDecorator calculator) {
        super(calculator);
        this.discountRate = new BigDecimal("0.9");
    }

    @Override
    public BigDecimal calculate(BigDecimal originalPrice) {
        BigDecimal price = super.calculate(originalPrice);
        return price.multiply(discountRate);
    }
}

满减装饰器：

java复制public class FullReductionDecorator extends PriceDecorator {
    @Override
    public BigDecimal calculate(BigDecimal originalPrice) {
        BigDecimal price = super.calculate(originalPrice);
        if (price.compareTo(new BigDecimal("300")) >= 0) {
            return price.subtract(new BigDecimal("50"));
        }
        return price;
    }
}

运费装饰器：

java复制public class ShippingDecorator extends PriceDecorator {
    @Override
    public BigDecimal calculate(BigDecimal originalPrice) {
        BigDecimal price = super.calculate(originalPrice);
        return price.add(new BigDecimal("10"));
    }
}

组装的时候，链的顺序就是业务规则：

java复制PriceCalculator calculator = new ShippingDecorator(
        new MemberDiscountDecorator(
                new FullReductionDecorator(
                        new BasePriceCalculator()
                )
        )
);

BigDecimal finalPrice = calculator.calculate(new BigDecimal("400"));

这段代码表达的业务逻辑是：先判断是否满300减50，再打九折，最后加运费10元。400元原价经过满减变350，打九折变成315，加运费变成325。如果顺序反过来，结果完全不一样，所以业务规则必须由装饰链的组织者牢牢控制。

5.4 实战里的顺序陷阱

订单计价场景里，顺序几乎就是业务本身。同样一个“会员折扣”装饰器，放在“满减装饰器”之前还是之后，直接决定用户省多少钱。产品经理嘴上说“先满减再打折”很容易，落地到代码就必须把链的顺序固定下来。

我的建议是把装饰链的组装收敛到一个工厂类或配置类里，按业务规则显式排列，并加上注释说明“为什么先满减再会员折扣”。不要指望使用者自己能拼对顺序，工具方法最能避免人为错误。

还有一点：这些装饰器不需要被大量复用的时候，完全可以配合lambda或函数式接口来做，不必为每个规则单独建类。比如Java的Function<BigDecimal, BigDecimal>也能做类似的链式处理：

java复制Function<BigDecimal, BigDecimal> calc = base -> base;
calc = calc.andThen(PriceRules::fullReduction)
           .andThen(PriceRules::memberDiscount)
           .andThen(PriceRules::shipping);

这种方式更轻量，但可读性和类型约束不如标准装饰者模式强。我的原则是：规则数量少且逻辑简单的用函数式，规则复杂且有独立状态时用标准装饰者类。

5.5 装饰者模式在其他语言里的延伸

Python里那个常见的@decorator语法，虽然也叫装饰器，但本质上是函数的包装器，是在函数级别做增强，和面向对象里的装饰者模式并不完全一样。不过思想同源：不动原函数，通过包装一层逻辑来扩展行为。

TypeScript里也有装饰器，类装饰器、方法装饰器用来做元编程层面的扩展，语义更接近注解工具。相比之下，Java生态里真正和装饰者模式一脉相承的，是Filter、Stream、包装器模式这些概念。理解模式本身，再去看各家语言的花样，就不会被同名概念绕晕了。

6. 常见问题与排查技巧实录

6.1 装饰后“类型消失”：调用独有方法报错

这是新手最容易踩的坑。假设BaseNotifier里有一个sendWithAttach特有的方法，把它包进SmsDecorator后，使用方拿到的类型是Notifier或者SmsDecorator，直接调用sendWithAttach是编译不过去的。

原因在于装饰者模式对外暴露的边界是Component接口，所有包装层都只能通过统一接口访问。这本身是特性不是 bug，它保证了链式替换的一致性，但也限制了调用方使用具体组件的专有能力。解决办法是：要么把这类“专有能力”也提升到Component接口里，要么放弃透明性，使用方强转成具体类型去调用。后者会让模式退化成半透明装饰，我一般只在迫不得已时才用。

6.2 装饰顺序导致功能失效

很多人在写Filter链、拦截器链或者IO流时，都遇见过“功能莫名其妙失效”的情况。大部分不是代码逻辑错了，而是装饰顺序颠倒。

举一个真实例子：有人给加密流外层套了BufferedInputStream，读起来性能很差，因为加密流读完才能缓冲，缓冲层收效甚微。又比如在HTTP过滤器链里，把字符编码设置放在链条尾部，结果前面的过滤器已经读取了请求体的内容，编码改动就失去了作用。

排查这类问题的思路很简单：从最内层的核心组件开始，逐层向外梳理每一步的数据处理流程，重点确认每一层的输出是否符合下一层的输入预期。画一张调用链图（不用多正规，草稿也行），把数据从内到外的路径标出来，问题通常会浮出水面。

6.3 equals和hashCode“失效”

默认情况下，包装后的对象不重写equals，比较时用的是对象引用地址。两个内容一样的对象，只是装饰层不同，就会被判定为不相等。这在集合去重、缓存key等场景里特别容易出问题。

要注意的是，装饰者模式的重心是行为增强，并不是值对象。绝大多数场景下，被装饰对象不应该直接作为Map的key或Set的元素。如果业务确实有这种需求，必须重写equals和hashCode，并且要决定比较范围：是只比较最内层核心对象，还是也要比较装饰层。我见到不少线上事故，就是因为包装后的对象被放进缓存，而缓存读取时比较逻辑没跟上，结果每次点击都重新计算。

6.4 序列化和性能问题

装饰链越长，对象图就越深。序列化的时候，如果装饰器和被装饰对象都实现了Serializable，整条链都会被序列化，数据体积和序列化耗时都会上涨。更麻烦的是，有些包装类内部持有临时状态（比如缓冲的字节数组），序列化这些东西本身就不合理。

性能上，多层装饰必然带来额外的栈深和方法调用。一个个别业务用一两次没什么感觉，但如果装饰链出现在高频路径上，比如每次用户请求都要穿过七八层装饰器，就要考虑压测之后再上线。我们当时在网关层套了日志、限流、鉴权、灰度等多个装饰器，结果上线前压测发现QPS不达标，排查下来就是装饰链太长导致的栈深和对象分配问题。解决方式是合并部分装饰层，把日志和灰度判断融合，减少一层包装，QPS立刻回升。

6.5 类数量依旧可观怎么办

有人会吐槽：装饰者模式把“组合爆炸”变成了“线性增长”，但功能维度一多，装饰器类数量其实也不少。这是事实，模式不能凭空消灭类的数量，只能把类数量控制在可维护范围内。

面对这种情况，我有两个处理方向。一是用工厂模式组织装饰器的创建，把组合规则收敛到一个地方，避免使用方各自拼链导致混乱；二是对简单场景拥抱函数式思维，用Function、UnaryOperator这类工具替代标准装饰者类，减少样板代码。但无论怎么精简，我都不建议为了少写几个类，把增强逻辑硬塞回核心类里——那会让代码重新滑向不可维护的深渊。

6.6 快速自检表

这六类问题，几乎覆盖了我这些年做代码评审和处理线上问题时的重点。它们不是装饰者模式特有的缺陷，而是所有“包装型”结构都可能遇见的通病。提前意识到这些风险，比等出了问题再补课要省力太多。

最后再分享一点个人体会。我做代码评审时，看到有人用继承去搞叠加功能，会先问一句“这里能不能换成装饰者”。但我也越来越清楚地认识到，装饰者模式不是什么万能药，它最适合的场景是“功能维度在增加，但核心组件稳定”。如果核心组件本身天天变，先把核心稳定下来，再谈包装。

还有一个很土但很有效的经验：装饰者的命名一定要带Decorator后缀。这看起来只是命名习惯，实际影响很大。曾经有个项目，同事把装饰器类命名为xxxHelper，结果后续维护的人根本分不清哪些是包装层、哪些是工具类，导致新功能重复实现。名字带Decorator，至少别人看到类名就知道它该套在哪个对象外面，能少踩一半的坑。