Android的拦露出崩溃日志里，有些异常你根本不想让用户看到。截某不是异常怕丢脸，是不爆怕用户截图发到应用商店，写上一句“这破软件又闪退”。拦露出实际上那只是截某后台同步时网络超时，界面压根没受影响。异常但系统默认的不爆全局异常处理器不管这些，它逮着个未捕获异常就弹窗、拦露出就写日志。截某

我接手过一个老项目，异常线上崩溃率报表里有个刺眼的不爆红点——某个机型上偶发IllegalStateException，指向一个第三方SDK的拦露出View绘制方法。查了三天，截某发现是异常SDK在Activity销毁后还尝试更新一个已被回收的Fragment视图。这异常根本不影响用户体验，但每次发生都触发系统默认的“应用已停止”对话框。用户一脸懵，我们一脸冤。

解决办法其实粗暴：在Thread.setDefaultUncaughtExceptionHandler里做过滤。但直接替换默认处理器有风险，你得先保存原处理器，处理完自己的逻辑再交给它。核心代码就十几行，但关键在识别哪些异常该“吞掉”。

Thread.setDefaultUncaughtExceptionHandler((thread, throwable) -> {  if (throwable instanceof IllegalStateException && throwable.getMessage() != null && throwable.getMessage().contains("Fragment already added")) {  // 这异常是SDK的bug，界面没事，直接忽略 return; } // 其他异常照旧 if (originalHandler != null) {  originalHandler.uncaughtException(thread, throwable); } else {  // 兜底，防止没人处理 android.os.Process.killProcess(android.os.Process.myPid()); } });

但这里有个坑：你不能把所有IllegalStateException都吞了。得看具体消息内容，最好再配合堆栈特征判断——比如栈顶是不是那个特定的SDK类。我见过有人图省事，直接if (throwable instanceof Exception) return;，结果把真正的空指针也藏了，线上用户数据丢失，那才叫灾难。

还有个更隐蔽的场景。某些国产ROM会在应用崩溃时自动上传日志到厂商服务器，就算你吞了异常，系统层面可能已经记录了。这时候你得在Application.onCreate里提前设置好Thread.setDefaultUncaughtExceptionHandler，抢在系统默认逻辑之前。另外，如果异常发生在子线程，系统同样会走这个处理器，所以过滤逻辑得放在子线程异常也能触达的地方。

吞异常不等于不管。我习惯在吞掉的同时，用Log.w打个警告，或者上报到自己后台的“非致命错误”分类。这样既不让用户看到崩溃弹窗，又能让开发团队知道这个SDK的坑还在。后来那个SDK更新修复了问题，我删掉过滤代码，一切干净。

干这活儿最重要的原则：只吞你完全确定无副作用的异常。判断标准就一条——这个异常发生后，应用状态是否依然完整可用。拿不准就宁可让它崩，也别藏。毕竟崩溃了还能查日志，藏了可能就是一笔糊涂账。