流作用域混乱的本质是上下文状态未隔离，需从入口校验、运行隔离、出口兜底、沙箱化四层防御：强校验非法上下文、ThreadLocal配对清理、异步显式传播、响应后强制清空、快照隔离高风险环节。
流作用域混乱导致的数据交叉感染，本质是上下文状态在多线程、异步或复用环境中未被正确隔离和清理。这类问题不常触发崩溃，却会悄悄污染业务结果——比如用户A的租户ID混入用户B的数据库写入，或链路追踪ID错配导致日志断链。真正的容错设计，不是等它出错再捕获，而是从源头掐断传播路径。
入口强校验：让非法上下文进不来
请求一进入系统，就要对关键上下文做“双检”：
- 类型校验：检查 tenantId 是否为非空字符串、userId 是否为合法数字、traceId 是否符合 UUID 格式；
- 语义校验：验证租户是否已激活、用户 token 是否未过期、灰度标签是否在预注册白名单内；
- 拒绝未声明字段：如出现未定义的 context.extFlag，直接返回 400 并附带错误码 E2001，不向下传递。
运行中隔离：让上下文“进得去、出得来、传得对”
ThreadLocal 不是自动保险柜，必须主动管理生命周期：
- 所有 set() 操作必须配对 try-finally 中的 remove()，尤其在 Filter、Interceptor 或 AOP around advice 里；
- 异步调用（@Async、CompletableFuture.supplyAsync）前，显式复制上下文，例如封装工具类 ContextPropagator.copyTo(newThread)；
- 避免在自定义线程池 submit(Runnable) 时裸传 lambda，改用包装后的 ContextAwareRunnable。
出口兜底与可观测：让残留无处藏身
即使编码规范到位，生产环境仍可能因异常跳过清理逻辑：
- 在统一响应拦截器或 ServletResponseWrapper 的 finally 块中，强制调用 ContextHolder.clear()；
- 接入 Arthas 或 Prometheus + Micrometer，暴露 threadlocal.remain.count 指标，当某类上下文连续 3 次复用未清零，触发告警；
- 日志 MDC 在每次请求结束时清空，并在首条日志中打上 clean:true 标记，便于快速识别残留痕迹。
沙箱化演进：把高风险环节切成独立执行单元
对于配置驱动型流程（如规则引擎、流式任务链），不能依赖全局上下文贯穿始终：
- 每个 task 节点加载时创建独立 ContextSnapshot，包含当前 tenantId、traceId、userRole 等必要字段副本；
- 节点失败时只回滚自身快照，不影响上下游；快照自带默认值策略，如 tenantId 缺失则 fallback 到 system_tenant；
- 通过 JSON Schema 校验输入结构，环路检测提前阻断 A→B→A 类依赖，避免无限递归引发栈溢出掩盖真实上下文问题。
