1. 项目概述：Flink SQL运行时包冲突异常的本质与典型表现

“flink sql包冲突异常”——这六个字，是过去三年我在某数据中台团队做实时计算平台维护时，被叫去救火频率最高的关键词之一。它不像“任务OOM”那样直观，也不像“checkpoint失败”那样有明确日志路径，而是一种典型的“表面平静、内里崩坏”的隐性故障：SQL作业提交成功，任务看似正常启动，但一写入数据就报错，错误堆栈里反复出现NoSuchMethodError、NoClassDefFoundError、LinkageError，甚至更隐蔽的ClassCastException——比如把org.apache.flink.table.api.bridge.java.StreamTableEnvironment强转成自己jar里的同名类却失败。这些都不是业务逻辑问题，而是JVM在类加载阶段就已埋下的雷。

这类异常的核心，从来不是Flink SQL语法写错了，而是类加载器（ClassLoader）在多层依赖嵌套下对同一类的不同版本产生了不可调和的认知分歧。Flink本身采用“parent-first + plugin isolation”混合类加载策略：系统核心类（如flink-runtime、flink-core）由Flink自身的FlinkClassLoader优先加载，确保框架稳定性；而用户代码（包括你写的UDF、自定义Connector、甚至某些第三方依赖）则被隔离到UserCodeClassLoader中，本意是避免污染。但问题恰恰出在这个“隔离”上——当你的SQL作业依赖了某个外部库（比如hadoop-client:3.3.4），而Flink发行版自带的却是hadoop-client:3.2.2，且两者都导出了org.apache.hadoop.conf.Configuration这个类时，JVM就会陷入“该信谁”的困境：StreamTableEnvironment在Flink系统类加载器里加载，它内部调用的Configuration期望是3.2.2版本的方法签名；而你的UDF在用户类加载器里加载，它引用的Configuration却是3.3.4版本，方法已被重命名或参数变更。此时哪怕只有一行config.set("key", "value")，也会在运行时炸开。

我见过最典型的三个爆发场景：一是用Flink 1.16+连接StarRocks 2.5+，StarRocks官方JDBC驱动里偷偷打包了旧版netty-all，和Flink 1.16自带的netty-transport4.1.90.Final冲突；二是自定义Kafka Sink里引入了kafka-clients:3.4.0，而Flink 1.15默认带的是3.3.2，ConsumerRecord构造函数参数顺序微调导致NoSuchMethodError；三是用HiveCatalog时，本地IDE里hive-exec版本是3.1.3，集群YARN上Hive服务端是2.3.9，SerDe序列化器在反序列化时因ObjectInspector实现类不兼容直接抛LinkageError。这些问题不会在sql-client.sh本地预编译时报错，也不会在Web UI提交时校验失败，它们只在第一个数据流经UDF、第一个元数据从Catalog读取、第一个消息被Kafka Producer发送的瞬间才暴露——这种延迟性，让排查成本陡增。

所以，如果你正面对一个“flink sql包冲突异常”，请立刻放弃“改SQL重试”的思路。这不是数据问题，也不是配置问题，而是一次精准的Java类加载环境诊断任务。你需要的不是调试器，而是一把能切开Flink类加载树的解剖刀。接下来我会带你从设计原理、关键细节、实操步骤到排障技巧，一层层剥开这个看似玄学、实则有迹可循的故障迷雾。无论你是刚接触Flink SQL的ETL工程师，还是负责平台稳定性的SRE，这套方法论都能让你在30分钟内定位到冲突根源，而不是花半天时间在Stack Overflow里大海捞针。

2. 内容整体设计与思路拆解：为什么必须放弃“删jar大法”，转向类加载链路分析

解决“flink sql包冲突异常”，最诱人的捷径是“删jar大法”：把作业jar包里所有疑似冲突的第三方依赖全删掉，只留业务代码，然后靠Flink集群自带的依赖运行。我试过，也推荐给团队新人用过——结果是，70%的case当场解决，剩下30%的case要么任务根本起不来（缺slf4j-log4j12桥接器），要么跑两小时后突然OOM（因为删掉了rocksdbjni的native lib适配包）。这说明，“删jar”只是在掩盖问题，而非解决问题。真正可靠的方案，必须建立在对Flink类加载机制的深度理解之上，并围绕三个核心原则展开：可复现、可追溯、可隔离。

2.1 核心设计原则：从“被动灭火”转向“主动布防”

第一原则：可复现。任何线上故障，必须能在本地或测试环境100%复现。Flink SQL的包冲突具有强环境依赖性——同样的jar包，在Standalone模式下可能正常，在YARN Session模式下必崩，原因在于YARN会额外注入Hadoop相关jar到classpath。因此，我们的设计起点不是“怎么修”，而是“怎么稳稳地把它搞崩”。具体做法是：将生产环境的Flink发行版（如flink-1.17.1-bin-scala_2.12.tgz）、YARN配置（yarn-site.xml）、Hive Metastore连接串、甚至Kafka Broker地址，全部同步到本地Docker环境；用docker-compose拉起一个精简版YARN集群（含ResourceManager、NodeManager）和Flink JobManager/TaskManager；再把出问题的SQL作业jar包丢进去执行。只有复现了，后续所有分析才有意义。我曾为定位一个AvroSchemaConverter冲突，专门写了脚本自动下载Flink各版本的lib/目录并比对MANIFEST.MF里的Export-Package声明，耗时两天，但换来的是此后所有Avro相关作业的零冲突。

第二原则：可追溯。必须能回答“这个类到底从哪个jar加载的？”这个问题。Flink默认不打印类加载路径，但JVM提供了-verbose:class参数，它会在控制台输出每一行[Loaded xxx from yyy]。问题是，Flink的log4j配置会把这类输出吞掉，且海量日志根本无法人工筛选。我们的解决方案是：在conf/log4j-console.properties里新增log4j.logger.org.apache.flink=DEBUG，同时在conf/flink-conf.yaml中设置env.java.opts: "-verbose:class -XX:+PrintGCDetails"，再配合grep "Loaded org.apache.hadoop.conf.Configuration"过滤。更进一步，我们开发了一个轻量级Agent（基于Java Instrumentation API），在premain阶段注册ClassFileTransformer，当检测到目标类（如Configuration）被加载时，自动打印其ProtectionDomain.getCodeSource().getLocation()，精确到jar包的绝对路径和SHA256哈希值。这个Agent只有200行代码，却让我们在一次跨集群迁移中，3分钟内锁定了冲突源是某运维同事手动拷贝的hadoop-common-2.8.5.jar。

第三原则：可隔离。不是所有依赖都需要“削足适履”去匹配Flink版本。Flink 1.15+引入了classloader.resolve-order: parent-first（默认）和child-first两种策略，后者允许用户jar优先于Flink系统jar加载类。但盲目设为child-first风险极大——一旦你的jar里打包了flink-table-api-java，就会覆盖Flink自身的TableEnvironment，导致整个SQL解析器崩溃。因此，我们采用“最小化覆盖”策略：只对明确冲突的包启用child-first，其余保持parent-first。具体操作是在pom.xml中用maven-shade-plugin的relocations功能，将冲突jar的包路径重命名（如com.starrocks.jdbc→shaded.com.starrocks.jdbc），并在UDF代码里用ShadedStarRocksSink替代原生类。这个方案牺牲了一点开发便利性，但换来的是100%的版本解耦。某次升级StarRocks JDBC驱动到3.2.0时，我们就是靠这个重命名方案，零停机完成了切换。

2.2 方案选型背后的硬核权衡：为什么不用Flink的“provided” scope？

很多教程会建议：“把Flink依赖设为<scope>provided</scope>，让集群提供”。这听起来很美，但实际踩坑无数。provided只解决编译期依赖，不解决运行时类加载冲突。举个真实案例：某团队将flink-connector-kafka设为provided，本地IDE里用kafka-clients:3.3.2，集群里Flink自带3.2.1。作业提交后，KafkaSink类由Flink加载，但它内部反射调用KafkaProducer时，JVM发现KafkaProducer的send()方法在3.2.1里是send(ProducerRecord, Callback)，而在3.3.2里是send(ProducerRecord, Callback, long)，于是抛出NoSuchMethodError。provided没阻止这个错误，因为它没管运行时的类版本一致性。

我们最终选择“Shade + Relocate”方案，理由很实在：

• 确定性：重命名后的类与Flink原生类完全隔离，不存在任何加载竞争；
• 可审计：shaded前缀让代码里所有外部依赖一目了然，Code Review时能快速识别风险点；
• 向后兼容：即使Flink未来升级到1.18，只要shaded包没变，业务代码无需修改；
• 调试友好：出错时堆栈里直接显示shaded.com.xxx，一眼知道是哪个依赖的问题，不用再猜“这个Configuration到底是Hadoop的还是Flink的”。

当然，Shade也有代价：jar包体积增大（一个hadoop-clientshade后增加8MB），首次加载类稍慢（需解压重命名）。但我们测算过，对TB级实时作业而言，这点开销远低于因包冲突导致的每小时一次的重启成本。所以，这不是技术洁癖，而是经过成本收益比计算后的理性选择。

3. 核心细节解析与实操要点：从错误日志到冲突定位的七步穿透法

当你看到java.lang.NoSuchMethodError: org.apache.kafka.clients.producer.KafkaProducer.send(Lorg/apache/kafka/clients/producer/ProducerRecord;Lorg/apache/kafka/callbacks/Callback;)Lorg/apache/kafka/clients/Future;这样的错误时，别急着改代码。这是JVM在告诉你：“我加载了A版本的KafkaProducer类，但它期望调用B版本的方法”。我们的任务，就是顺着这条线索，把A和B揪出来。以下是我在上百次实战中提炼出的“七步穿透法”，每一步都附带命令、参数和避坑提示。

3.1 第一步：锁定报错类与方法签名（必须精确到字节码）

错误日志里的NoSuchMethodError信息是黄金入口，但很多人忽略了一个关键细节：方法签名（method signature）必须完整复制，包括参数类型和返回值。上面例子中的send(Lorg/apache/kafka/clients/producer/ProducerRecord;Lorg/apache/kafka/callbacks/Callback;)Lorg/apache/kafka/clients/Future;，括号里的L表示对象类型，;是分隔符，Lorg/apache/kafka/clients/Future;是返回值。如果只复制send(ProducerRecord, Callback)，你会在javap反编译时找不到对应方法，因为字节码里没有泛型擦除后的“友好名称”。

实操命令：

# 进入Flink集群的lib目录，找到疑似jar cd $FLINK_HOME/lib # 查找所有包含KafkaProducer的jar（注意通配符） find . -name "*kafka*" -type f | xargs -I {} sh -c 'echo "=== {} ==="; jar -tf {} | grep -i "KafkaProducer.class"' # 对每个jar，用javap反编译并搜索完整方法签名 jar -xvf ./flink-connector-kafka-1.17.1.jar org/apache/kafka/clients/producer/KafkaProducer.class 2>/dev/null javap -cp . org.apache.kafka.clients.producer.KafkaProducer | grep -A 5 "send"

提示：javap输出的方法签名是Java源码风格（如public Future<RecordMetadata> send(ProducerRecord<K,V>, Callback)），而错误日志里是JVM字节码风格。两者等价，但搜索时务必用字节码风格，因为javap -s参数可直接输出签名：javap -s -cp . org.apache.kafka.clients.producer.KafkaProducer | grep "send"。

3.2 第二步：确认Flink发行版自带的依赖版本（查MANIFEST.MF）

Flink不是黑盒，它的lib/目录下每个jar包的META-INF/MANIFEST.MF文件里，都记录了Implementation-Version和Bundle-Version。这是判断“Flink官方带了什么版本”的唯一权威依据。

实操命令：

# 解压Flink发行版，进入lib目录 tar -xzf flink-1.17.1-bin-scala_2.12.tgz cd flink-1.17.1/lib # 批量提取所有kafka相关jar的版本信息 for jar in $(find . -name "*kafka*" -type f); do echo "=== $jar ===" unzip -p "$jar" META-INF/MANIFEST.MF 2>/dev/null | grep -E "(Implementation-Version|Bundle-Version|Specification-Version)" done | grep -v "^$"

注意：有些jar（如flink-sql-connector-kafka-1.17.1.jar）的MANIFEST.MF里不写版本，这时要看其pom.xml（如果jar里打包了的话）或Flink官网的Maven仓库页面。我们团队维护了一个内部Wiki，表格化记录了Flink 1.14~1.17各版本lib/目录下所有jar的精确版本，更新频率为每次Flink小版本发布。

3.3 第三步：检查用户jar包的依赖树（mvn dependency:tree是基础）

你的作业jar包里打了什么？光看pom.xml不够，因为传递性依赖（transitive dependency）可能悄悄引入冲突版本。mvn dependency:tree是第一步，但默认输出太冗长，需加过滤。

实操命令：

# 在你的项目根目录执行（确保已配置好Flink的maven profile） mvn dependency:tree -Dincludes=org.apache.kafka:kafka-clients -Dverbose -DoutputFile=dep-tree.txt # 或用grep精简 mvn dependency:tree | grep -E "(kafka-clients|flink-connector-kafka)" | grep -v "omitted for cycle"

关键技巧：-Dverbose参数会显示被省略的重复依赖，-Dincludes指定只看目标groupId:artifactId。如果输出里出现kafka-clients:3.4.0（你的项目引入）和kafka-clients:3.3.2（Flink传递引入），冲突已坐实。

3.4 第四步：运行时类加载路径取证（-verbose:class + grep）

这是最硬核的一步，也是区分“理论分析”和“实战定位”的分水岭。必须在Flink TaskManager进程启动时，就注入JVM参数捕获类加载源头。

实操步骤：

1. 修改conf/flink-conf.yaml，添加：

   env.java.opts.taskmanager: "-verbose:class -XX:+PrintGCDetails -Xloggc:/tmp/tm-gc.log"

2. 启动Flink集群（Standalone或YARN）；
3. 提交你的SQL作业；
4. 等待报错后，立即执行：

   # 查找TaskManager日志（通常在log/目录下，按时间戳排序） ls -t $FLINK_HOME/log/flink-*-taskexecutor-*.out | head -1 # 搜索报错类的加载路径 grep "Loaded org.apache.kafka.clients.producer.KafkaProducer" $FLINK_HOME/log/flink-*-taskexecutor-*.out

注意：-verbose:class输出极多（单个TaskManager启动可超10万行），务必用grep精准过滤。如果日志里出现两行Loaded KafkaProducer from .../flink-connector-kafka-1.17.1.jar和Loaded KafkaProducer from /path/to/your-job.jar，说明类被加载了两次，冲突铁证。

3.5 第五步：验证类加载器层级（jstack + JMX）

有时-verbose:class只显示“Loaded from”，但没说“被谁加载”。这时需要看线程栈和JMX信息。Flink TaskManager的ClassLoader是FlinkUserCodeClassLoader，它有一个parent指向FlinkClassLoader。我们可以通过jstack抓取线程快照，再结合JMX的java.lang:type=Runtime属性，确认当前线程的上下文类加载器。

实操命令：

# 获取TaskManager的PID（假设为12345） jstack 12345 | grep -A 10 "FlinkUserCodeClassLoader" # 或用JMX工具（如jconsole）连接到TaskManager的JMX端口（默认8081），查看Runtime的systemProperties # 关键属性：java.class.path（显示classpath顺序），sun.boot.class.path（启动类路径）

实测心得：在YARN模式下，java.class.path里会先列出YARN注入的Hadoop jar，再是Flink的lib/，最后才是你的jar。如果kafka-clients-3.4.0.jar出现在Hadoop jar之后、Flink jar之前，那它大概率会被FlinkUserCodeClassLoader优先加载，从而覆盖Flink自身的3.3.2版本。

3.6 第六步：字节码比对（javap -v 看常量池）

当两个版本的类方法签名看似相同，但依然报错时，问题可能出在常量池（Constant Pool）。比如kafka-clients:3.3.2里send()方法的Code属性里，LineNumberTable指向第123行；而3.4.0里指向第125行。JVM在链接时会校验这些元数据，不一致就抛LinkageError。

实操命令：

# 分别反编译两个版本的KafkaProducer.class javap -v -cp kafka-clients-3.3.2.jar org.apache.kafka.clients.producer.KafkaProducer > v332.txt javap -v -cp kafka-clients-3.4.0.jar org.apache.kafka.clients.producer.KafkaProducer > v340.txt # 比对常量池（重点关注#123、#125等行号） diff v332.txt v340.txt | grep -E "(Constant|LineNumberTable)"

避坑提示：不要用IDE的“Compare With Each Other”功能，它会忽略字节码层面的差异。javap -v输出的Constant pool段落，每一行开头的#数字是常量索引，必须逐行比对。

3.7 第七步：构建最小复现工程（排除干扰项）

以上六步做完，如果还不能100%确定，就进入终极手段：构建一个只有5行SQL和1个UDF的最小工程，打包后单独测试。这是为了排除“配置污染”——比如flink-conf.yaml里误配了classloader.parent-first-patterns: org.apache.kafka.*，导致Kafka类被强制父加载，反而引发新冲突。

最小工程结构：

pom.xml（只含flink-table-api、flink-connector-kafka、kafka-clients三个依赖） src/main/sql/test.sql（INSERT INTO sink SELECT * FROM source） src/main/java/MyUdf.java（一个空的ScalarFunction）

经验总结：70%的“疑难杂症”在最小工程里会消失，说明原作业里有其他隐藏依赖（如某个Log4j Appender间接引入了旧版slf4j-api）。这时，用mvn dependency:tree -Dverbose重新扫一遍，往往能发现那个被忽略的“幽灵依赖”。

4. 实操过程与核心环节实现：从Shade重命名到Flink配置的全流程落地

定位到冲突只是开始，真正的挑战是如何安全、可持续地修复它。我们团队沉淀出一套标准化流程，覆盖从Maven构建、Flink配置到上线验证的全链路。以下以“解决StarRocks JDBC驱动与Flink Netty冲突”为例，展示完整实操。

4.1 Maven Shade配置：不只是打包，更是类空间切割

我们的pom.xml中，maven-shade-plugin的配置不是简单地<shadedArtifactAttached>true</shadedArtifactAttached>，而是精密的“类空间手术”：

<plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-shade-plugin</artifactId> <version>3.4.1</version> <executions> <execution> <phase>package</phase> <goals> <goal>shade</goal> </goals> <configuration> <!-- 关键：排除所有Flink已提供的依赖，避免重复 --> <filters> <filter> <artifact>*:*</artifact> <excludes> <exclude>META-INF/*.SF</exclude> <exclude>META-INF/*.DSA</exclude> <exclude>META-INF/*.RSA</exclude> </excludes> </filter> </filters> <!-- 核心：重命名StarRocks JDBC及其传递依赖 --> <relocations> <relocation> <pattern>com.starrocks</pattern> <shadedPattern>shaded.com.starrocks</shadedPattern> </relocation> <relocation> <pattern>io.netty</pattern> <shadedPattern>shaded.io.netty</shadedPattern> </relocation> <relocation> <pattern>org.slf4j</pattern> <shadedPattern>shaded.org.slf4j</shadedPattern> </relocation> </relocations> <!-- 关键：合并Service文件，否则SPI机制失效 --> <transformers> <transformer implementation="org.apache.maven.plugins.shade.resource.ServicesResourceTransformer"/> <transformer implementation="org.apache.maven.plugins.shade.resource.ManifestResourceTransformer"> <mainClass>com.example.MySqlJob</mainClass> </transformer> </transformers> </configuration> </execution> </executions> </plugin>

原理说明：<relocation>标签不是简单的字符串替换，而是Shade插件在字节码层面重写CONSTANT_Class_info常量池项。当shaded.com.starrocks.jdbc.StarRocksSink类被加载时，它内部所有对io.netty.channel.Channel的引用，都会被自动改为shaded.io.netty.channel.Channel。这样，即使Flink系统类加载器里有io.netty.channel.Channel，它和shaded.io.netty.channel.Channel在JVM眼里是两个完全无关的类，彻底消除冲突。

4.2 Flink配置优化：让类加载器“各司其职”

Shade解决了“我的代码”，但Flink自身的类加载策略仍需微调，以防意外覆盖。我们在conf/flink-conf.yaml中做了三处关键配置：

# 1. 明确指定parent-first的包模式，避免StarRocks的shaded类被误判 classloader.parent-first-patterns: - org.apache.flink. - scala. - org.apache.logging. - shaded.com.starrocks. # 2. 禁用Flink自动扫描jar包里的Service，防止加载到shaded的SPI实现 classloader.checking-classloader-configuration: false # 3. 为TaskManager单独配置JVM参数，启用类加载调试 env.java.opts.taskmanager: "-XX:+TraceClassLoading -XX:+TraceClassUnloading -Xlog:gc*:file=/tmp/tm-gc.log:time"

注意：classloader.parent-first-patterns里必须包含shaded.com.starrocks.（末尾的点很重要！），否则shaded.com.starrocks.jdbc.Driver会被FlinkUserCodeClassLoader加载，而它依赖的shaded.io.netty.channel.Channel又可能被FlinkClassLoader加载，再次引发冲突。这个点位，我们踩了三次坑才确认。

4.3 SQL作业代码改造：UDF与Connector的无感接入

Shade后，代码里所有StarRocks相关的类引用，必须同步更新为shaded前缀。这不是简单的IDE全局替换，而是有策略的：

• Connector定义：在SQL DDL中，connector类型不变，仍是starrocks，因为这是Flink SQL Parser识别的关键字，与底层实现无关；
• UDF实现：ScalarFunction子类里，所有StarRocks JDBC的import语句，必须改为shaded.com.starrocks.jdbc.*；
• 配置传递：StarRocksSink的构造参数（如jdbc-url、load-url）不变，但内部创建shaded.com.starrocks.jdbc.Driver实例的逻辑，要封装在shaded包里。

示例代码片段：

// 原始（冲突版） import com.starrocks.jdbc.StarRocksSink; public class MyStarRocksSink extends StarRocksSink { public MyStarRocksSink(String jdbcUrl) { super(jdbcUrl); // 调用父类，但父类里new Driver()会加载非shaded类 } } // 改造后（安全版） import shaded.com.starrocks.jdbc.StarRocksSink; public class MyShadedStarRocksSink extends StarRocksSink { public MyShadedStarRocksSink(String jdbcUrl) { // 构造函数里不直接new，而是通过shaded包里的工厂类 super(jdbcUrl, ShadedStarRocksDriverFactory.create()); } }

实操心得：我们把所有shaded相关的工厂类、工具类，统一放在com.example.shaded包下，与业务代码隔离。这样，业务同学只需关注SQL逻辑，shaded细节由平台组维护，降低使用门槛。

4.4 上线验证 checklist：从本地到生产的五级放行

一个修复方案，必须经过严格验证才能上线。我们制定了五级checklist，每级失败即回退：

关键数据：L4压测时，我们发现shaded.io.netty的EpollEventLoopGroup在高并发下比原生NioEventLoopGroup性能低12%，于是追加了-Dio.netty.transport.noNative=trueJVM参数，强制回退到NIO模式。这说明，Shade不是万能的，必须结合真实场景调优。

5. 常见问题与排查技巧实录：那些文档里不会写的“血泪经验”

在解决“flink sql包冲突异常”的过程中，有些问题高频出现，但官方文档几乎从不提及。我把它们整理成速查表，并附上我们团队的真实应对记录。这些不是理论推演，而是凌晨三点在服务器前敲下的命令和笔记。

5.1 常见问题速查表

5.2 独家避坑技巧：那些“只可意会”的细节

技巧一：用-XX:+TraceClassLoading替代-verbose:class
-verbose:class只输出“Loaded”，而-XX:+TraceClassLoading会输出“Loaded X from Y by Z”，其中Z是类加载器的hashcode。我们写了个Python脚本，自动解析这个输出，生成类加载器拓扑图：

# parse_class_loading.py import re for line in open("/tmp/tm-class.log"): m = re.match(r"(.*) class (.*) from (.*) by (.*)", line) if m: timestamp, cls, jar, loader = m.groups() print(f"{cls} -> {loader} -> {jar}")

运行后，能清晰看到shaded.com.starrocks.jdbc.Driver被FlinkUserCodeClassLoader@12345加载，而io.netty.channel.Channel被FlinkClassLoader@67890加载，证明隔离成功。

技巧二：在UDF里主动触发类加载，提前暴露问题
不要等数据进来才报错。在UDF的open()方法里，加一行“探针代码”：

public void open(Configuration parameters) throws Exception { // 主动加载shaded类，如果失败，任务在open阶段就挂，而不是在processElement时挂 try { Class.forName("shaded.com.starrocks.jdbc.StarRocksSink"); } catch (ClassNotFoundException e) { throw new RuntimeException("shaded StarRocks classes not found!", e); } }

这让我们在CI流水线里，就能用mvn test捕获90%的Shade配置错误。

技巧三：为每个shaded包生成独立的version.txt
在maven-shade-plugin的<transformers>里，添加一个自定义的ResourceTransformer，在jar包根目录生成shaded-com-starrocks-version.txt，内容