关键在于切断异常引发的状态污染链，需通过作用域封装隔离参数副作用、异常后立即清场、返回语义化兜底值，而非简单包装异常。
关键不在“包装异常”，而在切断异常引发的状态污染链。并发污染往往不是因为异常没被捕获，而是捕获后未重置上下文、未清理中间状态、未隔离作用域，导致错误残留影响后续请求或线程。
识别参数传递中的污染风险点
方法参数本身不携带状态，但参数常被用于触发副作用操作——比如将用户ID传入数据库查询后更新ThreadLocal里的权限缓存；或将配置Map传入解析器后意外修改了全局默认值。这些场景中，参数是“引信”，真正污染的是共享变量、线程局部存储、静态缓存或连接上下文。
需重点检查以下参数使用模式：
- 参数被用作键名写入静态Map或ConcurrentHashMap（如
cache.put(paramId, result)） - 参数参与构建或修改ThreadLocal变量（如
userContext.set(userId)） - 参数传入非线程安全对象并调用其可变方法（如向共享List.add()、对共享Builder.setXXX()）
- 参数用于构造SQL/JSON模板后直接拼接执行（埋下二次注入或XSS隐患）
用“作用域封装”替代简单异常包装
不要在方法入口加try-catch再throw new RuntimeException("wrapped: " + e)——这无法阻止污染。应把高风险参数处理包裹进独立作用域：
- Java中用
CompletableFuture.supplyAsync(..., executor)配合独立线程池，避免复用业务线程的ThreadLocal - Kotlin协程中用
withContext(NonCancellable) { ... }或新建CoroutineScope隔离上下文 - Go中通过
context.WithCancel(parent)派生子ctx，并在defer中显式清理资源 - 所有跨模块调用前，对参数做防御性拷贝：
new HashMap(inputMap)、Arrays.copyOf(arr, arr.length)
异常发生后必须执行的三步清场
一旦捕获到异常，不能只记录日志或返回错误码，必须立即执行状态归零操作：
- 清空独占中间态：置空临时buffer、重置计数器、清除本地Builder实例
-
还原关键上下文：调用
ThreadLocal.remove()、恢复数据库事务隔离级别、重置HTTP客户端超时配置 -
剔除可能污染的缓存：主动失效以该参数为key的缓存项（如
cache.invalidate(key)），而非等待TTL过期
返回哑值而非null或原始异常
下游方法若基于参数结果做分支判断（如if (parseConfig(params) != null)），返回null可能引发NPE或逻辑跳过；抛出新异常则破坏调用链可控性。应返回语义明确的兜底值：
- 布尔型参数校验失败 → 返回
false（如“风控开关默认关闭”） - 数值型配置缺失 → 返回预设安全阈值（如超时时间取
3000ms而非0） - 对象型参数解析失败 → 返回不可变空对象（如
Collections.emptyMap()、Optional.empty()）
这样既防止下游误判，也避免因异常传播导致整个并发批次中断。
