逻辑隔离是通过明确边界截断异常传播并重置污染状态，而非简单try-catch；需划定高风险边界、捕获后清场、返回可控哑值，防止脏状态扩散。
“逻辑隔离”不是加个 try-catch 就完事，而是有明确边界的异常围栏——它让高风险模块（如第三方调用、文件解析、模型推理）的错误止步于自身作用域，不干扰外围业务流程和共享状态（比如全局配置、用户会话、缓存上下文）。关键不在“捕获”，而在“截断传播路径”和“重置污染风险”。
为什么必须做逻辑隔离？
很多系统崩溃并非源于异常本身，而是异常后残留的脏状态：比如一个支付模块因网络超时抛出异常，但事务未回滚，账户余额字段被部分更新；又如图像识别服务解析损坏文件失败，却意外修改了全局预处理参数，导致后续所有请求都走错分支。这类“状态污染”比异常更难定位，且无法靠重试修复。
怎么做才真正隔离？三步闭环
1. 明确划定“高风险边界”
不是所有代码都需要包裹。只对以下操作设防：
- 外部依赖调用（HTTP API、数据库查询、消息队列发送）
- 不可信输入处理（用户上传文件、JSON 解析、正则匹配）
- 非幂等资源操作（写磁盘、改注册表、调用硬件接口）
2. 捕获后立即“清场”，而非仅记录
catch 块里必须做三件事：
- 重置该模块独占的中间变量（如清空临时 buffer、置空线程局部存储）
- 恢复关键上下文（如还原 ThreadLocal 中的用户身份、重置数据库连接隔离级别）
- 主动丢弃可能被污染的缓存项（如清除本地计算结果缓存，避免下次误用）
3. 返回可控的“哑值”，切断下游误用链
不要 throw 新异常或返回 null，而应提供语义明确的兜底值：
- 对布尔判断 → 返回 false（如“风控校验失败”默认不拦截）
- 对数值计算 → 返回 0 或默认阈值（如“AI置信度缺失”按最低可信分处理）
- 对对象构造 → 返回空对象或 Builder 的默认实例（避免下游 NPE）
典型反例：看似捕获，实则埋雷
下面这段代码看似安全，实则破坏逻辑隔离：
❌ 错误示范
try {<br>
result = thirdPartyService.invoke();<br>
cache.put("last_result", result); // 异常前已写入脏数据<br>
} catch (TimeoutException e) {<br>
log.warn("调用超时，使用缓存");<br>
return cache.get("last_result"); // 返回的可能是上次失败残留的错误结果<br>
}问题在于：cache.put 在异常发生前执行，且未在 catch 中清理。正确做法是把缓存写入移到 try 块末尾，或在 catch 中强制清除该 key。
