业务代码该不该吞掉中间件异常？故障隔离的边界到底画在哪里

背景： 做中间件研发 10 年，code review 里争议最多、也最容易"各说各对"的，就是异常处理。同一个 catch (Exception e) { log.warn("调用xx失败", e); return fallback; } 在 A 团队是"高可用典范"，在 B 团队是"必须打回的重罪"。我见过因为吞掉异常导致下游故障被掩盖 3 天才发现的，也见过因为"异常一路抛到网关返回 500"把一次缓存 miss 放大成全站雪崩的。两件事根因相反，但代码形态几乎一样。

常见分歧（三种流派）：

1. "异常必须上抛"派：异常要冒泡到最外层（Spring 的 GlobalExceptionHandler / gRPC 的 status / 网关），中间层 catch 一律视为隐藏 bug；可观测性靠框架统一打点。
2. "本地故障隔离"派：高可用系统里，单个依赖挂了必须就地降级、就地吞掉，否则一次依赖抖动就是全局雪崩；catch + log + fallback 是标配。
3. "按异常分类"派：业务异常（参数错、状态机非法）上抛，基础设施异常（超时、连接拒绝、序列化失败）就地降级；关键是把"可恢复 vs 不可恢复"分清楚。

我的倾向与理由： 我倾向"默认上抛，仅在明确的隔离边界上捕获"，并配合三条纪律——

• 边界定义：只有服务入口（HTTP/gRPC handler）、线程池任务入口、批处理单条循环这三类位置允许"吞"；中间层一律透传或包装上抛。
• 吞必须留痕：吞掉的异常必须写结构化日志（含 traceId、被吞异常类型、降级动作），且降级路径要有独立 metric，否则吞等于埋雷。
• 吞必须可观测：任何"静默降级"都要在监控面板上有一张曲线，曲线掉下去就该报警，而不是等用户投诉。 理由：异常上抛解决的是"不丢信息"，本地隔离解决的是"不放大故障"，两者不冲突，冲突的是"既不隔离又不留痕"的无脑 catch。

想听大家的：

• 你们团队目前属于哪一派？有没有"吞了之后埋雷"或"没吞导致雪崩"的真实案例？
• 你们怎么判定一个异常"可以吞"？有没有一份可复用的判定清单（比如按异常类型 / 按调用方 SLA / 按重试次数）？
• 吞掉之后，你们配套的监控/告警长什么样？纯日志够不够？
• 中间件本身（比如自研 RPC 框架、缓存客户端）抛出去的异常，业务侧应该如何约定"哪些必须处理、哪些允许忽略"？ 欢迎带上具体场景（同步调用 / 异步消费 / 批处理 / 定时任务）一起讨论，越具体越好。