tomcat类加载隔离核心是“精准隔离”：javax.servlet等容器契约类必须由父加载器统一供给以防linkageerror，业务配置类和多版本工具包须由webappclassloader优先加载，shared.loader可显式控制通用工具库共享。
核心思路是：不靠“禁用共享”，而靠“精准隔离”——让每个 war 自己管自己的配置类，同时确保容器契约类（如 javax.servlet.*）仍由 tomcat 统一提供，避免 linkageerror。
明确哪些类必须共享、哪些必须隔离
Tomcat 的类加载器分层不是摆设，而是有明确职责划分：
-
必须由父加载器统一供给的：所有
javax.servlet.*、org.apache.catalina.*、jakarta.*（Tomcat 10+）等容器规范类。这些若被各应用重复打包，会直接触发LinkageError或ClassCastException -
必须由 WebAppClassLoader 优先加载的：业务配置类（如
application.yml对应的YamlPropertySourceLoader）、Spring Boot 的自动配置类、自定义的@Configuration类、以及不同版本的工具包（如commons-lang3-3.12.jarvscommons-lang3-3.9.jar） -
可选共享但需显式控制的：通用工具库（如
fastjson、slf4j-api）。这类建议放入$CATALINA_BASE/lib/shared/，并在catalina.properties中启用shared.loader
从构建阶段切断污染源头
很多“配置污染”其实在打包时就已埋下。关键动作如下：
- Maven 中将容器 API 标记为
provided：<dependency><groupid>jakarta.servlet</groupid><artifactid>jakarta.servlet-api</artifactid><scope>provided</scope></dependency> - 检查 WAR 包内容，确认没有重复打包
servlet-api.jar、tomcat-*.jar等容器内部类 —— 使用jar -tf your-app.war | grep -i "servlet\|catalina"快速验证 - Spring Boot 项目打 WAR 时，确保排除内嵌 Tomcat：
<exclusions><exclusion><groupid>org.springframework.boot</groupid><artifactid>spring-boot-starter-tomcat</artifactid></exclusion></exclusions>
运行时通过类加载策略加固隔离
在 $CATALINA_BASE/conf/catalina.properties 中调整关键参数：
- 设置
loader.delegate=false（默认为false，但务必确认）—— 这是 WebAppClassLoader “先查自己再委托”的前提 - 若需共享基础工具类，启用并配置
shared.loader：shared.loader=${catalina.base}/lib/shared/*.jar，然后把slf4j-api.jar、logback-classic.jar等放进去 - 禁止应用覆盖核心包：确保
common.loader中未意外包含应用级 jar；检查$CATALINA_HOME/lib下无spring-core.jar、mybatis.jar等业务依赖
识别和定位典型污染现象
以下日志特征往往指向类加载污染：
-
FactoryConfigurationError: Provider org.apache.xerces.jaxp.SAXParserFactoryImpl not found→ 应用打包了旧版 Xerces，但 JDK 14+ 已移除内置支持，又没正确委托给容器或 JVM -
java.lang.LinkageError: loader constraint violation→ 同一个类（如HttpServlet）被两个不同加载器加载 -
NoClassDefFoundError出现在某个 WAR 启动成功后、另一个启动失败时 → 前者抢先加载了某类，后者因委托机制找不到兼容版本 - 配置类生效异常（如
@Value("${my.prop}")取到空值或旧值）→ 多个application.properties被不同加载器混读，或PropertySourcesPlaceholderConfigurer实例被共享
