排查第三方JAR泛型Raw Type污染需从依赖源头识别未声明边界的原始类型API，通过反编译确认字节码无泛型信息，调用侧用@SuppressWarnings("rawtypes")最小粒度转型并封装适配器，构建期启用-Xlint:rawtypes强制失败，CI中扫描字节码拦截，并优先升级或替换为有界泛型替代库。
排查第三方 JAR 包因泛型未声明边界引发的 Raw Type 污染，核心在于识别“被擦除却未约束”的泛型使用痕迹，并阻断其向项目代码的传播。这不是改自己代码就能解决的问题，而是要从依赖链源头识别、隔离、适配。
定位污染源：从依赖树中揪出原始类型暴露点
第三方 JAR 若导出未带边界（如 List 而非 List<?> 或 List<Object>）的 API，调用方就极易退化为 raw type。排查需分两步：
- 执行
mvn dependency:tree -Dincludes=groupId:artifactId锁定具体依赖，再加-Dverbose查看是否含compile范围的原始类型导出类 - 反编译该 JAR 中关键类（如
jar -xvf xxx.jar后用 IDE 打开.class），重点查看其 public 方法签名——若返回值或参数是Collection、Map等无泛型形式，即为污染源 - 在 IDE 中按住 Ctrl（Win）或 Cmd（Mac）点击该类方法跳转，若提示 “Cannot resolve symbol” 或显示 raw type 声明，说明其字节码里确实没保留泛型信息
切断传播：在调用侧强制引入类型安全桥接
无法修改第三方代码时，必须在你自己的调用处建立“类型防火墙”，避免 raw type 向下游扩散：
- 禁止直接接收 raw type 返回值：
✘List list = thirdParty.getList();
✔ 改为显式转型并抑制警告（最小粒度）：@SuppressWarnings("rawtypes")<br>List<String> list = (List<String>) thirdParty.getList(); - 对泛型方法参数做通配符封装：
若第三方方法接受Comparator，不要传new Comparator() {...}，而应写new Comparator<? super MyType>() {...} - 封装一层适配器类，把 raw type 输入转为安全泛型输出：
例如包装thirdParty.createMap()返回的Map，内部用new HashMap<String, Object>()接收并校验 key/value 类型
构建防御机制：编译期拦截 + CI 强制卡点
靠人眼检查不可持续，需工程化拦截：
- 在
maven-compiler-plugin中启用-Xlint:rawtypes -Xlint:unchecked，并配置<failOnWarning>true</failOnWarning>，让 raw type 警告直接导致构建失败 - 用
error-prone或checkstyle添加自定义规则：禁止import xxx.thirdparty.*后直接使用原始类型，要求所有调用必须显式标注泛型或通过适配器 - 在 CI 流水线中加入字节码扫描步骤（如使用
jdeps或byte-buddy分析），自动报告项目中哪些类间接引用了第三方 raw type API
长期规避：优先选用有界泛型替代品或自行封装
真正治本的方式是减少对问题 JAR 的直接依赖：
- 查该库是否有新版已修复——很多老版 Apache Commons、早期 Guava 存在此类问题，升级到 3.12+、32.0.0+ 通常已补全边界
- 寻找语义等价但类型严谨的替代库，例如用
org.eclipse.collections替代部分 raw-type-heavy 的 commons-collections - 对高频使用的污染接口，建立公司级轻量封装模块（如
safe-thirdparty-api），内部完成类型桥接，对外只暴露List<T>、Optional<T>等安全接口
