兄弟，你碰到的这个情况真的太典型了——本地跑主类一切顺畅，一打包把Spark依赖塞进去就崩，拿掉Spark包又正常，核心原因其实是Spark的架构和依赖特性，天生就不适合被打包进你的独立Jar包。

Spark作为分布式计算框架，它的核心依赖（比如Hadoop组件、Netty、序列化库这些）和普通Java应用的依赖很容易撞版本；而且Spark运行时不管是本地模式还是集群模式，都有自己专属的类加载机制，你把它的包硬塞进自己的Jar里，直接就把这套机制打乱了，不报错才怪。

下面给你几个落地的解决办法，按靠谱程度排序：

1. 把Spark依赖设为“运行时提供”（最推荐） #

虽然你现在没用到Maven，但其实用构建工具管依赖会省心很多。如果换成Maven的话，把Spark相关依赖的scope改成provided，这样打包的时候就不会把Spark的Jar包打进你的Artifact里——因为不管是本地跑Spark还是集群模式，Spark本身的运行环境都会提供这些依赖：

<dependency>
    <groupId>org.apache.spark</groupId>
    <artifactId>spark-core_2.12</artifactId>
    <version>你的Spark版本号</version>
    <scope>provided</scope>
</dependency>
<!-- 要是用到spark-sql、spark-streaming这些模块，都照这个格式改scope -->

要是你坚持用IntelliJ的Artifact打包，那就在Artifact配置界面里，找到所有Spark相关的依赖项，右键选Exclude，这样打包的时候就自动跳过这些依赖了。

2. 排查并解决依赖冲突（不推荐硬打包的情况下用） #

如果你非要把Spark依赖塞进Jar里（真心不建议这么干），那得先揪出冲突的依赖。你可以用IntelliJ自带的Dependency Analyzer工具（路径是File > Project Structure > Modules > Dependencies，找右上角的Analyzer按钮），看看有没有和Spark依赖重复的库——比如不同版本的Guava、Netty，这些都是重灾区。找到冲突后，要么在依赖里手动排除掉多余的版本，要么调整依赖顺序让Spark的版本优先。

3. 打“瘦Jar”+ 外置依赖 #

还有一种方式是只打包你自己写的代码（也就是所谓的瘦Jar），然后把Spark的所有依赖单独放在一个lib文件夹里，运行的时候用下面的命令启动：

java -cp "你的瘦Jar包路径:lib/*" 你的主类全路径

这样既避免了打包Spark依赖带来的冲突，又能保证运行时能找到所有需要的依赖。

最后再给你补个小知识点：为啥本地跑正常？因为IntelliJ的类加载器会帮你处理好Spark的依赖隔离，不会让不同版本的库互相干扰；但打包成独立Jar后，所有类都在同一个类加载器下，之前被隐藏的冲突就直接爆发了。

内容的提问来源于stack exchange，提问作者shazamsixfive