Java魔法值详解：从枚举、常量到策略模式，彻底消除硬编码

接手过不少老项目的代码，最让我头疼的往往不是复杂的算法，也不是高深的设计模式，而是满屏写死的裸数字和裸字符串。比如看到if (order.getStatus() == 1)这种代码，我第一反应不是去猜业务逻辑，而是先骂一句：“这 1 到底是啥意思？”是的，这就是程序里臭名昭著的“魔法值”。对 Java 开发者来说，魔法值几乎陪伴了整个编码生涯，从初级写手到资深架构师，谁都绕不开它。这篇博文就专门聊聊魔法值的定义、危害、消除方案，以及围绕它衍生出的面试考点和代码审查规范，希望对正在学 Java 或者准备面试的小伙伴有所帮助。

1. 魔法值到底是个什么东西

1.1 一段迟早会让你崩溃的代码

魔法值这个词听起来挺玄乎，好像是什么黑魔法，实际上它的含义非常朴素：在代码里直接出现的、没有任何注释和定义的常量，比如裸的数字、裸的字符串、裸的布尔值。

我举个例子，你在项目里大概率见过类似代码：

if (order.getStatus() == 1) { // 执行发货逻辑 } else if (order.getStatus() == 2) { // 执行退款逻辑 }

这段代码在写出来的那一刻，作者自己心里清楚：1 代表已支付，2 代表已退款。但这种“清楚”是有保质期的，可能过了半个月，你再回头看这段代码，心里就开始犯嘀咕了，这个 1 是已支付还是已下单？2 是退款中还是退款完成？如果这时候来个新同事接手项目，他面对这一堆数字，只能一个一个去问，或者去翻历史文档碰运气。

那为什么它被叫做“魔法值”呢？因为这个值就像魔法师手里的咒语一样，只有施法者本人（写下这段代码的人）才懂它的含义，其他人看起来就像在看天书。它像是代码里的一个暗号体系，除了你自己之外，团队里每个人都要靠猜才能知道它在干什么。这个说法最早源自编程社区，大家对“magic number”的戏称，后来被广泛用于描述所有硬编码的常量。

除了数字，字符串魔法值也很常见。我在很多项目里见过类似if ("SUCCESS".equals(resultCode))这种写法，还有if (userType.equals("ADMIN"))，这些字符串有一天被改成小写、改成别的单词时，你只能全局搜索碰运气，看哪些地方需要同步改，这种体验真的让人头皮发麻。

1.2 魔法值的“危害半径”到底有多大

很多人觉得魔法值不就是写了个数字吗？有什么大不了的。但如果你经历过一次因为魔法值导致的生产事故，你可能就不会这么想了。

第一个危害是可读性差。代码是给机器执行的，但更是给人看的。当你写下if (status == 3)时，阅读代码的人根本不知道 3 代表什么，他需要在脑子里做一次“数字到业务含义”的翻译，如果翻译不出来，他就只能猜测。这种不明确性会极大拉低团队协作效率。

第二个危害是维护成本高。假设系统里有十处代码都用了数字 1 来表示“已支付”，现在业务方突然说要调整状态机，把 1 改成 6。你必须把这十处代码全部找出来改一遍，万一漏改一处，线上就会出现“状态判断错乱”这种bug。而且有些数字还可以被多个含义复用，你改了这里，可能影响了完全不相干的功能。

第三个危害是容易导致低级错误。比如两个不同的业务含义都用了数字 1，一个表示性别男，一个表示订单已取消。你本来想判断“订单已取消”，结果不小心写错了字段，判断到了性别上，程序不仅不会报错，还会在某种巧合条件下给出正确结果，这种隐藏逻辑错误是最难排查的。

第四个危害是类型不安全。拿数字来举例，一个方法参数是 int 类型，你传入 1 和 2 代表不同的模式，编译器完全不会帮你检查是否合法。你写了个process(5)，编译器不报错，程序也能跑，但它实现的根本不是你要的逻辑。而如果使用枚举，传入一个不存在的枚举值，编译器直接就报错了，能拦截一大批低级错误。

总的来说，魔法值是你看得见但永远摸不透的东西。它像代码里的脏水，短期看没什么问题，时间一长就会发臭，最后臭的人不是别人，就是当初写下它的你自己。

2. 为什么我们总在不知不觉中写出魔法值

2.1 “偷懒”是最大的原罪

写代码的人为什么明知道魔法值不好，还是会写？我总结了一下，根本原因其实就是“偷懒”。大多数情况下，我们脑子里冒出的第一个方案就是最直接的方案。

比如要判断一个用户是不是VIP，你脑子里的第一反应大概率是if (user.getLevel() == 3)，而不是先去定义一个常量或枚举。因为前者只需要敲几行键盘，后者则需要单独建一个类或枚举文件。对于一个小功能来说，建一个枚举确实显得有点“杀鸡用牛刀”，于是魔法值就这么自然地产出了。

还有种情况是“临时写死，后面再说”。比如对接第三方接口时，你暂时不确定返回码的含义，程序里先用if (code == 200)顶着，打算等文档齐全了再改。结果呢？文档到了之后你已经忘了这茬，或者接手的人压根不知道这是临时方案，于是这个魔法值就永远留在了代码里，成了遗产。

要破除这种“偷懒思维”，关键还是得有个意识：写代码不只是写给机器看的，更是写给下一个维护者看的。而下一个维护者，很可能就是几个月后的你自己。你省下来的那几分钟定义一个常量的时间，后面可能会花几个小时去找bug，得不偿失。

2.2 团队缺少统一的规范约束

我观察过很多项目，魔法值泛滥的团队，通常没有一个明确的编码规范。代码审查的时候只看逻辑对不对、能不能跑，没人去管这个数字是不是应该被提取成常量。新人进来后看到满屏魔法值，还以为这是项目组的“特色写法”，于是继续在生产代码里疯狂堆数字。

这种氛围一旦形成，就像烂苹果效应，整个代码库的质量会慢慢滑向失控边缘。所以后来我在带团队时，明确立了一条规矩：代码审查时只要看到裸数字、裸字符串，必须提出修改意见，除非是 0、1 这种放在 if 里判断真假、或者数组索引等没法再语义化的场景。

另外还有一个容易被忽略的场景，团队之间、服务之间相互调接口的时候，如果一个接口返回的是数字状态码，但没有配套的状态码枚举文档，那调用方就必然面临“面对魔法值却不知何意”的局面。这种接口层面的魔法值，危害比代码内部的更大，因为它跨了服务边界，排查问题时要跨多个项目全局搜索才能定位。

2.3 需求频繁变更带来的“连锁爆炸”

业务需求一旦频繁变动，魔法值的危害就会成倍放大。我印象最深的一次经历是这样的：支付系统里原本用数字 1、2、3 表示支付渠道，分别是支付宝、微信、银行卡。后来接入了一个新的渠道，产品经理说用 4 表示吧，然后我还得确保在十几处判断逻辑里都加上 4 的分支。

这还算好的，更惨的是后来做数据统计，发现历史库里有不少莫名的 5、6 值，查了半天才发现是前任开发在代码里临时写死的。这种状态码一旦和不同的系统进行同步，出问题的概率就会指数级上升。业务需求一变，你就得把每个魔法值的含义梳理清楚，而这个梳理过程的成本，往往比重新开发还高。

如果你在初期就把这些状态定义在枚举里，需求变更时只需要改枚举定义或者加一个枚举项，编译器会帮你找到所有用错的地方，改起来就会有理有据，不会漏。

3. 动手干掉魔法值：四套主流方案

3.1 最基础的做法：用常量类归拢所有裸值

最直接的消除魔法值方案，就是新建一个常量类，把分散在代码各处的裸值收拢到一起。这是门槛最低的一种做法，几乎零学习成本。

比如之前的订单状态：

public class OrderStatusConstant { private OrderStatusConstant() { } public static final Integer CREATED = 0; public static final Integer PAID = 1; public static final Integer SHIPPED = 2; public static final Integer COMPLETED = 3; public static final Integer CLOSED = 4; }

改造之后，代码就变成了：

if (OrderStatusConstant.PAID.equals(order.getStatus())) { // 执行发货逻辑 }

好处是显而易见的：可读性大幅提升，团队里每个人看到PAID都知道这是“已支付”的意思，就算不看注释也能猜出七八分。

常量的命名我个人建议用大写字母加下划线，这是一个约定俗成的习惯，可以一眼和普通变量区分开。另外，这种常量类最好设计成不可实例化的类，把构造方法私有化，防止别人 new 一个出来当对象用。

不过常量类也有局限性，它只是给数字起了个名字，并没有真正约束业务逻辑。你依然可能把一个原本不属于这个状态集合的数字传进来。所以说，常量类是及格线，但它远不是最好的解。

3.2 更 Java 的做法：用枚举代替可以枚举的取值范围

如果说常量类是给魔法值贴了个标签，那枚举就是给魔法值修了一堵围墙。对于状态值、类型值这种“取值范围有限”的业务字段，Java 枚举几乎是完美的方案。

使用枚举改造上面的订单状态：

public enum OrderStatusEnum { CREATED(0, "已创建", "订单已生成，等待支付"), PAID(1, "已支付", "支付成功，等待发货"), SHIPPED(2, "已发货", "商品已发出，等待收货"), COMPLETED(3, "已完成", "订单已完成"), CLOSED(4, "已关闭", "订单已关闭"); private final Integer code; private final String desc; private final String detail; OrderStatusEnum(Integer code, String desc, String detail) { this.code = code; this.desc = desc; this.detail = detail; } public Integer getCode() { return code; } public String getDesc() { return desc; } public String getDetail() { return detail; } public static OrderStatusEnum of(Integer code) { for (OrderStatusEnum status : values()) { if (status.code.equals(code)) { return status; } } throw new IllegalArgumentException("未知的订单状态: " + code); } }

使用枚举之后，判断代码可以这样写：

OrderStatusEnum status = OrderStatusEnum.of(order.getStatus()); if (OrderStatusEnum.PAID == status) { // 执行发货逻辑 }

相比常量类，枚举有三大优势：

第一，所有状态值被“圈”在了一个集合里，取值范围完全受控。某个方法如果要求传一个OrderStatusEnum类型的参数，那你就没法乱传数字了，编译阶段就能拦截错误。

第二，枚举自带描述信息。以前看到 1 你要猜含义，现在你直接可以输出OrderStatusEnum.PAID.getDesc()，前端的下拉、后端的日志、对接文档都能共用一套定义。

第三，可以写业务逻辑。枚举不是简单的常量列表，它本身是一个类，可以在枚举里定义抽象方法、普通方法，甚至可以配合策略模式实现复杂的逻辑分发。这一点后面我还会展开讲。

当然，枚举也不是万能的。如果业务状态是动态变化的，比如在管理后台可以随时新增状态、删除状态，那枚举就不适合了，这种情况更适合数据库字典表和配置中心。

3.3 更灵活的做法：用配置中心或配置文件管理会变化的值

有些值虽然也是魔法值，但它不够“硬”，因为它随着业务变化比较频繁。比如第三方接口的超时时间、灰度放量的开关比例、某些业务开关的开启关闭，这类值如果硬编码在枚举或常量类里，每次改动都得重新发布版本，非常麻烦。

这种情况下，正确的姿势是放到配置文件或配置中心里。以 Spring Boot 项目为例，可以这样定义配置项：

order: timeout: 30 max-retry-times: 3 auto-close-minutes: 15

然后利用@ConfigurationProperties绑定到一个配置类上：

@Component @ConfigurationProperties(prefix = "order") @Data public class OrderProperties { private Integer timeout; private Integer maxRetryTimes; private Integer autoCloseMinutes; }

调用时直接注入OrderProperties使用即可：

if (order.getCreateTime().plusMinutes(orderProperties.getAutoCloseMinutes()).isBefore(LocalDateTime.now())) { // 超时未支付，自动关闭订单 }

如果用了配置中心（Apollo、Nacos），甚至可以在不重启应用的情况下动态刷新数值。这类配置选项本身就是“会变的值”，你把它从代码中剥离出去，让运营或开发在后台就能调整，比什么都强。

我个人的建议是：如果你的值将来有“运营后台可调整”的需求，优先考虑配置中心；如果纯粹是代码内部的业务状态定义，用枚举就够了。不要为了上配置中心而把本来很稳定的状态码也塞进去，那样反而把简单问题复杂化。

3.4 三种方案到底应该怎么选

很多人看完上面的内容可能会纠结，我到底该用常量类、枚举还是配置中心？这里我根据自己的实践经验，整理了一张对比表，你在做技术选型的时候可以参考一下：

我的经验法则是：如果一个值的取值范围是有限的、静态的、业务含义明确的，优先用枚举；如果只是某个方法内部用一次的临时标记，且没有复用价值，也可以考虑用常量类；如果这个值会频繁变化、需要外部调整，那就上配置中心或配置文件。

这里再说一个个人的小习惯：哪怕只是一个临时变量，我也不会直接用裸数字。我会先写一个常量或者局部变量，给这个数起个有意义的名字，哪怕它只在当前方法里用一次。一开始可能觉得麻烦，但坚持一段时间后你就发现，代码可读性有了质的提升。

4. 进阶玩法：用设计模式把“魔法值”赶出业务代码

4.1 基于魔法值写 if-else 到底有多坑

上面的方案能从一定程度上消除魔法值本身的“不可读”问题，但在一些复杂的业务场景中，光把数字换成枚举还不够，真正的难点在于：你依然在用if-else或者switch-case根据魔法值去分发业务逻辑。

举个例子，假设一个支付系统支持支付宝、微信、银行卡、云闪付四种渠道，每个渠道的支付逻辑完全不一样。初始版本里的代码可能是这样的：

public void pay(Integer channel, BigDecimal amount) { if (channel == 1) { alipayService.pay(amount); } else if (channel == 2) { wechatPayService.pay(amount); } else if (channel == 3) { bankCardService.pay(amount); } else if (channel == 4) { unionPayService.pay(amount); } else { throw new IllegalArgumentException("未知支付渠道"); } }

这段代码最大的问题不是魔法值 1、2、3、4，而是每增加一个新渠道，你都必须改动这个pay方法，在原有的if-else链条里再插入一个分支。随着分支越来越多，方法的圈复杂度蹭蹭往上涨，代码越来越难维护。

而且这种代码非常容易出错误，你在第 20 个else if后面很容易复制粘贴漏改判断条件。特别是当渠道数量增长到几十个的时候，每次上线我都提心吊胆，生怕影响到了别的渠道。

4.2 用“策略模式 + 枚举”打一套组合拳

要治好这种“魔法值分支病”，业界最常用的方案是策略模式加枚举的组合拳。

策略模式的核心思想是把每个分支的逻辑封装成独立的类，然后由上下文根据条件去选择一个策略。在 Java 里，我们可以借用枚举本身能承载抽象方法的特性，实现一种轻量级的策略分发。

先定义支付渠道枚举：

public enum PayChannelEnum { ALIPAY(1) { @Override public void pay(BigDecimal amount) { alipayService().pay(amount); } }, WECHAT(2) { @Override public void pay(BigDecimal amount) { wechatPayService().pay(amount); } }, BANK_CARD(3) { @Override public void pay(BigDecimal amount) { bankCardService().pay(amount); } }, UNION_PAY(4) { @Override public void pay(BigDecimal amount) { unionPayService().pay(amount); } }; private final Integer channelCode; PayChannelEnum(Integer channelCode) { this.channelCode = channelCode; } public static PayChannelEnum of(Integer channelCode) { for (PayChannelEnum channel : values()) { if (channel.channelCode.equals(channelCode)) { return channel; } } throw new IllegalArgumentException("未知支付渠道: " + channelCode); } public abstract void pay(BigDecimal amount); }

有了这个枚举之后，原来的pay方法就变得非常干净：

public void pay(Integer channel, BigDecimal amount) { PayChannelEnum channelEnum = PayChannelEnum.of(channel); channelEnum.pay(amount); }

你仔细感受一下这个变化：原来要写一大堆if-else，现在只有三行代码。新增一个支付渠道，只需要新增一个枚举项并实现pay方法，不用再去改动pay方法内部的逻辑。这就是开闭原则的体现：对扩展开放，对修改关闭。

这种写法的另一个好处是，魔法值被完全封装在枚举内部，业务代码层面根本看不到裸数字了。即使以后渠道编码从 1 改成 101，你只需要动枚举里的channelCode字段和of方法，所有调用方的代码都不需要改。

4.3 用 Spring 按类型注入策略，彻底解耦

上面的枚举策略方案虽然已经很好了，但如果策略逻辑很重，不适合塞在枚举里，那你还可以更进一步，用 Spring 的依赖注入特性来实现策略分发。

定义一个统一策略接口：

public interface PayStrategy { Integer getChannelCode(); void pay(BigDecimal amount); }

每个策略一个类，标记为 Spring Bean：

@Component public class AlipayStrategy implements PayStrategy { @Override public Integer getChannelCode() { return 1; } @Override public void pay(BigDecimal amount) { // 调用支付宝 SDK 的支付逻辑 } }

然后在一个容器里注入所有策略，做一个工厂类：

@Component public class PayStrategyFactory { private final Map<Integer, PayStrategy> strategyMap; public PayStrategyFactory(List<PayStrategy> strategyList) { strategyMap = strategyList.stream() .collect(Collectors.toMap(PayStrategy::getChannelCode, Function.identity())); } public PayStrategy getStrategy(Integer channelCode) { PayStrategy strategy = strategyMap.get(channelCode); if (strategy == null) { throw new IllegalArgumentException("未知支付渠道: " + channelCode); } return strategy; } }

然后业务方法就变成了：

public void pay(Integer channel, BigDecimal amount) { strategyFactory.getStrategy(channel).pay(amount); }

这种写法把每个渠道的支付逻辑彻底隔离到了独立的类中，新增渠道只需要新增一个类实现接口并标记@Component即可，原方法一行都不用改。唯一的缺点是类和 Bean 数量会增多，如果策略本身非常简单，用这种方案反而有点过度设计。

我个人习惯是：逻辑简单、分支少用枚举策略；逻辑复杂、每个策略都是一大坨代码时，就用 Spring 容器管理的策略模式。这两种方案都能有效消灭“魔法值 + if-else”的坏味道，具体选哪种要看团队规模和你代码复杂度的现实情况。

5. 面试考点：魔法值相关的“八股文”该怎么答

5.1 面试官问魔法值的时候，到底在考什么

最近几年 Java 面试越来越卷，除了问算法、源码、分布式，基础编码习惯问题也开始频繁出现，“魔法值”就是其中一个典型考点。很多面试官会问：“你在项目中是怎么处理魔法值的？说说你的理解。”

你以为他在问你知不知道魔法值是什么？其实他问的是你对代码质量的理解程度，以及你在实际项目中是否真的有意识地维护代码可维护性。这个问题没有标准答案，但考官想看到的是一种“我不会在生产代码里乱写裸值”的职业素养。

我建议回答时按“是什么、为什么、怎么办”三步走：简单描述魔法值的定义，说明魔法值对可读性、维护性、扩展性的危害，然后重点讲你在项目里是怎么治理的，比如用枚举定义状态值、用常量类沉淀固定参数、用配置中心管理动态阈值。如果最后还能举一个自己踩过的坑，比如因为魔法值导致的线上 bug，那这个回答基本就稳了。

5.2 常见的追问与参考回答

围绕魔法值这个点，面试官还会抛出一些变形提问，提前准备一下很加分。

追问一：常量类和枚举有什么区别，为什么更推荐枚举？

可以从类型安全、扩展性、语义表达三个方面展开。常量只是给数字起了个名字，实际类型还是 int 或者 String，无法在编译期限制取值；枚举本身是类型，取值范围是固定的，编译器能帮你检查。枚举还可以携带描述文本和行为方法，表达力更强。

追问二：如果业务状态是动态变化的，枚举就不适用了，你会怎么做？

这时可以说用数据库字典表加配置中心来管理，把状态值作为一种数据而非代码。这个回答显示了你对不同方案的边界有清醒认知。

追问三：字符串类型的魔法值怎么治理？

字符串魔法值通常出现在状态码、错误码、用户类型等场景。方案和数字类似，可以用常量、枚举类、或者定义专门的 ErrorCode 枚举。不过字符串比数字更容易“隐式出现”，因为代码里到处是字符串的判断，建议项目里定一个规范，必须在常量池或枚举中定义。

追问四：你在代码审查时怎么发现魔法值？

可以说肉眼扫描加静态扫描工具。肉眼扫描主要靠 review 习惯，看到裸数字裸字符串先提意见；工具层面可以用 Checkstyle 的自定义规则、PMD 的 AvoidMagicNumbers 规则，在 CI 阶段直接拦截，让魔法值根本走不到代码评审这一步。

5.3 至少记住一个真实案例

面试时纯讲理论容易给人一种“背书”的感觉，如果你能结合一个亲历的案例来讲，效果会好很多。

我自己遇到过的最惨痛的一次事故：之前某个订单模块里用了if (status == 0)判断待支付订单，而另一个模块里也用 0 表示删除状态。后来两个模块的代码被整合到一起，搜索结果出现了混乱，导致一批已删除的数据被当成了待支付订单，还是靠从凌晨排查到天亮才定位到问题。如果当时用了枚举，进场开始就会让取值范围不同，编译器早就报错了。

我建议你准备一个自己项目里关于魔法值的小故事，无论大小，只要真实，都能让你的回答比别人多一层“实战”味道。

6. 代码审查时怎么抓魔法值：几条可以落地的团队规范

6.1 肉眼扫描法：review 时候的几个关键词

日常代码审查是消灭魔法值的第一道防线。我自己在做 code review 的时候，有几个固定关注点：

第一，看到整数判断时，先看这个数是不是 0、1、-1 这种通用语义。如果是 0 和 1 判断真假，一般可以接受；如果数字明显带业务含义，比如状态、类型、渠道，就必须要求抽成枚举或常量。

第二，看到字符串比较时，直接搜一下这个字符串有没有定义的常量或枚举。如果是一个裸的equals("SUCCESS")，我基本都会在代码审查意见里提一句。

第三，看到数组或者集合里一堆数字，比如int[] levels = {1, 2, 3}，也要问清楚这些数字的含义。即使暂时没地方放，至少写个注释说明含义。

代码审查不能只是查逻辑 bug，代码风格和可维护性必须同步看。没有一个原则说“能跑就行”，等到不能跑的时候你已经晚了。

6.2 工具扫描法：CI 阶段自动拦截

光靠人眼去 review 效率不高，而且每天能盯的代码量有限。比较靠谱的做法是把魔法值检查纳入持续集成流程，用自动化工具去扫。

PMD 有个叫AvoidMagicNumbers的规则，只要开启就能检测出代码里未定义的魔法数字。Checkstyle 也有类似的MagicNumbercheck。如果项目是 Maven 构建，可以配置maven-pmd-plugin或maven-checkstyle-plugin，把质量门槛绑定到构建阶段。一旦有人提交了包含魔法值的代码，构建直接失败，提醒开发者修改后再提交。

使用 Checkstyle 时，一个常见的细节是要配置忽略项。比如第 0、1、2、-1 这些通用数值，以及 hashCode、数组索引等场景，如果不忽略的话会产生很多误报，搞得大家很烦，最后干脆关掉检查。我在团队里通常会把ignoreNumbers配置成0, 1, 2, -1，然后剩下的一律不能出现。

6.3 给团队立规的几条可复用建议

第一，约定枚举优先原则。新写的代码里涉及到固定取值范围的状态、类型、渠道等，原则上不允许裸用数字和字符串，一律定义枚举。

第二，约定常量命名规范。如果必须使用常量，常量名要能够直接被读懂，不能定义成A1、B2这种缩写。注释里最好带上这个值的来源和含义，特别是从外部接口对接过来的值。

第三，约定接口返回值处理。调用外部接口或者第三方 SDK 时，返回的状态码必须在当前服务里定义为枚举或常量，对外部系统的魔法值进行二次封装，避免把对方的裸值直接透传到自己的核心业务层。

第四，约定新项目不留存量债务。如果是新项目或新模块，从第一天起就要严格执行规范，不要给魔法值留任何生存空间。老项目里的存量魔法值，可以列一个技术债清单，安排时间分批清理，别让历史包袱压垮后续的每一次迭代。

7. 写在最后的一点个人体会

聊了这么多，魔法值本质上不是什么技术难题，而是一种编码习惯问题。它考验的是你有没有站在下一个维护者的角度去思考代码的可读性。我见过太多项目，就是在一次次“先写死，后面再说”的偷懒中走向失控的。消除魔法值只是手段，真正的目的是让你的代码具备更好的可维护性和可扩展性。

如果在实际项目里，你实在拿不准某个值该不该抽出来，我有一个最简单的判断标准：把这个值拿给你旁边的同事看，如果他看不出这个数字代表什么含义，那它大概率就是魔法值，该治理了。以前我在代码里看到if (status == 1)我真的会崩溃，现在队里的人都会习惯性地用枚举和常量来替代裸值，回头看看，这大概就是代码质量在一步步变好的感觉吧。