上周排查一个接口 500 的问题日志里躺着这么一行No serializer found for class com.example.demo.dto.XXX and no properties discovered to create BeanSerializer后面还贴心地补了半句to avoid exception, disable SerializationFeature.FAIL_ON_EMPTY_BEANS。搜索“关闭 Spring Boot Jackson 的 FAIL_ON_EMPTY_BEANS”出来的答案几乎清一色是一行spring.jackson.serialization.fail-on-empty-beansfalse抄完红字消失收工。但这个开关是 Jackson 序列化体系里最像“止痛药”的东西——它能立刻让异常消失也能顺手把真正的问题藏起来。这篇内容我想把它彻底讲透异常在什么条件下触发、Jackson 内部是怎么判定“空 Bean”的、四种关闭方式各自适用什么场景、关掉之后序列化结果会变成什么样、以及我在实际项目里踩过的几个典型坑。无论你是刚接手一个 Spring Boot 项目的新手还是已经写过不少接口的老手看完都能形成一套自己的判断标准而不是遇到问题就无脑抄配置。1. 先把报错现场还原清楚1.1 报错信息到底在说什么这条异常的关键词是“no properties discovered”——不是找不到类不是字段类型不支持而是 Jackson 盯着一个类看了半天没有发现任何可序列化的属性于是拒绝为一个“什么都没有”的对象生成序列化器。换句话说Jackson 不是不能序列化而是它认为“你让我序列化一个空壳八成是哪里配错了”主动拦了下来。报错里那段括号提示是它在告诉你“如果你确定这就是我想要的结果请把SerializationFeature.FAIL_ON_EMPTY_BEANS关掉”。我第一次碰到这个报错时以为是 DTO 写错了翻来覆去检查字段名和类型其实完全找错方向。字段是有的但没有对外暴露的读取入口Jackson 就看不见。理解这一点后面的所有排查都会顺很多。一个很具体的触发场景Controller 里返回了一个只有私有字段、没有 getter 的 DTO方法签名是public ResultFooDto query()其中Result是通用包装类FooDto里三个字段全是 private 且没生成 getter。此时异常堆栈会指向MappingJackson2HttpMessageConverter.writeInternal看起来像是 web 层的问题实际根子在FooDto这个类本身。1.2 异常类型在不同 Jackson 版本里的变化这个细节很多人不注意但排查时会影响你的判断。在 Jackson 2.9 之前抛出的通常是com.fasterxml.jackson.databind.JsonMappingException2.9 之后Jackson 把“类定义层面的问题”统一收口到了com.fasterxml.jackson.databind.exc.InvalidDefinitionException它是JsonMappingException的子类。所以如果你在旧项目里看到的是JsonMappingException在新项目里看到的是InvalidDefinitionException别怀疑是不是换了框架只是版本不一样。这个变化带来的实际影响是如果你写了全局异常处理器去区分“参数错误”和“序列化错误”抓JsonMappingException在 2.9 依然能抓到因为父类关系还在。但如果你的日志告警规则是按异常全限定名匹配的就得把新的InvalidDefinitionException也加进去否则告警会漏。我在一个老系统升级 Jackson 版本时就吃过这个亏告警静默了两周才被发现。另外Spring Boot 2.x 默认带的是 Jackson 2.9 到 2.13 之间的版本3.x 默认带 2.15 往上具体小版本跟着 Boot 版本走。想确认自己项目里到底是哪个版本最省事的办法是在启动日志里搜jackson-databind或者用mvn dependency:tree -Dincludescom.fasterxml.jackson.core看依赖树。1.3 一个三十行内的最小复现想彻底搞明白这个异常最好的办法是自己复现一次。下面这段代码不需要任何业务逻辑纯纯的最小案例// 注意三个字段全是 private且刻意不生成 getter public class EmptyDto { private String name; private Integer age; private Boolean enabled; public EmptyDto() { this.name test; this.age 18; this.enabled true; } } RestController public class DemoController { GetMapping(/demo) public Object demo() { return new EmptyDto(); } }请求/demo你会稳定拿到一个 500日志里就是那条No serializer found。把EmptyDto换成Data标注的类或者手动补上 getter异常立刻消失。这个对比实验做完你就再也不会把这个异常和“数据为空”“对象是 null”混为一谈了——它跟对象里有没有值毫无关系只跟“有没有可读属性”有关系。反过来如果你把EmptyDto里的字段全部改成public即使没有 getterJackson 也能正常序列化出{name:test,age:18,enabled:true}。这恰好印证了下一节要讲的东西Jackson 找属性的路径有三条getter 只是其中之一。提示复现实验时建议单独起一个空项目别在主工程里临时改 DTO。我见过有人在主工程里为了验证把某个实体的 getter 全删了结果本地跑通了提交时忘了还原联调环境直接炸了一片接口。2. Jackson 判定“空 Bean”的完整逻辑2.1 属性发现Jackson 眼里什么才算“属性”这是理解整个问题的核心。Jackson 在构建一个类的序列化器时会先做一次“属性发现”它会从三个方向扫描字段成员但每个方向都有默认的可见性门槛getter 方法名字符合getXxx或isXxx布尔类型public 修饰无参数返回非 void。这是默认可见性最高的一类基本都会被发现。public 字段直接声明为 public 的成员变量会被识别为属性无需 getter。构造器参数与 setter主要用于反序列化场景序列化时它们更多是“辅助参与”属性名的确定。除了这三个方向还有注解通道JsonProperty、JsonGetter、JsonAnyGetter、JsonValue等注解都能强行把一个元素变成属性哪怕它是个 private 方法。这也是为什么有些类明明没有 getter却能被正常序列化——因为类上或方法上有注解兜住了。把这套规则落到实际代码上一个只有 private 字段的类如果既没有 getter也没有JsonProperty标注也没有开启字段级可见性放宽那么在 Jackson 眼里它就是一个“零属性”类型。这跟“这个对象里有没有数据”完全是两回事这一点必须刻在脑子里。注意record 类型是个例外。Java 16 起正式支持的 record它的访问器方法名是name()而不是getName()Jackson 2.12 之后做了专门适配能正常识别。但如果 record 的某个组件被JsonIgnore标注或者整个 record 被JsonIgnoreType标注一样会退化成空 Bean。2.2 走到抛异常那一行之前发生了什么序列化的调用链大致是这样的ObjectMapper.writeValue→ 找到目标类型的JsonSerializer→ 缓存里没有就现造一个。现造的过程交给BeanSerializerFactory它会先构造一个BeanSerializerBuilder然后把前面属性发现得到的属性集合塞进去。关键就在这一步之后如果属性集合为空BeanSerializerFactory会去读一次SerializationFeature.FAIL_ON_EMPTY_BEANS这个开关。开关打开默认就是打开的抛InvalidDefinitionException开关关闭就退化成一个只输出{}的占位序列化器。所以这个开关的语义其实非常清晰——它不是“允许空对象”而是“允许零属性类被序列化成空 JSON 对象”。搞明白了这一点你就能理解为什么关闭这个开关之后返回的是{}而不是null也不是直接被忽略。很多前端同学拿到{}会以为是后端返回了空对象实际上是后端告诉 Jackson“这个类确实没东西可写你就写个空壳吧”。接口契约上这就埋了一个隐患前端如果判断if (data){}是 truthy 的逻辑就走偏了。2.3 三个容易混淆的开关别再张冠李戴Jackson 的SerializationFeature和DeserializationFeature里有一堆名字很像的开关实际项目里最常被搞混的是下面这三个。我整理了一张表建议收藏下次看日志时先对号入座配置项完整枚举名默认值触发时机典型错误信息开头空 Bean 检查FAIL_ON_EMPTY_BEANS开启序列化时类没有任何可写属性No serializer found for class ...未知字段检查FAIL_ON_UNKNOWN_PROPERTIES开启反序列化时 JSON 里有类中不存在的字段Unrecognized field xxx自引用检查FAIL_ON_SELF_REFERENCES开启对象图里出现直接自引用Direct self-reference leading to cycle这三个开关分属不同的处理阶段一个在写一个在读一个在遍历对象图。所以看到No serializer found却去关FAIL_ON_UNKNOWN_PROPERTIES是典型的南辕北辙。我在问答区见过不止一次这种提问配置贴出来一看方向完全错了。再多说一句FAIL_ON_UNKNOWN_PROPERTIES它在 Spring Boot 里其实默认是被关掉的因为 Spring Boot 的JacksonAutoConfiguration会主动调用disable(DeserializationFeature.FAIL_ON_UNKNOWN_PROPERTIES)。这也是为什么很多人在纯 Jackson 环境里跑得好好的代码搬到 Spring Boot 里反而“报错消失了”——不是你的配置生效了是框架替你关的。这个默认行为和FAIL_ON_EMPTY_BEANS恰好相反后者 Spring Boot 没有动保持 Jackson 原生的开启状态。3. 四种关闭姿势与各自适用边界3.1 配置文件一行搞定但有生效前提最省事的方式直接在application.yml里加spring: jackson: serialization: fail-on-empty-beans: false或者用 properties 写法spring.jackson.serialization.fail-on-empty-beansfalse两种都能被 Spring Boot 的宽松绑定识别。原因在于JacksonProperties里定义的是MapSerializationFeature, Boolean serialization而 Spring Boot 的转换服务在处理枚举 key 时会做“去连字符、去下划线、忽略大小写”的比对所以fail-on-empty-beans、FAIL_ON_EMPTY_BEANS、failOnEmptyBeans这几种写法最终都指向同一个枚举。我实测过前两种都能正常生效。这个方式的优点是零代码侵入、环境隔离天然方便application-dev.yml和application-prod.yml可以给不同值。但它有明确的前提你的ObjectMapper必须是由 Spring Boot 自动配置出来的那一个。一旦项目里有人手动new了一个ObjectMapper或者自己声明了一个ObjectMapper类型的 Bean这行配置就形同虚设。判断方法很简单在启动类里打一行日志System.out.println(objectMapper.getSerializationConfig().isEnabled(SerializationFeature.FAIL_ON_EMPTY_BEANS))打印true就说明配置没进去。还有一个容易被忽略的点spring.jackson.*这一组配置只影响 Spring Boot 自动配置的ObjectMapper。如果你用的是 WebFluxJackson2JsonEncoder和Jackson2JsonDecoder也是基于这同一个ObjectMapper构建的所以配置同样有效。但如果项目里同时引了 WebMvc 和 WebFlux 且同时启用就要注意两套消息转换器的装配差异了。3.2 Jackson2ObjectMapperBuilderCustomizer我更推荐的姿势如果你需要在代码层面控制或者项目里已经有了一堆定制逻辑我建议用Jackson2ObjectMapperBuilderCustomizer。它的定位是“在 Spring Boot 构建ObjectMapper的过程中插一脚”而不是把整个ObjectMapper替换掉所以spring.jackson.*里的其他配置不会丢Configuration public class JacksonTuningConfig { Bean public Jackson2ObjectMapperBuilderCustomizer emptyBeanCustomizer() { return builder - builder .featuresToDisable(SerializationFeature.FAIL_ON_EMPTY_BEANS) // 可以顺便做点别的定制比如日期格式 .simpleDateFormat(yyyy-MM-dd HH:mm:ss); } }这段代码的价值在于“叠加”而不是“替换”。多个CustomizerBean 会被 Spring Boot 收集起来依次执行所以你可以把“关空 Bean”“统一日期格式”“注册自定义模块”拆成三个互不干扰的Customizer团队里不同人维护不同文件也不会冲突。这个设计比在一个大Configuration里堆十几行objectMapper.configure(...)要清爽得多。有一个版本细节要说清楚Jackson2ObjectMapperBuilderCustomizer在 Spring Boot 2.x 和 3.x 里都位于org.springframework.boot.autoconfigure.jackson包下接口签名也没变。所以从 2.7 升到 3.x 时这个类本身不需要改。但如果你在升 3.x 时把javax.*改成jakarta.*的过程中涉及到了 Jackson 的ObjectMapper相关 import注意别顺手把这个Customizer的包名也改错了。我见过有人批量替换时把autoconfigure.jackson误伤编译报错排查了半小时。3.3 自定义 ObjectMapper Bean 的代价比你想的大很多老项目的写法是这样的Configuration public class JacksonConfig { Bean Primary public ObjectMapper objectMapper() { ObjectMapper mapper new ObjectMapper(); mapper.configure(SerializationFeature.FAIL_ON_EMPTY_BEANS, false); return mapper; } }代码能跑异常也确实没了但代价你可能没意识到。Spring Boot 的JacksonAutoConfiguration里创建ObjectMapper的那个方法带了ConditionalOnMissingBean也就是说只要你声明了同类型 BeanBoot 就不再创建自己的那个。结果是spring.jackson.*下的所有配置集体失效包括日期格式、时区、属性包含策略、命名策略。JavaTimeModule、Jdk8Module、ParameterNamesModule这些 Boot 自动注册的模块能不能用全看你自己有没有手动注册。LocalDateTime序列化报Java 8 date/time type not supported by default八成就是这个原因。枚举的READ_UNKNOWN_ENUM_VALUES_AS_NULL、ACCEPT_CASE_INSENSITIVE_ENUMS等行为也回到 Jackson 原生默认。所以除非你有非常特殊的诉求比如需要完全掌控模块注册顺序否则别走这条路。如果实在要自定义至少用Jackson2ObjectMapperBuilder来构建能把上面这些问题补回大半Bean Primary public ObjectMapper objectMapper(Jackson2ObjectMapperBuilder builder) { ObjectMapper mapper builder.build(); mapper.configure(SerializationFeature.FAIL_ON_EMPTY_BEANS, false); return mapper; }注意这里注入的是Jackson2ObjectMapperBuilder它会带着Customizer已经施加过的配置所以spring.jackson.*里的东西大部分还在。但严格说这样做仍然绕过了JacksonAutoConfiguration中ObjectMapper那一步的完整逻辑稳妥起见还是优先选 3.2 的方案。3.4 WebMvcConfigurer 与消息转换器层面还有一种更“边缘”的做法直接改HttpMessageConvertersConfiguration public class WebConfig implements WebMvcConfigurer { Override public void extendMessageConverters(ListHttpMessageConverter? converters) { for (HttpMessageConverter? converter : converters) { if (converter instanceof MappingJackson2HttpMessageConverter jacksonConverter) { jacksonConverter.getObjectMapper() .disable(SerializationFeature.FAIL_ON_EMPTY_BEANS); } } } }这个写法的适用场景非常窄你没法改ObjectMapper的构建过程但又想只影响 HTTP 层的输出。好处是影响面可控坏处是它只管得住 MVC 的响应序列化管不住RestTemplate、消息队列、缓存序列化。我在一个遗留系统里用过一次原因是那个项目里ObjectMapper被别的团队锁死了不让动只能从转换器下手。3.5 配置优先级理清楚少走弯路几种方式同时存在时谁说了算我按实际验证结果整理如下方式生效范围是否覆盖spring.jackson.*其他配置推荐度spring.jackson.serialization.fail-on-empty-beansfalse全局自动配置的 ObjectMapper不覆盖属于其中一项高Jackson2ObjectMapperBuilderCustomizer全局自动配置的 ObjectMapper不覆盖叠加执行最高自定义ObjectMapperBean注入该 Bean 的全部位置覆盖其他 Boot 配置失效低WebMvcConfigurer改转换器仅 MVC 响应序列化不覆盖中应急这张表的核心判断依据只有一条你要动的是“谁创建的 ObjectMapper”。动配置就是动 Boot 创建的那个动 Bean 就是换掉它动转换器就是只改使用者。想清楚这一层选型就不会纠结。4. 关掉之前先确认你关的是不是该关的4.1 关闭之后序列化结果长什么样把开关关掉之后一个零属性的对象会被序列化成{}。这个结果本身没有对错关键看你的接口契约怎么定义。如果接口文档里写着“data 字段返回对象无数据时为 null”那么{}就违反了契约前端拿到的不是null走if (data null)的分支永远不成立。更麻烦的是嵌套场景。假设你的返回结构是{code:0,data:{user:{},order:null}}前端遍历时看到user是个对象就去取user.name拿到undefined页面显示成“undefined”三个字。这种问题排查起来特别费劲因为后端日志干干净净没有任何异常。所以我的建议是如果决定关闭这个开关一定要同步检查前端对空对象的处理逻辑或者干脆在Result包装类里约定好“空数据统一返回null”用JsonInclude(JsonInclude.Include.NON_NULL)把空对象挡掉。不过要注意NON_NULL挡的是null{}不是null挡不住。想挡{}得靠业务逻辑层面判断Jackson 本身没有“空对象也当 null 处理”的开关。4.2 六种根因与对应修法关开关是“止血”找根因才是“治病”。我把实际遇到过的根因归了归类根因典型现象对症修法DTO 只有 private 字段无 getter新建的类编译正常但序列化报错补 getter 或用 LombokDataLombok 注解处理器未生效代码里有Data但target/classes里反编译看不到 getter检查 IDE 注解处理开关与maven-compiler-plugin配置全字段被JsonIgnore类上有JsonIgnoreProperties或每个 getter 都加了JsonIgnore逐个核对注解确认是否有误加代理对象懒加载/字节码增强从 ORM 拿到的对象是代理实例属性列表为空转 DTO或用JsonIgnoreProperties({hibernateLazyInitializer,handler})空壳类/标记类类里确实一个字段都没有如某些空请求体加JsonSerialize自定义或明确返回null泛型擦除导致的Object运行时类型字段声明为Object运行时是某个无属性类明确类型或加类型信息这六种里前三种占了绝大多数。特别是第一种新人写 DTO 时经常只写字段不写 getter本地用 IDEA 的调试窗口看对象有值就以为万事大吉一跑接口就炸。第二种更隐蔽因为代码看起来是对的问题出在编译产物上。判断方法很简单javap -p target/classes/com/example/FooDto.class看看有没有getName这样的方法签名没有就是处理器没生效。4.3 分环境策略开发别关生产谨慎关我个人的做法是开发环境和测试环境保持开启生产环境视情况关闭。理由很直接——开发和测试阶段这个异常是最好的“免费代码审查员”它会逼着你把 DTO 定义、Lombok 配置、代理对象处理这些问题在提测前就解决掉。一旦关了这些问题会伪装成“接口返回空对象”等到线上被发现时排查成本翻好几倍。生产环境如果确实存在“某些第三方库返回的对象没法改、但也不能让接口 500”的情况再考虑关闭。关闭的同时建议加一条监控对返回{}的响应做计数数量异常增长时告警。这样既不阻断业务也不至于让问题石沉大海。这个思路我在两个项目里落地过效果比单纯关开关好得多。5. 四个踩坑实录5.1 Lombok 注解处理器掉线代码看着对但字节码里啥都没有这个坑我第一次遇到时足足查了一下午。现象是某个 DTO 明明标了DataIDE 里也能点进getName()方法但一跑接口就报空 Bean。最后用javap一看编译出来的 class 里压根没有 getter。原因在于 IDE 的“启用注解处理”开关被某次插件更新重置了IDE 靠自己的语法分析让你能点进去看但maven-compiler-plugin编译时没调 Lombok 处理器产物就是裸字段。这类问题在多人协作、CI 和本地环境不一致时尤其常见。我的应对办法是在pom.xml里把 Lombok 显式声明为provided并配置annotationProcessorPaths同时在 CI 脚本里加一步javap校验关键 DTO 的方法签名成本很低但能挡住一类低级故障。顺带提一句如果你用的是 Java 17 以上加较新版本的 Lombok注意版本匹配。版本不匹配时的表现往往不是编译报错而是“部分注解生效、部分不生效”这种半吊子状态最难查。5.2 代理对象与懒加载你拿到的可能不是你以为的那个类从 ORM 里查出来的对象很多时候不是实体类本身而是字节码增强生成的子类。这类代理对象有两个特点一是类名带一长串后缀二是它的字段值可能还是空的真正的数据在拦截逻辑里。Jackson 序列化时会按运行时类型去找属性代理类如果没继承到 getter或者 getter 被特殊处理过就会判定为空 Bean。常见的应对方式是在实体类上加JsonIgnoreProperties({hibernateLazyInitializer, handler}) public class OrderEntity { ... }这两个名字是 ORM 代理类额外暴露出来的属性忽略掉它们能避免另一类“序列化出奇怪字段”的问题。但更彻底的做法是别把实体直接返给前端统一转成 DTO。转 DTO 这一步看似多写了代码实际上把“序列化什么问题该由谁负责”这件事划清楚了长期看是划算的。我在一个项目里推行过这个规范接口层的序列化异常几乎归零。5.3 RestTemplate、消息队列、缓存里的 ObjectMapper 是另外一个人这是最容易被忽略的一类。你在application.yml里配了spring.jackson.*以为万事大吉结果发现调第三方接口时序列化请求体仍然报空 Bean。原因很简单new RestTemplate()使用的默认消息转换器里那个ObjectMapper是独立构建的跟你 Spring 容器里的不是同一个实例。正确的做法是用RestTemplateBuilder构建它会带上 Spring Boot 配置好的转换器Bean public RestTemplate restTemplate(RestTemplateBuilder builder) { return builder.build(); }消息队列同理。以 Kafka 的 JSON 序列化器为例它内部默认new ObjectMapper()需要在配置里显式指定或者自己构造序列化器实例传进去。缓存场景比如某些 JSON 序列化策略也是一样。判断方法只有一个看这个组件里的 ObjectMapper 是谁 new 出来的。只要是new出来的就跟你的全局配置无关。5.4 全字段JsonIgnore造成的“人为空 Bean”还有一个很隐蔽的场景类上本来有正常的 getter但某个 teammate 为了防止敏感字段外泄在 getter 上批量加了JsonIgnore加着加着把这个类的所有属性都忽略了于是它变成了“人为空 Bean”。这时候报错信息一样但你在 DTO 定义里翻半天也找不到问题因为字段和 getter 都在只是被注解屏蔽了。这类问题的排查技巧是不要只看类定义用ObjectMapper的getSerializationConfig().introspect(javaType)打印出BeanDescription看findProperties()返回的集合是不是空的。如果集合为空但你肉眼看代码有 getter那基本就是注解或者可见性配置的问题。这个方法比一行行读代码高效得多尤其在类很大、注解很多的时候。6. 排查套路与速查表6.1 三步定位法从现象到根因我处理这类问题有个固定套路三步之内基本能定位。第一步确认是不是空 Bean。看异常信息里的类名用javap -p看这个类的字节码里有没有 getter或者直接在 IDE 里用反射打印getClass().getMethods()过滤get开头的方法。这一步能筛掉 60% 的问题。第二步确认 ObjectMapper 是谁。在出问题的位置打日志打印objectMapper的hashCode再在启动时打印容器里注入的那个hashCode两个不一致就说明用错了实例。这一步能筛掉 30% 的问题尤其是跨组件场景。第三步确认配置有没有加载。打印objectMapper.getSerializationConfig().isEnabled(SerializationFeature.FAIL_ON_EMPTY_BEANS)如果是true说明你的关闭配置压根没生效回头检查 Bean 冲突和配置文件加载顺序。这三步走完剩下的问题基本都在“注解误加”或者“代理类型”这两个方向上范围已经很小了。6.2 常见问题速查表现象可能原因快速验证方式配了 yml 但依然报错项目里自定义了 ObjectMapper Bean打印容器内 ObjectMapper 的类名本地好使打包后报错Lombok 处理器在 CI 未生效javap检查编译产物只有某个接口报错该接口返回的 DTO 缺 getter单独对该 DTO 做序列化测试换成 DTO 后就好了原对象是 ORM 代理打印obj.getClass().getName()关闭后返回{}但前端报错前端未处理空对象抓包看响应体启动直接失败配置项拼写错误导致绑定失败检查枚举名拼写与缩进层级6.3 我个人沉淀下来的几条经验第一条能改代码就别改配置。空 Bean 异常九成以上是代码问题补个 getter、转个 DTO、加个注解都是几分钟的事关开关是几秒钟的事但留下的是长期隐患。我现在的默认动作是先查根因实在改不动才考虑关。第二条关闭开关时一定要加注释说明原因和范围。配置项这种东西半年后没人记得为什么加。我习惯在 yml 里写一行注释比如“某第三方回调对象无 getter无法修改仅在 prod 关闭”。这行注释在未来某次重构时会救你一命。第三条给关键 DTO 补一个序列化冒烟测试。用ObjectMapper直接对 DTO 做一次writeValueAsString断言不抛异常。这个测试跑一次不到一毫秒但能在 CI 阶段拦住“忘记加 getter”这类低级问题。我在两个项目里加过加起来省下的排查时间远超写测试的成本。第四条升级 Jackson 或 Spring Boot 大版本时单独回归一次序列化行为。FAIL_ON_EMPTY_BEANS的默认值虽然一直没变但配套的属性发现规则、模块注册方式在不同版本间是有细微差异的。特别是从 2.x 升 3.x 时JavaTimeModule的注册行为和ObjectMapper的构建链路都有调整值得单独跑一轮接口回归。第五条不要在公共基础库里全局关这个开关。有些团队会把它写进公司级的 starter结果所有接入方都失去了这个“免费代码审查员”。基础库应该只提供能力不该替业务方做这种取舍。这个观点我在内部评审时提过后来确实改成“提供开关但默认不关”。最后说个我自己的判断标准如果一个问题出现后你的第一反应是“搜一下怎么关掉它”那多半说明你还没搞清楚它想告诉你什么。FAIL_ON_EMPTY_BEANS这条异常的价值恰恰在于它把“类定义有问题”这个隐性错误变成了显性错误。关掉它很容易难的是关掉之后还能记得当初为什么报错。