Netty EventLoopGroup 缺失排查与修复

凌晨两点被告警叫起来，日志里一行java.lang.NoClassDefFoundError: io/netty/channel/EventLoopGroup，服务起不来，本地跑得好好的。这种场景做 Java 后端的人大概率都遇到过，尤其是项目里引了 RPC 框架、消息队列客户端、搜索引擎客户端、网关组件之后，Netty 就像空气一样存在——平时感觉不到，一旦缺了立刻窒息。这个报错看起来简单，但它背后能牵扯出依赖缺失、版本混战、打包插件配置、类加载隔离、模块化路径等至少五条完全不同的排查路线，而很多人第一反应是“加个 netty 依赖”，结果加完还是报同样的错，因为方向从一开始就错了。

这篇内容面向的是已经能看懂 Java 异常栈、会跑 Maven 或 Gradle 命令，但在“类明明在依赖里、运行期就是找不到”这类问题上还缺少系统方法的中级开发者。我会把这个错误的产生机理拆开，把EventLoopGroup在 Netty 里的确切位置讲清楚，然后给出从依赖树到产物验证的完整定位链路，再按场景给出修复方案。文中涉及的具体项目、模块、公司一律使用虚构代称，步骤和命令都可以直接照着敲。

1. 先把“找不到类”这件事问到根上

1.1 NoClassDefFoundError 与 ClassNotFoundException 差在哪

很多人把这两个异常混着理解，但它们的触发时机完全不同，混着理解会直接导致排查方向跑偏。ClassNotFoundException是显式加载失败，典型场景是Class.forName("xxx")、ClassLoader.loadClass("xxx")或者反序列化时按名字找类，JVM 明确告诉你“我按这个名字找，没找到”。而NoClassDefFoundError是隐式加载失败，它通常发生在字节码已经通过校验、链接阶段需要解析某个符号引用的时候——换句话说，代码里写死了new NioEventLoopGroup()或者某个方法的参数类型是EventLoopGroup，JVM 在执行到那一行、需要把这个符号引用解析成真正的类对象时，发现类加载器给不出这个类。

这里有个非常关键的区别：NoClassDefFoundError有两种完全不同的成因，第一种是类文件压根不存在，第二种是类文件存在，但它的静态初始化抛了异常。第二种情况迷惑性极强，因为第一次报的是ExceptionInInitializerError，之后同类加载请求就会变成NoClassDefFoundError，看起来像是“类丢了”，实际上是“类加载过但初始化失败了，JVM 把它标记成 erroneous 状态，后续不再重试”。所以在动手加依赖之前，先做一件事：把完整的异常栈往上翻，看看有没有被包裹的Caused by。

对于io.netty.channel.EventLoopGroup这个具体的类，它是接口，本身几乎没有静态初始化逻辑，所以绝大多数情况下属于第一种成因——类真的不在运行期 classpath 上。但这不代表可以跳过看栈这一步，因为栈里往往藏着更重要的信息：是哪个框架的哪个类在引用它。如果是你自己的启动类引用，说明你直接用了 Netty；如果是某个客户端库的Bootstrap类引用，说明是传递依赖出了问题。这两条路的修法不一样。

提示：排查时优先看at行的第一行，它告诉你“谁在要这个类”。这个信息比“缺了什么类”更有价值。

1.2 EventLoopGroup 到底住在哪个 jar 里

io.netty.channel.EventLoopGroup这个接口位于netty-transport模块，不在 netty-common，也不在 netty-buffer。它继承自io.netty.util.concurrent.EventExecutorGroup（后者在 netty-common 里），是 Netty 事件循环体系的门面接口。围绕它还有几个容易混淆的近亲：EventLoop继承EventLoopGroup和EventExecutor，NioEventLoopGroup是面向 NIO 的具体实现，EpollEventLoopGroup则需要额外的 native 依赖。

把这个继承链讲清楚，是因为它能解释一个很常见的现象：报错是EventLoopGroup找不到，你加了netty-common依赖，还是找不到；你加了netty-buffer，还是找不到。因为这两个模块里根本没有io.netty.channel这个包。同理，如果某天报错变成io.netty.util.concurrent.EventExecutorGroup找不到，那才轮到怀疑 netty-common。报错里那个完整类名，就是定位模块最准的线索，把包名和模块的对应关系记住，能省掉大量试错。

顺带提一个历史包袱：Netty 3 的包名是org.jboss.netty，Netty 4 才改成io.netty。所以只要报错里出现io.netty，就说明代码走的是 Netty 4 的 API，这一点在排查“版本混搭”时是重要判据——如果你的项目里同时存在org.jboss.netty和io.netty两套依赖，那基本可以确定有一个老库在拖后腿。

1.3 编译期能找到、运行期找不到的三个分界点

为什么本地 IDE 里跑得好好的，换个环境就炸？因为从“写代码”到“跑起来”中间有三个分界点，任何一个出问题都会导致这个错。

第一个分界点是作用域。Maven 的provided、runtime、test这些 scope 决定了依赖是否进入最终的运行期 classpath。IDE 在运行 main 方法时往往会把所有 scope 的依赖都塞进去，所以你感觉不到问题；但打包成 jar 之后，provided的依赖不会进去。

第二个分界点是打包产物的结构。普通 jar 的META-INF/MANIFEST.MF里有一行Class-Path，它决定 jar 之外的依赖怎么找；Spring Boot 的 fat jar 用的是BOOT-INF/lib目录加自定义的LaunchedURLClassLoader；war 包则依赖容器的WEB-INF/lib。这三种结构的类查找规则完全不同，产物结构一旦和你以为的不一致，就会出这个错。

第三个分界点是类加载器的层级。在 Tomcat、OSGi、各种插件化框架里，你的代码可能跑在一个子类加载器里，而 Netty 的类可能被放在了父加载器或者干脆被隔离掉了。这种情况下，依赖树里明明有netty-transport-4.1.x.jar，产物里也能jar tf看到那个 class，但运行时就是找不到——因为加载你的那个 ClassLoader 的父链上看不到它。

把这三个分界点记住，后面的排查就有了坐标系：先判断是哪一类，再决定用哪套工具。

2. 用依赖树把“这个类去哪了”问清楚

2.1 Maven 项目的三条核心命令

Maven 项目里，第一步永远是mvn dependency:tree，但直接用默认输出会被几百行淹没。我的习惯是带上过滤条件直接看目标：

mvn dependency:tree -Dincludes=io.netty

这条命令只输出和io.netty相关的依赖路径，能同时回答两个问题：netty 到底有没有被引进来、是通过哪条传递路径进来的。如果输出为空，恭喜，问题定位完成——你的项目里根本没有 netty，某个库是通过运行时反射或者动态加载用的它，你需要显式补依赖。

如果有输出，重点看版本号和路径缩进。路径缩进代表依赖层级，缩进越深说明是传递依赖。如果同一个netty-transport出现了两次且版本不同，Maven 的“最近者优先”规则会只保留一条，被裁掉的那条会标上(omitted for conflict with xxx)。这种 omitted 标记是排查版本冲突的金矿。

第二条命令是查看某个模块的全部依赖，包括被 scope 过滤掉的：

mvn dependency:list -DincludeScope=test

有时候你会在测试 scope 里看到 netty，却不在 compile scope 里，这能解释“单元测试跑得通、main 方法跑不通”的怪现象。

第三条是直接看最终生效的完整依赖坐标集合：

mvn dependency:build-classpath -Dmdep.outputFile=cp.txt

生成的cp.txt就是运行期（按当前 scope 计算）的完整 classpath，一行一个 jar。这时候可以直接在里面搜netty-transport，看看它到底在不在。这个方法比看依赖树更“实锤”，因为它反映的是最终结果而不是依赖声明。

2.2 Gradle 场景下的依赖洞察

Gradle 的命令更丰富一些。快速看某个依赖的解析结果：

./gradlew dependencies --configuration runtimeClasspath | grep -i netty

只关心 netty 时可以直接过滤。想追一条具体路径为什么被选中的话，用dependencyInsight：

./gradlew dependencyInsight --dependency netty-transport --configuration runtimeClasspath

这个任务会列出所有候选版本、每个版本的来源，以及最终为什么选了这一版，比 Maven 的 omitted 标记信息量更大。如果输出里有because of rule或者selected by rule，说明项目里配置了resolutionStrategy或者 BOM 约束，这种情况下版本可能被强行拉到某个值，需要一并检查。

还有一个容易被忽略的点：Gradle 的implementation和api配置。api会把依赖暴露给下游模块，implementation不会。多模块项目里，如果 A 模块implementation了 netty，B 模块依赖 A 但自己没用 netty，那 B 在编译期看不到 netty 的类，但运行期 classpath 上会有——反过来也可能因为配置不当而丢失。

2.3 直接翻产物：比依赖树更硬的证据

依赖树告诉你“声明了什么”，产物解包告诉你“到底打进去了什么”。这两个可能完全不一致。验证方法：

# 普通 jar / fat jar 都适用 unzip -l your-app.jar | grep -i netty

如果是 Spring Boot 的 fat jar，netty 的 jar 会平铺在BOOT-INF/lib/下面，你能看到BOOT-INF/lib/netty-transport-4.1.xx.Final.jar这样的完整文件名。注意看版本号，如果和你依赖树里的版本不一致，说明打包时发生了版本替换，通常是 shade 插件或者 BOM 干的。

更进一步，想确认那个类真的在 jar 里：

unzip -l your-app.jar | grep -i "netty-transport" unzip -p your-app.jar BOOT-INF/lib/netty-transport-4.1.xx.Final.jar > /tmp/nt.jar jar tf /tmp/nt.jar | grep "io/netty/channel/EventLoopGroup"

最后这条能给出确定的答案。如果类不在，问题在打包；如果类在，问题在类加载器。这一步是整个排查链路的分水岭，很多人卡住就是因为跳过了它，一直在依赖层面反复折腾，而真正的问题在产物或者加载器。

3. 五类高频成因，按踩坑概率排序

3.1 根本没引 Netty，或者坐标写错了

这是最容易解决也是最常见的一类。典型场景：项目用了某个轻量客户端库，它在文档里写“自带 Netty”，但实际发布到仓库里的那个版本把 Netty 标成了provided或者optional。Maven 的optional依赖是不传递的，对方写了<optional>true</optional>，你就得自己补。

另一个变种是坐标写错。netty-all在较新版本里更接近一个聚合坐标，是否把所有类打进单个 jar 取决于具体版本，不要想当然地以为“引了 netty-all 就什么都有”。我的建议是不用 netty-all，按需引具体模块：netty-transport、netty-handler、netty-codec、netty-buffer、netty-common。这样依赖关系清晰，也不会因为一个大包引入一堆用不到的类。

判断方法很简单：如果mvn dependency:tree -Dincludes=io.netty输出为空，那就是这一类，直接补netty-transport即可，版本要和其他 netty 模块保持一致。

3.2 版本打架：3 和 4 并存、4.0 和 4.1 混用

Netty 3 到 4 是包名级别的断裂，org.jboss.netty和io.netty完全不兼容，不可能通过版本仲裁“合并”。如果项目里同时出现两套，那一定是某个老库还在用 Netty 3。这时候的做法是：找到那个老库，看有没有新版本升级，实在升不了就把它隔离出去（比如独立进程、独立模块），别指望在同一个 ClassLoader 里共存。

更隐蔽的是 4.0 和 4.1 混用。包名一样，类名一样，但内部行为、方法签名有细微差别。Maven 只会保留一个版本，通常是路径最短的那个。如果某个库是针对 4.0 编译的，被强行拉到 4.1，运行时可能出现NoSuchMethodError；反过来如果主项目要求 4.1 的某个新 API，被仲裁成 4.0，那就是NoClassDefFoundError或者NoSuchMethodError。

排查方法是在依赖树里搜 omitted：

mvn dependency:tree -Dverbose -Dincludes=io.netty

加上-Dverbose之后，被裁掉的版本也会显示出来。看到(omitted for conflict with 4.0.x)这类标记，就要评估这个仲裁结果是否符合预期。修复手段是显式在dependencyManagement里锁定版本，而不是靠“最近者优先”这种隐式规则碰运气。

3.3 scope 与打包插件：三个经典陷阱

第一个是provided。这个 scope 的语义是“编译时需要，运行时由环境提供”。在 web 应用里它常用于 servlet-api，因为容器会提供。但如果某个库把 netty 写成了 provided，而你的运行环境并不提供 netty，那就必然报错。

第二个是maven-shade-plugin的relocate。这个功能会把依赖的包名整体重命名，比如把io.netty改成shaded.io.netty，目的是避免和宿主环境冲突。如果你的代码直接引用了io.netty.channel.EventLoopGroup，而 shade 把 netty relocate 了，那你的代码就会找不到类——因为类被搬到shaded.io.netty.channel.EventLoopGroup去了。这个坑非常隐蔽，因为依赖树、产物里都能看到 netty 的痕迹，唯独类名对不上。

第三个是spring-boot-maven-plugin的repackage配置。默认情况下它会生成一个可执行 fat jar，但如果你的pom里配了classifier或者同时生成了普通 jar，就有可能出现“部署的是普通 jar、依赖没进去”的情况。检查方法就是前面说的unzip -l，直接看BOOT-INF/lib目录。

3.4 类加载隔离：容器与插件化框架

这一类最难查，因为表面上一切正常。典型场景是把应用部署到外部 Servlet 容器，容器有自己的类加载体系，WEB-INF/lib和容器的公共 lib 是分开的。如果某个依赖被容器提供了一份（比如容器自带的某个 RPC 组件），而你应用里又打了一份，就可能出现“加载你的 ClassLoader 看不到容器的那份、或者看到的是被容器过滤掉的那份”。

插件化框架同理。很多中间件平台会用自定义 ClassLoader 加载业务插件，插件之间的依赖是隔离的。这种情况下，Netty 被放在平台层还是插件层，决定了业务代码能不能直接引用它。诊断方法是在报错处把 ClassLoader 打出来：

System.out.println(EventLoopGroup.class.getClassLoader());

这一行在类加载成功时自然没意义，但可以在捕获NoClassDefFoundError之后，用Thread.currentThread().getContextClassLoader()和当前类的getClassLoader()打印出来对比，看看两条链上分别有哪些 jar。更彻底的做法是用-verbose:class启动参数，JVM 会打印每个类的加载来源，能看到到底是从哪个 jar、哪个 ClassLoader 加载的。

3.5 中间件客户端带进来的“隐形依赖”

这一类严格说不算“缺失”，而是“你以为有其实没有”。很多客户端库会把 Netty 作为实现细节藏起来，对外只暴露自己的 API。你在代码里import io.netty.channel.EventLoopGroup直接用，编译期因为依赖传递能过，但对方的 POM 里可能标了optional，或者用了runtimescope。到了真正打包的时候，netty 就不在 classpath 上了。

判断依据还是依赖树：如果 netty 的路径是某个客户端库 -> netty-transport，且层级较深，就要警惕。稳妥做法是凡是自己在代码里直接 import 的类，所在依赖一定要显式声明在 POM 里，不要依赖传递。这条规则能消灭掉一大半这类问题。

4. 分场景的修复动作与验证手法

4.1 普通 Maven 工程的最小修法

先加依赖，版本用一个属性统一管理：

<properties> <netty.version>4.1.100.Final</netty.version> </properties> <dependency> <groupId>io.netty</groupId> <artifactId>netty-transport</artifactId> <version>${netty.version}</version> </dependency> <dependency> <groupId>io.netty</groupId> <artifactId>netty-handler</artifactId> <version>${netty.version}</version> </dependency>

只加netty-transport通常够解决EventLoopGroup找不到的问题，但实践中你会发现启动之后紧接着报Handler相关类缺失，所以一次性把handler也加上更省事。版本号一定要写具体值，不要留空，否则 Maven 会给你一个从超级 POM 继承来的版本，那个版本通常很老，而且会和其他 netty 模块不一致。

修复之后一定要做三步验证：跑mvn dependency:tree -Dincludes=io.netty确认只有一套版本；跑mvn clean package后unzip -l确认 jar 里有 netty；最后本地java -jar起一次，确认真的能跑。跳过任何一步都可能在上线时才暴露问题。

4.2 Spring Boot fat jar 的嵌套规则

Spring Boot 的 fat jar 用的是org.springframework.boot.loader.JarLauncher，它会把BOOT-INF/lib下的每个 jar 做成嵌套条目，用一个自定义的LaunchedURLClassLoader加载。这个机制对大多数情况透明，但有几个点需要注意。

一是spring-boot-maven-plugin的includes/excludes配置。如果你的pom里配置了只包含某些 groupId，那 netty 很可能被排除了。这个配置在聚合项目里很常见，目的是减小包体积，但很容易误伤。

二是layout配置。如果是LAYOUT_ZIP或者LAYOUT_NONE，类加载行为和默认的LAYOUT_JAR不同。

三是如果同时用了 shade 插件和 Boot 插件，两者可能打架。Boot 插件在repackage阶段会重写 jar，shade 在package阶段就完成了打包，执行顺序不对会导致产物结构混乱。这种项目的排查方法很直接：unzip -l看结构，如果既看到BOOT-INF/lib又看到平铺在根目录的io/netty/...，那说明两个插件都在干活，得去掉一个。

4.3 war 包部署到外部容器

war 包装到外部容器时，netty 应该在WEB-INF/lib下。如果providedscope 的依赖里有 netty，它不会进WEB-INF/lib，容器也不一定提供，那就必炸。

还有一种情况是容器的类加载委托策略。默认是“先父后子”，也就是先找容器的公共库，再找WEB-INF/lib。如果容器自带了一个老版本的 netty，你可能在加载时拿到的是老版本，从而出现NoSuchMethodError而不是NoClassDefFoundError。想强制优先用应用自己的版本，可以在META-INF/context.xml里配置delegate="false"，或者在容器配置里调整委托顺序。具体配置项各容器不同，实际动手时以当前容器版本的官方文档为准。

修复后在 war 包里确认：

unzip -l your-app.war | grep "WEB-INF/lib" | grep -i netty

4.4 版本统一的正确姿势：BOM 与依赖收敛

前面所有方案都是“哪里漏了补哪里”，但真正让这类问题不再反复出现的方法，是在项目层面把 netty 的版本统一起来。Netty 官方提供了 BOM，可以直接导入：

<dependencyManagement> <dependencies> <dependency> <groupId>io.netty</groupId> <artifactId>netty-bom</artifactId> <version>4.1.100.Final</version> <type>pom</type> <scope>import</scope> </dependency> </dependencies> </dependencyManagement>

导入之后，所有io.netty下的模块都不需要写版本号了，且会被强制统一到 BOM 声明的版本。这一招在多模块项目里价值极大，因为它把“版本仲裁”从隐式规则变成了显式约束。

如果你已经在用 Spring Boot 的 parent，注意 Boot 也管理了一部分 netty 版本。这时候两个 BOM 可能冲突，规则是后声明的优先（在dependencyManagement里）。实际做法是把 netty-bom 放在 Boot parent 之后导入，或者在属性里覆盖 Boot 的 netty 版本属性（Boot 通常用netty.version这个属性名）。改完之后务必用dependency:tree验证最终生效版本，别改完不验证。

5. 一次完整的排查实录

5.1 现象：本地正常，测试环境起不来

前段时间遇到一个典型案例。某个模拟项目在本地 IDEA 里跑得好好的，推到测试环境用java -jar启动就报NoClassDefFoundError: io/netty/channel/EventLoopGroup。这个项目的依赖里有一个 RPC 客户端，Netty 是通过它传递进来的。第一反应当然是去看依赖树，mvn dependency:tree -Dincludes=io.netty输出了三行，netty-transport、netty-common、netty-buffer都在，版本都是 4.1.x，看起来没毛病。

这时候一个容易犯的错误是“既然有依赖，那可能是版本不对，换个版本试试”。我见过不少人开始挨个试版本，试了半小时毫无进展。正确的做法是停下来，问自己：依赖树证明的是“声明了”，那“打进去了吗”？

5.2 转折点：把产物拆开看

于是执行unzip -l target/xxx.jar | grep -i netty，结果BOOT-INF/lib下面只有一个netty-common，netty-transport不在。到这里问题性质就变了：不是版本问题，是打包时被排除了。

继续翻 POM，发现spring-boot-maven-plugin配置了这样一段：

<configuration> <excludes> <exclude> <groupId>io.netty</groupId> <artifactId>netty-transport</artifactId> </exclude> </excludes> </configuration>

这个排除是从上一个版本遗留下来的，当时为了减少包体积，把认为“用不到”的模块排掉了。后来代码里新增了一个功能，直接用了EventLoopGroup，本地因为 IDE 不受这个配置影响所以能跑，打包之后就废了。

5.3 修复与验证

修复动作很简单，删掉那个 exclude。但为了防止再出问题，加了两道保险：一是把项目里直接 import 的 netty 类所在模块显式声明在依赖里，不再依赖 RPC 客户端传递；二是在构建流程里加了一条检查命令，构建完成后 grep 一下产物里有没有关键的类。

验证顺序是：mvn clean package打新包、unzip -l确认BOOT-INF/lib/netty-transport-*.jar存在、解出这个嵌套 jar 用jar tf确认io/netty/channel/EventLoopGroup.class存在、最后用java -jar起服务并观察启动日志里的端口监听信息。

5.4 复盘：哪一步本来可以更早做

这次排查从报错到定位大概花了二十分钟，其中有一半时间浪费在“看依赖树觉得没问题”的自我怀疑上。事后复盘，最该更早做的是把“依赖声明”和“产物内容”这两件事分开验证。依赖树只是声明层面的视图，任何打包插件、profile、scope 配置都能让它和最终产物产生偏差。

第二个教训是“本地能跑”这个信号的价值被高估了。IDE 的类路径构造和命令行、和容器环境都不一样，本地能跑只能证明代码逻辑没问题，证明不了产物完整。凡是涉及打包的问题，一定要在接近生产的环境里验证。

第三个教训是关于那个遗留的 exclude。这类配置往往会“活”很久，因为没人记得它为什么存在。我的做法是给每个 exclude 加一行注释说明原因和加的时间，虽然土，但真的能省事。

6. 让这个错少出现的几个工程习惯

6.1 在构建流程里加一条类存在性检查

最朴素也最有效的办法，是在 CI 里加一步验证。比如构建完之后跑一段脚本，检查产物里是否包含关键类：

if ! unzip -l target/app.jar | grep -q "netty-transport"; then echo "netty-transport missing in artifact" exit 1 fi

这段脚本可以按需扩展成检查多个关键依赖。它的价值在于把“运行期才发现”提前到“构建期发现”，成本极低，收益很高。如果团队用 Gradle，可以写成自定义 task 挂到check生命周期上。

更进阶一点的方案是用jdeps做静态分析，它能列出产物的所有依赖关系：

jdeps --multi-release 17 -summary target/app.jar

不过jdeps对 fat jar 的嵌套结构支持有限，实际用起来还是unzip+jar tf的组合更直接。

6.2 启动自检与快速失败

有些团队会在应用启动的最开始加一段自检代码，主动Class.forName几个关键类，失败就立刻退出并打印清晰的提示。这比让错误在业务初始化到一半时爆出来要好得多，因为那时候可能已经建立了一半的连接、注册了一半的监听器，清理起来更麻烦。

private static void assertNettyPresent() { try { Class.forName("io.netty.channel.EventLoopGroup"); } catch (ClassNotFoundException e) { throw new IllegalStateException( "Netty transport missing, check dependency and packaging config", e); } }

这段代码放在main方法的第一行。看起来有点笨，但它把“隐式失败”变成了“显式失败”，日志里能直接看到原因，省掉了后续的排查时间。尤其是那种“跑了几分钟才报错”的服务，提前失败的价值更大。

6.3 依赖收敛要当成日常维护而不是救火

最后说一个长期习惯。netty 这类被大量框架间接依赖的库，版本漂移几乎是必然的。我的做法是每个季度跑一次全量依赖树，看看有没有同一个 groupId 下的不同版本，把结果记录到项目的技术债清单里。具体命令：

mvn dependency:tree -Dverbose -Dincludes=io.netty,com.fasterxml.jackson,org.slf4j

把这类“高频冲突库”列成一张表，每次大版本升级时对着表检查一遍。听起来是额外工作，但比起线上炸了之后再花两小时定位，这点成本可以忽略不计。

还有一条经验：不要用netty-all。它看起来省事，实际上会让你对依赖关系的感知变钝，出了问题也不知道缺的是哪个模块。按模块引入虽然多几行 XML，但排查时的清晰度完全不是一个量级。我在几个项目里推行过这个做法，后续遇到 netty 相关问题的平均定位时间明显下降。

另外补充一个容易被忽视的点：本地开发时，可以定期跑一次mvn clean package而不是只在 IDE 里点运行。很多人习惯一天到晚在 IDE 里跑，直到提测才打一次包，结果问题全堆在最后暴露。把打包频率提高，让“IDE 能跑”和“包能跑”这两件事尽早对齐，能提前发现大量配置类问题。