动态混淆类名会导致基于字符串匹配的matches断言失效，需识别日志、异常栈、反射、mockito中类名匹配等易受影响场景，通过保留规则、类型安全替代和实测验证保障一致性。
动态混淆类名（如 ProGuard、R8 或其他代码压缩工具在构建时重命名类/方法）会导致原本基于字符串匹配的 matches 断言失效——比如用正则匹配类名、反射查找类、或通过日志/异常栈中类名做条件判断。这类断言在混淆后“名不符实”，直接跑偏。
明确哪些 matches 会受混淆影响
以下几类断言极易被混淆破坏，需重点识别：
- 日志内容匹配：如
log.contains("MyService")→ 混淆后可能变成"a.b.c" - 异常栈信息解析：如
throwable.getStackTrace()[0].getClassName().matches(".*Processor.*") - 反射调用：如
Class.forName("com.example.UserManager")→ 类名被重命名后抛ClassNotFoundException - Mockito/JUnit 中基于类名的匹配器（非类型安全）：如
verify(mock).process(argThat(s -> s.getClass().getSimpleName().equals("Request")))
用保留规则守住关键标识
混淆工具支持显式保留特定类、方法、字段。只要这些元素参与 matches 判断，就必须保留原始名称：
- 对反射使用的类/方法加
-keep：-keep class com.example.network.** { *; } - 对日志中需识别的类名，用
@Keep注解（Android）或自定义注解 + 规则：-keep @interface androidx.annotation.Keep-keepclasseswithmembers class * { @androidx.annotation.Keep <methods>; }</methods> - 避免用
-dontobfuscate全局关闭混淆——只保必要项，平衡安全与可维护性
改用类型安全或结构化替代方案
绕开字符串匹配，从源头消除混淆依赖：
- 用
instanceof或getClass().isAssignableFrom()替代类名字符串匹配 - 日志中不写类名，改打语义标签或枚举值：
log("NETWORK", "request_sent", Map.of("url", url)) - 异常处理不解析栈，而用自定义异常类型：
if (e instanceof NetworkTimeoutException) { ... } - 测试中避免
argThat(s -> s.getClass().getName().contains("Dto"))，改用any(MyDto.class)或真实实例比对
验证混淆后行为是否一致
仅靠配置不够，必须实测混淆包：
- 构建 release 包后，反编译
classes.jar，确认关键类名未被重命名 - 运行集成测试，重点覆盖所有含
matches的断言逻辑 - 在崩溃监控平台（如 Firebase Crashlytics）中搜索混淆后类名是否出现在预期位置，验证栈解析逻辑
