显然，我不希望我的最终可执行jar文件包含Log4J jar。
不一定是这样。还有另一种方法。您可以为代码使用slf 4j+任何日志后端的混合，并继续为有问题的依赖项使用log4j。这样您将最终得到两组日志文件。但这并不是世界末日...
如果您这样做是为了处理log4j漏洞，则可以通过其他方式修复或缓解这些漏洞，具体取决于您讨论的是log4j 1.2.x还是log4j 2.x。详细信息请参见https://logging.apache.org/log4j/2.x/security.html
...所以我当然可以在我的项目pom文件中添加一个排除项，但这不是一个很大的风险吗？因为理论上第三方代码可能会使用Log4J的一些方面，而这些方面在Log4J-over-slf 4j实现中没有涉及，然后您将面临运行时异常的风险，因为所需的二进制文件不在类路径中。
是的。这是有风险的。但是你应该能够通过测试你的代码来解决这个问题。只有当第三方库 * 实际上 * 使用了桥代码没有实现的log4j API方法时，这个风险才会成为一个真实的的问题。如果它确实存在，当你的代码试图使用第三方库的 * 受影响的部分 * 时，你应该很快就会看到类加载器错误：

• 在库代码基1中可能根本不存在该问题。
• 该问题可能与应用程序不使用的库部分无关。

无论哪种方式...如果您彻底测试您的应用程序，您应该能够判断这是一个 * 真实的 * 的问题...还是您只是担心一个假设的问题。
如果事实证明桥接方法不起作用，那么您有许多替代方法：
1.将依赖项更新为使用slf 4j、log4j 2或其他可接受的库的较新版本。
1.激励图书馆供应商/销售商解决其遗留日志记录问题;例如，提供付款，或威胁取消您的支持合同，或...
1.查看是否可以分叉库并将其移植到更现代的日志记录解决方案中。
1.看看是否可以派生log4j-over-slf 4j桥库并添加对缺少的log4j API的支持（可行性取决于缺少什么以及第三方库需要什么）。
1.抛弃依赖，寻找更好的东西。这样做往往会有其他长期的好处。
1.雇佣一个有技能 * 和信心 * 的承包商来为你 * 解决问题 *。
1 -通过对第三方库源代码或其.class文件进行取证检查，查看其引用了哪些日志记录类和方法，可以确定这一点。