Builder设计模式：未设置的Integer变量为何被自动设为0？技术问询

数据老陈

2026-5-20

这确实是Builder模式里处理基本类型和包装类型时很容易踩的一个坑，我来帮你理清楚问题根源和对应的解决办法：

先还原一下你的场景（推测的代码结构）

我猜你的代码大概是这样的：

// 目标类：Phone，用基本类型定义属性
class Phone {
    private String os;
    private int ram;
    private int processor; // 基本类型int，不能为null

    public Phone(String os, int ram, int processor) {
        this.os = os;
        this.ram = ram;
        this.processor = processor;
    }

    // getter方法...
}

// Builder类：用包装类型接收可选参数
class PhoneBuilder {
    private String os;
    private Integer ram;
    private Integer processor; // 包装类型Integer，未设置时为null

    public PhoneBuilder setOs(String os) {
        this.os = os;
        return this;
    }

    public PhoneBuilder setRam(int ram) {
        this.ram = ram;
        return this;
    }

    public PhoneBuilder setProcessor(int processor) {
        this.processor = processor;
        return this;
    }

    public Phone getPhone() {
        // 这里的处理把null转成了0，导致最终Phone的processor是0
        return new Phone(
            os,
            ram != null ? ram : 0,
            processor != null ? processor : 0
        );
    }
}

当你执行Phone p = new PhoneBuilder().setOs("Android").setRam(2).getPhone();时，因为没调用setProcessor()，Builder里的processor是null，而getPhone()里的三元表达式把它转成了0，最终Phone的processor变成0；但如果你直接实例化Phone，比如new Phone("Android", 2, null)会直接编译报错——这就是你困惑的核心：两种实例化方式的行为不一致。

问题根源

基本类型（int、long等）本身不能为null，必须持有一个有效值（比如int的默认值是0）；而包装类型（Integer、Long）可以为null，用来表示「未设置」的状态。
你的Builder用包装类型来接收可选参数，本来是为了区分「用户没设置」和「用户主动设置了0」，但getPhone()里的处理逻辑把「未设置」的null直接转成了0，不仅丢失了状态区分度，还和直接实例化的行为产生了矛盾。

解决办法（根据你的业务需求选）

1. 允许属性为「未指定」：把Phone的属性改成包装类型

如果你的业务场景允许processor为null（表示这个参数未被指定），那直接把Phone里的基本类型换成包装类型：

class Phone {
    private String os;
    private Integer ram;
    private Integer processor; // 包装类型，允许为null

    public Phone(String os, Integer ram, Integer processor) {
        this.os = os;
        this.ram = ram;
        this.processor = processor;
    }

    // getter方法...
}

// 对应的Builder的getPhone()无需再转默认值
public Phone getPhone() {
    return new Phone(os, ram, processor);
}

这样：

直接实例化时可以传null给processor参数（因为是包装类型）
使用Builder时，未设置processor的话，最终Phone的processor就是null，完全符合你的预期

2. 强制必填：在Builder中校验非空

如果processor是Phone的必填参数，那应该在getPhone()里添加校验，而不是偷偷给默认值：

public Phone getPhone() {
    if (processor == null) {
        throw new IllegalStateException("Processor is a required parameter, please set it first!");
    }
    // ram如果也是必填项，同样要加校验
    return new Phone(os, ram, processor);
}

这样就和直接实例化的行为一致了——缺少必填参数时直接报错，而不是生成一个不符合预期的实例。

3. 合理设置默认值：在Builder初始化时就赋值

如果processor的默认值确实是0（业务上允许未设置时用0），那可以在Builder里直接用基本类型定义，初始化时就赋值默认值：

class PhoneBuilder {
    private String os;
    private Integer ram;
    private int processor = 0; // 直接用基本类型，默认值0

    public PhoneBuilder setProcessor(int processor) {
        this.processor = processor;
        return this;
    }

    public Phone getPhone() {
        return new Phone(os, ram, processor);
    }
}

这样既避免了包装类型拆箱的问题，也明确了默认值的逻辑，用户未设置时就会用0，行为清晰可预期。

内容的提问来源于stack exchange，提问作者Mous Kamel