在实际项目中，我们常常会遇到一些看似简单、实则暗藏复杂逻辑的业务场景。“电梯里的黑胶人”这个比喻，就非常形象地描绘了在分布式系统或高并发环境下，一个请求或任务在多个服务间流转时，其状态、上下文和身份信息如何被层层“包裹”和“传递”，最终可能变得面目全非，难以追踪。这不仅仅是日志链路追踪的问题，更深层次的是关于请求上下文（Request Context）在整个调用链中的无损透传、线程安全以及异步环境下的延续性管理。

对于 Java 开发者，尤其是使用 Spring Boot、Spring Cloud 构建微服务的工程师，理解并正确实现请求上下文的透传，是保障系统可观测性、排查线上问题、实现基于用户的灰度发布等功能的基础。本文将从一个具体的工程问题切入：当一个 HTTP 请求进入网关，经过认证服务、业务服务A、再异步调用业务服务B时，如何保证用户ID、追踪ID、语言标识等关键信息不丢失，并能被所有参与处理的服务和线程正确获取。

我们将围绕这个核心问题，构建一个从概念到落地的完整解决方案。文章会先解释“黑胶人”问题的本质与核心概念，然后搭建一个最小化的微服务演示环境，接着通过代码实现一个基于ThreadLocal和TransmittableThreadLocal的上下文管理组件，并集成到 Spring Cloud 生态中。最后，我们会深入探讨生产环境中可能遇到的坑，并提供一套完整的排查清单和最佳实践。

1. 理解“黑胶人”：请求上下文透传的核心挑战

“黑胶人”这个比喻，生动地说明了请求信息在复杂链路中逐渐“失真”的过程。在技术层面，这主要涉及三个核心概念：请求上下文、线程模型和调用链。

1.1 什么是请求上下文？

请求上下文（Request Context）是指与单个用户请求生命周期绑定的所有状态信息。它不是一个具体的框架类，而是一个逻辑概念。典型的信息包括：

• 用户身份信息：用户ID、用户名、所属租户。
• 追踪信息：TraceId、SpanId，用于链路追踪。
• 环境信息：请求来源IP、语言、设备标识。
• 业务上下文：当前操作的功能模块、特定的业务标志位。

在单体应用中，这些信息通常可以存储在一个全局的、线程绑定的对象中（如ThreadLocal），因为一个请求从头到尾通常由一个线程处理。但在微服务架构下，一个请求会跨越多个进程、多个线程，甚至多个异步任务，这个简单的模型就失效了。

1.2 线程模型带来的挑战

Java Web 应用通常使用线程池来处理请求。当一个 HTTP 请求到达时，Tomcat 或 Netty 会从线程池中分配一个工作线程来处理它。此时，将上下文信息存储在该线程的ThreadLocal变量中是有效的。问题出现在以下场景：

1. 同步跨服务调用：通过 Feign 或 RestTemplate 调用另一个服务时，会发起新的 HTTP 请求。你需要手动将当前线程的上下文信息取出，并塞入新请求的 Header 中。
2. 异步处理：使用@Async、CompletableFuture或消息队列时，任务会被提交到另一个线程池执行。子线程无法继承父线程的ThreadLocal变量。
3. 定时任务/批处理：这些任务并非由外部请求触发，没有天然的“请求上下文”，但执行过程中可能需要访问类似用户、租户等系统级上下文。

如果不做处理，在场景2和3中，子线程试图获取ThreadLocal中的上下文时会得到null，这就是“黑胶人”——请求的身份和状态信息丢失了。

1.3 调用链与透传协议

为了在整个分布式链路中识别同一个请求，我们需要一个唯一的追踪标识（TraceId）。同时，为了描述调用间的父子关系，还需要 SpanId。这些信息需要在每次服务间调用时进行透传。常见的做法是通过 HTTP Header 来传递，例如使用X-Trace-Id、X-Span-Id。

因此，一个完整的上下文透传方案需要解决两个问题：

1. 进程内透传：在同一个 JVM 内，如何让上下文信息在同步、异步、线程池切换等场景下无损传递。
2. 进程间透传：在服务间调用时，如何将上下文信息序列化到协议中（如 HTTP Header），并在对端服务正确解析和还原。

2. 环境准备与项目结构

在开始编码前，我们需要搭建一个简单的演示环境。这个环境将模拟一个网关接收请求，然后调用一个业务服务，业务服务内部再进行异步处理的流程。

2.1 技术栈与依赖

我们使用 Spring Boot 2.7.x 和 Spring Cloud 2021.0.x 作为基础框架。主要依赖如下：

• Spring Boot Starter Web：提供 Web 服务能力。
• Spring Cloud OpenFeign：用于声明式的服务间 HTTP 调用。
• TransmittableThreadLocal (TTL)：阿里开源的解决ThreadLocal跨线程传递问题的库。
• Lombok：简化 Java Bean 编写。

以下是 Maven 父工程pom.xml的关键部分：

<?xml version="1.0" encoding="UTF-8"?> <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd"> <modelVersion>4.0.0</modelVersion> <parent> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-parent</artifactId> <version>2.7.18</version> <relativePath/> </parent> <groupId>com.example</groupId> <artifactId>request-context-demo</artifactId> <version>1.0.0</version> <packaging>pom</packaging> <modules> <module>gateway-service</module> <module>business-service</module> <module>common-context</module> </modules> <properties> <java.version>11</java.version> <spring-cloud.version>2021.0.8</spring-cloud.version> <transmittable-thread-local.version>2.14.2</transmittable-thread-local.version> </properties> <dependencyManagement> <dependencies> <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-dependencies</artifactId> <version>${spring-cloud.version}</version> <type>pom</type> <scope>import</scope> </dependency> </dependencies> </dependencyManagement> <dependencies> <!-- 公共依赖，会被子模块继承 --> <dependency> <groupId>org.projectlombok</groupId> <artifactId>lombok</artifactId> <optional>true</optional> </dependency> <dependency> <groupId>com.alibaba</groupId> <artifactId>transmittable-thread-local</artifactId> <version>${transmittable-thread-local.version}</version> </dependency> </dependencies> </project>

2.2 项目模块划分

我们创建三个子模块，职责清晰分离：

1. common-context：存放上下文定义、管理工具类、Feign 拦截器等通用代码。这是一个普通的 Jar 模块，不启动。
2. gateway-service：模拟网关或边缘服务。负责接收外部请求，初始化上下文，并调用下游业务服务。端口：8080。
3. business-service：模拟核心业务服务。接收网关调用，并执行包含异步操作的业务逻辑。端口：8081。

request-context-demo/ ├── pom.xml ├── common-context │ ├── pom.xml │ └── src/main/java/com/example/common/context/... ├── gateway-service │ ├── pom.xml │ └── src/main/java/com/example/gateway/... └── business-service ├── pom.xml └── src/main/java/com/example/business/...

gateway-service和business-service都需要依赖common-context模块。

<!-- 在 gateway-service 和 business-service 的 pom.xml 中 --> <dependency> <groupId>com.example</groupId> <artifactId>common-context</artifactId> <version>${project.version}</version> </dependency> <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-openfeign</artifactId> </dependency> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> </dependency>

3. 实现进程内上下文管理：告别裸用 ThreadLocal

ThreadLocal是基础，但直接使用它在异步场景下会“失忆”。我们需要一个更强大的包装器。

3.1 定义上下文实体

首先在common-context模块中定义我们要传递的上下文数据。这是一个简单的 POJO。

package com.example.common.context; import lombok.Data; import java.io.Serializable; @Data public class RequestContext implements Serializable { /** * 链路追踪ID，整个请求链唯一 */ private String traceId; /** * 当前用户ID */ private String userId; /** * 当前用户名称 */ private String userName; /** * 租户ID (多租户系统) */ private String tenantId; /** * 请求语言 */ private String lang; // 其他业务自定义字段... }

3.2 创建基于 TTL 的上下文持有器

这是最核心的组件。我们使用TransmittableThreadLocal来持有上下文对象。TTL 通过TtlRunnable和TtlCallable包装，可以解决线程池场景下的上下文传递问题。

package com.example.common.context; import com.alibaba.ttl.TransmittableThreadLocal; public class RequestContextHolder { /** * 使用 TransmittableThreadLocal 存储上下文 */ private static final TransmittableThreadLocal<RequestContext> CONTEXT_HOLDER = new TransmittableThreadLocal<>(); /** * 设置当前请求上下文 */ public static void setContext(RequestContext context) { if (context == null) { clearContext(); } else { CONTEXT_HOLDER.set(context); } } /** * 获取当前请求上下文 * @return 当前上下文，可能为null（例如在非Web线程或未初始化时） */ public static RequestContext getContext() { return CONTEXT_HOLDER.get(); } /** * 获取当前上下文，如果为空则返回一个空的上下文对象（避免NPE） * 适用于非关键路径，需要谨慎使用 */ public static RequestContext getContextOrDefault() { RequestContext context = getContext(); if (context == null) { return new RequestContext(); // 返回一个所有字段为null的空对象 } return context; } /** * 清除当前线程的上下文 * 重要：必须在请求处理结束时调用，防止内存泄漏和上下文污染 */ public static void clearContext() { CONTEXT_HOLDER.remove(); } /** * 获取当前TraceId，方便日志打印 */ public static String getTraceId() { RequestContext ctx = getContext(); return ctx != null ? ctx.getTraceId() : "N/A"; } /** * 获取当前UserId */ public static String getUserId() { RequestContext ctx = getContext(); return ctx != null ? ctx.getUserId() : null; } }

关键解释：

1. TransmittableThreadLocal继承自InheritableThreadLocal，但通过包装Runnable/Callable解决了线程池复用线程时上下文传递的问题。
2. setContext和clearContext必须成对调用，尤其是在 Web 请求的拦截器或过滤器中，clearContext通常放在finally块中。
3. getContextOrDefault提供了一个降级方案，但业务代码应尽量判断上下文是否存在，因为空上下文可能意味着调用链路出现了问题。

3.3 配置 TTL 线程池包装（可选但推荐）

为了自动化，我们可以配置一个ThreadPoolTaskExecutorBean，让 Spring 管理的@Async任务自动支持 TTL。

package com.example.common.context.config; import com.alibaba.ttl.threadpool.TtlExecutors; import org.springframework.context.annotation.Bean; import org.springframework.context.annotation.Configuration; import org.springframework.scheduling.annotation.AsyncConfigurer; import org.springframework.scheduling.concurrent.ThreadPoolTaskExecutor; import java.util.concurrent.Executor; @Configuration public class TtlThreadPoolConfig implements AsyncConfigurer { @Bean("ttlThreadPoolTaskExecutor") public ThreadPoolTaskExecutor ttlThreadPoolTaskExecutor() { ThreadPoolTaskExecutor executor = new ThreadPoolTaskExecutor(); executor.setCorePoolSize(10); executor.setMaxPoolSize(50); executor.setQueueCapacity(100); executor.setThreadNamePrefix("ttl-async-"); executor.initialize(); return executor; } /** * 关键：返回经过 TTL 包装的 Executor。 * 这样，使用 @Async("ttlThreadPoolTaskExecutor") 的方法会自动传递上下文。 */ @Override public Executor getAsyncExecutor() { ThreadPoolTaskExecutor executor = ttlThreadPoolTaskExecutor(); return TtlExecutors.getTtlExecutor(executor); } }

在业务代码中，使用@Async("ttlThreadPoolTaskExecutor")来指定使用这个支持上下文传递的线程池。

4. 实现进程间上下文透传：Feign 拦截器与过滤器

上下文在单个服务内管理好了，下一步就是如何在服务间调用时传递。我们通过实现 Feign 的RequestInterceptor和 Spring Web 的Filter来完成。

4.1 定义上下文常量（Header Key）

在common-context中定义用于 HTTP Header 的常量。

package com.example.common.context.constant; public class ContextConstant { /** * HTTP Header 中传递 TraceId 的键名 */ public static final String HEADER_TRACE_ID = "X-Trace-Id"; /** * HTTP Header 中传递 UserId 的键名 */ public static final String HEADER_USER_ID = "X-User-Id"; public static final String HEADER_USER_NAME = "X-User-Name"; public static final String HEADER_TENANT_ID = "X-Tenant-Id"; public static final String HEADER_LANG = "X-Lang"; // ... 其他字段 }

4.2 实现 Feign 客户端拦截器（发送端）

这个拦截器会在 Feign 构造请求前执行，将当前线程上下文中的信息放入请求 Header。

package com.example.common.context.feign; import com.example.common.context.RequestContextHolder; import com.example.common.context.constant.ContextConstant; import feign.RequestInterceptor; import feign.RequestTemplate; import lombok.extern.slf4j.Slf4j; import org.springframework.stereotype.Component; @Slf4j @Component // 自动被 Spring Cloud Feign 扫描并应用 public class FeignContextInterceptor implements RequestInterceptor { @Override public void apply(RequestTemplate template) { // 从当前线程的 TTL 中获取上下文 com.example.common.context.RequestContext context = RequestContextHolder.getContext(); if (context != null) { // 将上下文信息放入 Feign 请求的 Header 中 template.header(ContextConstant.HEADER_TRACE_ID, context.getTraceId()); template.header(ContextConstant.HEADER_USER_ID, context.getUserId()); template.header(ContextConstant.HEADER_USER_NAME, context.getUserName()); template.header(ContextConstant.HEADER_TENANT_ID, context.getTenantId()); template.header(ContextConstant.HEADER_LANG, context.getLang()); log.debug("[FeignInterceptor] Transmit context to service: {}, traceId: {}", template.feignTarget().name(), context.getTraceId()); } else { log.warn("[FeignInterceptor] No RequestContext found in current thread for Feign call to {}", template.feignTarget().name()); } } }

4.3 实现 Web 请求过滤器（接收端）

这个过滤器会在请求到达 Controller 之前执行，从 HTTP Header 中提取信息，并构造上下文设置到RequestContextHolder中。务必在 finally 块中清理上下文。

package com.example.common.context.filter; import com.example.common.context.RequestContext; import com.example.common.context.RequestContextHolder; import com.example.common.context.constant.ContextConstant; import lombok.extern.slf4j.Slf4j; import org.springframework.core.annotation.Order; import org.springframework.stereotype.Component; import org.springframework.util.StringUtils; import javax.servlet.*; import javax.servlet.http.HttpServletRequest; import java.io.IOException; import java.util.UUID; @Slf4j @Component @Order(Integer.MIN_VALUE) // 设置最高优先级，确保最早执行 public class RequestContextFilter implements Filter { @Override public void doFilter(ServletRequest servletRequest, ServletResponse servletResponse, FilterChain filterChain) throws IOException, ServletException { HttpServletRequest request = (HttpServletRequest) servletRequest; RequestContext context = new RequestContext(); // 1. 获取或生成 TraceId String traceId = request.getHeader(ContextConstant.HEADER_TRACE_ID); if (!StringUtils.hasText(traceId)) { traceId = "GATEWAY-" + UUID.randomUUID().toString().replace("-", "").substring(0, 16); log.info("[RequestContextFilter] Generate new traceId: {}", traceId); } context.setTraceId(traceId); // 2. 从 Header 中获取其他上下文信息 context.setUserId(request.getHeader(ContextConstant.HEADER_USER_ID)); context.setUserName(request.getHeader(ContextConstant.HEADER_USER_NAME)); context.setTenantId(request.getHeader(ContextConstant.HEADER_TENANT_ID)); context.setLang(request.getHeader(ContextConstant.HEADER_LANG)); // 3. 将上下文设置到 TTL 中 RequestContextHolder.setContext(context); log.debug("[RequestContextFilter] Set context for traceId: {}", traceId); try { // 4. 继续执行过滤器链和业务逻辑 filterChain.doFilter(servletRequest, servletResponse); } finally { // 5. 关键！请求结束后必须清理，防止内存泄漏和上下文污染 RequestContextHolder.clearContext(); log.debug("[RequestContextFilter] Cleared context for traceId: {}", traceId); } } @Override public void init(FilterConfig filterConfig) throws ServletException { Filter.super.init(filterConfig); } @Override public void destroy() { Filter.super.destroy(); } }

关键解释：

1. @Order(Integer.MIN_VALUE)确保这个过滤器最先执行，这样后续的拦截器、Controller 都能获取到上下文。
2. TraceId 生成策略：在网关或第一个接收请求的服务中，如果 Header 里没有 TraceId，则生成一个新的。这保证了整个链路的唯一标识。
3. finally 块中的clearContext()：这是防止内存泄漏的生命线。无论请求处理成功还是抛出异常，都必须清理当前线程的ThreadLocal数据。在线程池场景下，一个线程会被复用处理多个请求，如果不清理，下一个请求会读到上一个请求的上下文，造成严重的数据错乱。

5. 在业务服务中验证与使用

现在，我们可以在business-service中编写代码，验证上下文是否能够正确透传。

5.1 编写业务 Controller 和异步 Service

首先，创建一个接收网关调用的 Controller。

package com.example.business.controller; import com.example.business.service.AsyncBusinessService; import com.example.common.context.RequestContextHolder; import lombok.extern.slf4j.Slf4j; import org.springframework.beans.factory.annotation.Autowired; import org.springframework.web.bind.annotation.GetMapping; import org.springframework.web.bind.annotation.RequestMapping; import org.springframework.web.bind.annotation.RestController; @Slf4j @RestController @RequestMapping("/api/biz") public class BusinessController { @Autowired private AsyncBusinessService asyncBusinessService; @GetMapping("/process") public String processRequest() { // 1. 同步代码中可以直接获取上下文 String traceId = RequestContextHolder.getTraceId(); String userId = RequestContextHolder.getUserId(); log.info("[BusinessController] Sync process. traceId: {}, userId: {}", traceId, userId); // 2. 调用异步方法 asyncBusinessService.asyncTask(); return "Business process started. TraceId: " + traceId; } }

然后，创建一个异步 Service，模拟耗时的后台任务。

package com.example.business.service; import com.example.common.context.RequestContextHolder; import lombok.extern.slf4j.Slf4j; import org.springframework.scheduling.annotation.Async; import org.springframework.stereotype.Service; @Slf4j @Service public class AsyncBusinessService { /** * 使用支持 TTL 的线程池执行器 */ @Async("ttlThreadPoolTaskExecutor") // 指向我们配置的 TTL 包装线程池 public void asyncTask() { // 在异步线程中尝试获取上下文 String traceId = RequestContextHolder.getTraceId(); String userId = RequestContextHolder.getUserId(); if (traceId != null && !"N/A".equals(traceId)) { log.info("[AsyncBusinessService] Async task executed successfully. traceId: {}, userId: {}", traceId, userId); // 这里可以继续用 traceId 和 userId 进行数据库操作、日志记录等 } else { log.error("[AsyncBusinessService] ERROR! Context is LOST in async thread!"); // 上下文丢失，可能导致业务逻辑错误或日志无法关联 } } }

5.2 网关服务调用业务服务

在gateway-service中，我们创建一个简单的 Controller 来模拟网关入口，并通过 Feign 客户端调用业务服务。

首先，定义 Feign 客户端接口。

package com.example.gateway.client; import org.springframework.cloud.openfeign.FeignClient; import org.springframework.web.bind.annotation.GetMapping; @FeignClient(name = "business-service", url = "http://localhost:8081") public interface BusinessServiceClient { @GetMapping("/api/biz/process") String process(); }

然后，编写网关的入口 Controller。

package com.example.gateway.controller; import com.example.gateway.client.BusinessServiceClient; import com.example.common.context.RequestContext; import com.example.common.context.RequestContextHolder; import lombok.extern.slf4j.Slf4j; import org.springframework.beans.factory.annotation.Autowired; import org.springframework.web.bind.annotation.GetMapping; import org.springframework.web.bind.annotation.RequestHeader; import org.springframework.web.bind.annotation.RestController; import java.util.UUID; @Slf4j @RestController public class GatewayController { @Autowired private BusinessServiceClient businessServiceClient; @GetMapping("/gateway/entry") public String gatewayEntry( @RequestHeader(value = "X-User-Id", required = false) String userId, @RequestHeader(value = "X-User-Name", required = false) String userName) { // 1. 模拟网关认证，并构建初始上下文 RequestContext context = new RequestContext(); context.setTraceId("GATEWAY-" + UUID.randomUUID().toString().replace("-", "").substring(0, 16)); context.setUserId(userId != null ? userId : "anonymous"); context.setUserName(userName != null ? userName : "Anonymous User"); context.setTenantId("tenant_001"); context.setLang("zh-CN"); // 2. 将上下文设置到当前线程（网关线程） RequestContextHolder.setContext(context); log.info("[Gateway] Context set. traceId: {}, userId: {}", context.getTraceId(), context.getUserId()); try { // 3. 通过 Feign 调用下游业务服务 // FeignContextInterceptor 会自动将上下文注入请求Header String result = businessServiceClient.process(); return "Gateway -> " + result; } finally { // 4. 清理网关线程的上下文 RequestContextHolder.clearContext(); } } }

5.3 运行与验证

1. 依次启动gateway-service(端口8080) 和business-service(端口8081)。
2. 使用 curl 或 Postman 调用网关入口：

   curl -H “X-User-Id: U1001” -H “X-User-Name: ZhangSan” http://localhost:8080/gateway/entry

3. 观察两个服务的控制台日志输出。

预期成功的日志输出：

• gateway-service:

  [Gateway] Context set. traceId: GATEWAY-7a3b8c9d0e1f2a3b, userId: U1001 [FeignInterceptor] Transmit context to service: business-service, traceId: GATEWAY-7a3b8c9d0e1f2a3b

• business-service:

  [RequestContextFilter] Set context for traceId: GATEWAY-7a3b8c9d0e1f2a3b [BusinessController] Sync process. traceId: GATEWAY-7a3b8c9d0e1f2a3b, userId: U1001 [AsyncBusinessService] Async task executed successfully. traceId: GATEWAY-7a3b8c9d0e1f2a3b, userId: U1001 [RequestContextFilter] Cleared context for traceId: GATEWAY-7a3b8c9d0e1f2a3b

如果一切正常，你将看到同一个traceId贯穿了网关、业务服务的同步代码和异步代码。这证明我们的“黑胶人”问题得到了解决——请求的身份信息在复杂的调用链路中保持了完整。

6. 生产环境常见问题与排查清单

将方案应用到生产环境，会面临更多挑战。以下是典型问题及排查路径。

6.1 上下文丢失的常见场景与排查

6.2 性能与内存考量

• TTL 包装开销：TtlRunnable包装会带来微小的性能损耗和内存占用。对于极高并发、超低延迟的场景，需要评估。但对于绝大多数业务系统，其带来的可观测性收益远大于损耗。
• 上下文对象大小：RequestContext应保持轻量，仅存放链路追踪和必要的身份信息。切勿将大数据对象（如完整的用户实体、查询结果集）放入其中，这会导致每个线程都持有大量内存，引发 GC 压力。
• ThreadLocal 内存泄漏：这是老生常谈但至关重要的问题。TransmittableThreadLocal本身不解决泄漏，它只是解决了传递问题。必须依靠clearContext()来清理。建议在代码审查中重点检查所有设置上下文的地方，是否都有配对的清理逻辑。

6.3 与现有基础设施集成

• 链路追踪系统（SkyWalking, Zipkin）：我们的traceId最好能与这些系统的 TraceId 对齐。通常可以在网关或第一个服务中，从追踪系统（如通过org.slf4j.MDC）获取 TraceId，然后设置到我们的RequestContext中。这样日志和追踪链路就能通过同一个 ID 关联。
• 安全框架（Spring Security）：我们的userId等信息很可能来自 Spring Security 的SecurityContext。可以在认证成功的过滤器或事件监听器中，将SecurityContext的信息提取出来，填充到我们的RequestContext。
• RPC 框架（Dubbo, gRPC）：原理与 Feign 类似，需要实现相应的 Filter 或 Interceptor。Dubbo 有RpcContext和Attachment机制，gRPC 有Metadata，都需要在其中进行上下文的序列化和反序列化。

7. 最佳实践与扩展方向

7.1 上下文管理最佳实践清单

1. 定义清晰边界：明确RequestContext中应该放什么（全局、跨服务、与请求强相关的元数据），不应该放什么（业务数据、大对象）。
2. 提供工具类而非直接操作 TTL：就像我们封装的RequestContextHolder，业务代码只通过它访问上下文，隐藏底层实现。
3. 设置默认值与空安全：RequestContextHolder.getContextOrDefault()提供了降级，但业务逻辑应判断关键字段（如userId）是否为 null，以决定是否继续执行或抛出友好异常。
4. 强制清理：将clearContext()的调用写入团队编码规范，并利用代码检查工具（如 SonarQube）进行约束。
5. 日志集成：在日志框架（如 Logback, Log4j2）的 Pattern 中配置%X{traceId}，这样每条日志都会自动打印当前 TraceId，无需手动添加。
6. 单元测试：编写单元测试，模拟 Web 请求、异步调用等场景，验证上下文传递的正确性。

7.2 扩展方向

1. 动态字段：当前的RequestContext是静态定义的。可以设计一个Map<String, Object>类型的attributes字段，用于存放一些临时、动态的上下文信息，但需谨慎管理其生命周期。
2. 上下文传播到数据访问层：可以通过 MyBatis 的Interceptor或 JPA 的@EntityListener，在数据操作时自动注入tenantId、createBy等字段，实现数据层面的多租户和审计。
3. 基于上下文的灰度发布：在RequestContext中加入version或tag字段，在网关或 RPC 调用时，根据该字段将请求路由到特定版本的服务实例。
4. 上下文与 Reactive 编程：在 WebFlux 等响应式编程模型中，ThreadLocal失效。需要采用 Reactor 的Context机制来管理请求上下文，其设计思想类似，但 API 不同。

通过以上从理论到实践，从核心代码到生产保障的完整阐述，我们系统地解决了“电梯里的黑胶人”问题。关键在于理解线程模型、选择正确的工具（如 TTL）、设计无侵入的透传机制（Filter + Interceptor），并严格遵守设置与清理的编程契约。这套方案不仅能用于用户信息透传，更是构建可观测、可排查、具备高级治理能力的分布式系统的基石。在实际项目中，你可以以此为基础，根据具体的架构和技术栈进行适配和增强。