插件兼容性冲突不会静默处理，所谓“静默”实为错误被吞掉、日志被忽略或加载失败后继续执行导致的假象；真正风险是运行时出现ClassNotFoundException、NoClassDefFoundError等异常，而根源早已埋在类路径或模块路径中。
插件兼容性冲突不会静默处理——所谓“静默”，其实是错误被吞掉、日志被忽略、或加载失败后继续执行导致的假象。 真正的风险在于：你没看到报错，却在运行时遭遇 ClassNotFoundException、NoClassDefFoundError 或 MethodHandle.invoke 失败，而问题根源早已埋在类路径（classpath）或模块路径（module-path）里。
为什么插件冲突常被误判为“静默失效”
多数插件系统（如 IDEA 插件平台、dnSpy、MyBatis-Plus 拦截器链、自研 SDK 插件框架）在加载阶段会捕获异常并记录到日志，但默认不中断主流程。用户只看控制台或 IDE 界面，看不到 idea.log、plugin.log 或 stderr 里的真实堆栈。
- IDEA 插件加载失败时，仅在
Help → Show Log in Explorer中可见Plugin 'xxx' failed to load及嵌套的LinkageError - dnSpy 插件若引用了与主程序不兼容的
dnlib版本，System.IO.FileLoadException被吞进AppDomain.CurrentDomain.AssemblyResolve回调，无任何 UI 提示 - MyBatis-Plus 的
TenantLineInnerInterceptor若被注册在其他拦截器之后，租户条件可能被覆盖——它不报错，只是“不生效”
快速定位冲突的三类关键日志位置
别等出问题再翻，把以下路径加入日常排查清单：
- IntelliJ IDEA：
idea.log（路径见Help → Show Log in Explorer），搜索PluginClassLoader、version conflict、duplicate class - Java 应用启动时加
-Dorg.slf4j.simpleLogger.defaultLogLevel=debug，让插件加载器（如ServiceLoader）输出实际加载的META-INF/services/实现类及版本 - dnSpy / .NET 插件：启用 Fusion Log Viewer（
fuslogvw.exe），监控Assembly.LoadFrom失败详情，尤其关注PublicKeyToken和Version字段是否匹配
避免“看起来正常”的兼容性陷阱
很多配置看似通过了校验，实则埋雷。重点盯住这几个点：
-
plugin.xml或MANIFEST.MF中的depends声明只是静态检查，不验证运行时类加载结果；必须配合实际类加载测试 - 使用
mvn dependency:tree -Dincludes=org.projectlombok:lombok查 Lombok 版本时，注意compilevsprovidedscope —— 插件依赖若落在provided，IDE 可能根本不用它 - 模块化项目（
module-info.java）中，即使插件 JAR 声明了requires lombok，若主模块未导出对应包（exports），javac仍会静默跳过注解处理 - 多租户插件中，
excludeTables配置若漏写sys_user这类基础表，租户条件会被错误追加，查询返回空或越权数据——它不报错，只改 SQL
真正危险的不是报错，而是“没报错却做错了”。每次升级插件、JDK 或构建工具前，务必在干净环境跑一次 java -cp 手动触发类加载，比等线上出事再查快十倍。
