介绍

在这周的工作中

当我遇到业务场景时，我需要给旁边的同事打电话。 李同学打开一个接口，发现给我的返回值中含有枚举类型变量。 我随口提到最好不要使用这种接口返回值。 该对象包含枚举类型

李同学问我为什么，我就直接说了。 《Java开发手册》中强制要求第二方库可以定义枚举类型，参数可以使用枚举类型，但接口返回值不允许使用枚举类型或包含枚举类型的POJO对象

不过事后想一想，古晋老师在《手册》中写的这条规定就一定是正确的吗？

文本

杨小帅：我不明白，同学，你的界面有什么问题吗？ 序列化是否异常？

我不明白。 尽管心里慌了，但表面上还是故作镇定：不对，一定是你叫法不对。 你自己回去检查一下吧。 我没接触过这个界面。

毫无信心的连续三击，让小帅迷茫地回到了座位上。

这时我不明白了，赶紧打开思路。 “我修改了一个接口的枚举值，为什么会出现反序列化异常？不对，我记得手册上说接口返回值不允许使用枚举类型或者包含枚举类型的POJO对象，完了，完了完了，为什么我写代码的时候忘记了？让我赶紧改回来吧，只要我改得足够快，就没有人会发现我的bug。

此时，杨小帅已经静静地站在百度的工作站后面。 他看到百度改变了枚举，说道：“你就是不懂，你把这个标准给忘了，你这是怎么了？”

我不明白，有点害羞地笑了笑：“失误，失误，可控，可控”

杨小帅：“像这样的二方库接口，记得多关心一下返回值”

这时，小梅走过来说：“二房库是什么？”

杨小帅摇头：二方库也叫二方包，一般是指公司内部发布到中央仓库的、可以被公司内部其他应用依赖的库（jar包） ; 第一方库是本项目内部子项目模块的依赖。 图书馆； 第三方库是公司外部的开源库，例如

小梅：为什么这个接口返回值不允许使用枚举类型或者包含枚举类型的POJO对象？

杨小帅：是的。 如果你不理解并改变枚举，就会导致我们之间的枚举不同。 这个会出现在接口解析的时候，反序列化的时候会出现异常。

例如：你的本地枚举类有一个天气枚举：SUNNY、RAINY、。 如果根据天气计算心情的方法是：guess(xx)，那么传入这三个值就可以了。

返回值是guess（参数），那么对方操作后，返回一个SNOWY。 如果本地枚举中没有这个值，就会出现异常。

小美点点头，原来如此

这时，王经理走过来问大家：这个标准一定合适吗？

小梅：我觉得小帅说的有道理。 对接口返回值使用枚举确实会导致此类异常。

王经理：您认为枚举的含义是什么？

不明白：这个问题我知道。 顾名思义，看到这个字段就知道它的意思了。 与类型不同的是，如果你传递了1、2、3，你并不知道它意味着什么。

王经理：有道理。 枚举就是把已知的一切都列出来。 作为第二方/第三方库的提供者，您将使用我支持的任何内容。 这是安全的。 升级库版本后，支持更多。 如果你不了解情况，你就不会使用它。 反正你不能把我不支持的参数传给我，所以作为输入，枚举只是一种安全保证，但是作为返回值，情况就相反了。 我先告诉你这些东西你可以有，然后你规定你可以有这些东西，但不能有别的。 但是，是我说了算，不是你，所以你的规则都是扯淡。提供商偷偷升级，抛出异常的可能性接近100%。

那么如果遇到像那些不懂偷偷升级的骗子我们该怎么办呢？ 如果该接口的调用者较少，可以通知他们同步升级。 那么，如果一个接口有几百个调用者，是否可以实现同步升级呢？

那么我们在调用的时候是否可以增强我们的框架的健壮性呢？ 如果序列化的时候发现了新的枚举值，这个字段就会被设置为null，就像代码中写的那样？

王经理：好了，今天就到这里了，你们想想吧

小梅我不明白，小帅陷入沉思……

总结

实际上

第二方库返回的接口中，如果枚举的值必须使用枚举内部定义的方法和属性，那么配置一个策略，在无法进行转换时报错。

如果枚举只能处理业务中熟悉的枚举，不处理未知的枚举，则配置转为null的策略。

如果业务中无法识别枚举时将其视为默认值，请配置策略将其转换为默认值。

如果本地业务中根本不用枚举并且你不关心的话，可以在定义接收对象时直接定义为int或者type。

这样整个序列化框架中自定义枚举类的转换更加兼容安全检查和可扩展性。 它不仅可以兼容枚举的好处，还可以让我们的RPC框架变得健壮，所以在顶层可以做一些改进，让开发者更舒服吗？

当然，一切的出发点都是基于我们现在的业务场景和实际情况。 大家在使用的时候可以多思考一下。

附上古晋老师对于这个规则的解答。

由于升级，双方的枚举类不同，接口解析和类反序列化时出现异常。 Java中出现的任何元素都会有其背后的思维和逻辑（虽然不是绝对完美，但Java的顶层抽象已经是天才级别了），比如：接口、抽象类、注解、以及本文提到的枚举。 举起。 枚举的优点是类型安全，清晰直接，还可以使用等号进行判断，等号也可以用在。它的缺点也很明显，那就是不需要扩展。 但为什么要区分返回值和参数呢？ 如果它们不兼容，那么两者都会出现问题。 我们怎样才能允许参数具有枚举呢？ 当时的考虑是，如果不能使用参数，那么枚举几乎就没用了。 毕竟，参数输出是本地确定的。 如果你本地有的话，转移给它就不会有向前兼容性的问题。 但如果是接口返回的话就比较恶心了，因为解析出来的枚举值本地可能无法获取，会抛出序列化异常。 例如：你本地的枚举类有一个天气枚举：SUNNY、RAINY，如果根据天气计算心情的方法是：guess(xx)，那么传入这三个值就可以了。 返回值：guess（参数），那么对方操作后，返回一个SNOWY。 本地枚举中没有这样的值。 我傻眼了。

过去推荐的