深入理解 Spring TaskDecorator：异步线程上下文传递的优雅之道

风树种子2026-04-04 20:35

深入理解 Spring TaskDecorator：异步线程上下文传递的优雅之道

在微服务和异步编程大行其道的今天，线程上下文的传递问题几乎是每个 Java 后端工程师都会遇到的"隐形杀手"。本文将从一个真实的生产问题出发，深入剖析 Spring 提供的 TaskDecorator 机制，带你理解它的设计哲学、实现原理与最佳实践。

一、引言：一次 traceId 丢失引发的排查

某天，运维同事反馈：线上有一批请求的日志链路断裂，在主线程中可以看到完整的 traceId，但一旦进入 @Async 异步方法，traceId 就消失了，日志变成了一堆孤立的碎片，根本无法串联。

排查后发现，问题的根因非常简单------线程切换导致 ThreadLocal 中存储的上下文信息丢失。

主线程通过 MDC（Mapped Diagnostic Context）存储了 traceId，但当任务被提交到线程池后，执行任务的是线程池中的另一个线程，它的 ThreadLocal 是空的。

这个问题并不罕见。事实上，SecurityContext 丢失、RequestAttributes 丢失等，本质上都是同一类问题。Spring 框架为此提供了一个精巧的扩展点------TaskDecorator。

二、TaskDecorator 是什么

2.1 接口定义

TaskDecorator 位于 org.springframework.core.task 包下，定义极其简洁：

java 复制代码 
@FunctionalInterface
public interface TaskDecorator {
    Runnable decorate(Runnable runnable);
}

整个接口只有一个方法：接收一个 Runnable，返回一个新的 Runnable。这是经典的装饰器模式（Decorator Pattern）------在不修改原始任务逻辑的前提下，为其附加额外行为。

2.2 设计意图

TaskDecorator 的核心目的是：在任务提交（submit）与任务执行（execute）之间，插入一层装饰逻辑。

典型的使用方式如下：

java 复制代码 
@Bean
public ThreadPoolTaskExecutor taskExecutor() {
    ThreadPoolTaskExecutor executor = new ThreadPoolTaskExecutor();
    executor.setCorePoolSize(10);
    executor.setMaxPoolSize(20);
    executor.setTaskDecorator(new ContextCopyingDecorator());
    executor.initialize();
    return executor;
}

当 ThreadPoolTaskExecutor 接收到一个任务时，会先调用 taskDecorator.decorate(task) 对任务进行包装，然后再交给底层线程池执行。

2.3 装饰器模式的体现

从设计模式的视角来看，TaskDecorator 的思路非常清晰：

复制代码 
原始任务 (Runnable)
    ↓
TaskDecorator.decorate()
    ↓
增强后的任务 (Runnable) ------ 包含了上下文捕获与恢复逻辑
    ↓
线程池执行

它没有要求你修改业务代码，也不需要你继承某个基类，只需要在"提交"和"执行"之间加一层透明的装饰。这正是**开闭原则（OCP）**的优雅实践。

三、为什么需要 TaskDecorator ------ 问题根因分析

3.1 ThreadLocal 的工作原理回顾

ThreadLocal 为每个线程维护一份独立的变量副本，其底层结构是 Thread 对象内部的 ThreadLocalMap：

复制代码 
Thread-1: ThreadLocalMap { key=traceIdHolder, value="abc-123" }
Thread-2: ThreadLocalMap { key=traceIdHolder, value=null }

当业务代码在 Thread-1 中通过 MDC.put("traceId", "abc-123") 存储了追踪 ID 后，这个值只存在于 Thread-1 的 ThreadLocalMap 中。Thread-2 无法感知这个值的存在。

3.2 线程池复用的"陷阱"

线程池的核心价值是线程复用------避免频繁创建和销毁线程的开销。但这也意味着：

  1. 提交任务的线程（通常是 Web 容器的请求处理线程）和执行任务的线程（线程池中的工作线程）不是同一个线程。
  2. 工作线程被复用时，上一次任务残留的 ThreadLocal 数据可能还在（数据污染），或者已经被清除（数据丢失）。

3.3 三大典型丢失场景

场景 存储方式 影响
MDC 日志追踪 ThreadLocal<Map> traceId 丢失，日志链路断裂
Spring Security 认证 SecurityContextHolder（默认 ThreadLocal 策略） 异步线程中获取不到当前用户信息
HTTP 请求上下文 RequestContextHolder（ThreadLocal<RequestAttributes>） 异步线程中无法访问 HttpServletRequest

3.4 上下文断裂示意图

复制代码 
┌──────────────────┐         ┌──────────────────┐
│   请求线程         │         │   线程池工作线程    │
│                  │  submit  │                  │
│  ThreadLocal:    │ ───────> │  ThreadLocal:    │
│  ┌─────────────┐ │         │  ┌─────────────┐ │
│  │ traceId=abc │ │         │  │ traceId=??? │ │  ← 上下文丢失！
│  │ userId=1001 │ │         │  │ userId=???  │ │
│  │ request=... │ │         │  │ request=null│ │
│  └─────────────┘ │         │  └─────────────┘ │
└──────────────────┘         └──────────────────┘

核心矛盾 ：ThreadLocal 绑定的是线程，而非任务。当任务跨线程执行时，上下文自然断裂。

四、源码剖析：TaskDecorator 如何生效

4.1 ThreadPoolTaskExecutor 的继承体系

复制代码 
ExecutorConfigurationSupport
    └── ThreadPoolTaskExecutor
            ├── taskDecorator: TaskDecorator
            ├── execute(Runnable task)
            ├── submit(Runnable task)
            └── submitListenable(Runnable task)

ThreadPoolTaskExecutor 是 Spring 对 JDK ThreadPoolExecutor 的封装，其中关键字段就是 taskDecorator。

4.2 关键源码走读

先看 ThreadPoolTaskExecutor 中的 execute 方法：

java 复制代码 
@Override
public void execute(Runnable task) {
    Executor executor = getThreadPoolExecutor();
    try {
        executor.execute(task);
    }
    catch (RejectedExecutionException ex) {
        throw new TaskRejectedException(
            "Executor [" + executor + "] did not accept task: " + task, ex);
    }
}

等等，这里似乎没有 taskDecorator 的身影？别急，往上层看 initializeExecutor 方法和 createQueue 后的流程：

实际上装饰逻辑发生在任务提交的前置环节。从 Spring 5.x / 6.x 的源码来看，核心在 ThreadPoolTaskExecutor 的以下几个重写方法中：

java 复制代码 
@Override
public void execute(Runnable task) {
    Executor executor = getThreadPoolExecutor();
    try {
        executor.execute(getDecoratedTask(task));
    }
    catch (RejectedExecutionException ex) {
        throw new TaskRejectedException(...);
    }
}

private Runnable getDecoratedTask(Runnable task) {
    return (this.taskDecorator != null ? this.taskDecorator.decorate(task) : task);
}

关键逻辑 ：如果设置了 taskDecorator，则在 execute/submit 时，先对 Runnable 进行装饰，再交给底层的 ThreadPoolExecutor 执行。

4.3 @Async 的调用链路

当我们使用 @Async 注解时，Spring 的执行链路如下：

复制代码 
@Async 方法调用
    ↓
AsyncExecutionInterceptor.invoke()
    ↓
determineAsyncExecutor()  → 找到对应的 TaskExecutor
    ↓
TaskExecutor.submit(Callable)
    ↓
ThreadPoolTaskExecutor.submit()
    ↓
taskDecorator.decorate(task)   ← 装饰在此生效
    ↓
ThreadPoolExecutor.execute(decoratedTask)
    ↓
工作线程执行 decoratedTask.run()

所以，只要我们配置好 TaskDecorator 并将其关联到 @Async 使用的线程池，装饰逻辑就能自动生效，完全不需要修改业务代码。

五、实战：常见 TaskDecorator 实现

5.1 MDC 上下文传递（日志链路追踪）

问题场景 ：使用 SLF4J + Logback，日志 pattern 中配置了 %X{traceId}，但异步线程的日志中 traceId 为空。

实现：

java 复制代码 
public class MdcTaskDecorator implements TaskDecorator {

    @Override
    public Runnable decorate(Runnable runnable) {
        Map<String, String> contextMap = MDC.getCopyOfContextMap();
        return () -> {
            try {
                if (contextMap != null) {
                    MDC.setContextMap(contextMap);
                }
                runnable.run();
            } finally {
                MDC.clear();
            }
        };
    }
}

核心思路：

  1. 在提交线程 （主线程）中，通过 MDC.getCopyOfContextMap() 捕获当前的 MDC 上下文。
  2. 在执行线程 （工作线程）中，先通过 MDC.setContextMap() 恢复上下文，执行完毕后通过 MDC.clear() 清理，避免数据污染。

5.2 SecurityContext 传递（认证信息透传）

问题场景 ：在 @Async 方法中调用 SecurityContextHolder.getContext().getAuthentication() 返回 null。

实现：

java 复制代码 
public class SecurityContextTaskDecorator implements TaskDecorator {

    @Override
    public Runnable decorate(Runnable runnable) {
        SecurityContext context = SecurityContextHolder.getContext();
        return () -> {
            try {
                SecurityContextHolder.setContext(context);
                runnable.run();
            } finally {
                SecurityContextHolder.clearContext();
            }
        };
    }
}

注意 ：这里传递的是 SecurityContext 的引用，而非深拷贝。在大多数只读场景下是安全的，但如果异步线程会修改 SecurityContext（如重新认证），则需要做深拷贝处理。

5.3 RequestAttributes 传递（HTTP 请求上下文）

问题场景 ：异步线程中需要通过 RequestContextHolder 获取当前请求的属性（如 Header 中的租户 ID）。

实现：

java 复制代码 
public class RequestContextTaskDecorator implements TaskDecorator {

    @Override
    public Runnable decorate(Runnable runnable) {
        RequestAttributes attributes = RequestContextHolder.getRequestAttributes();
        return () -> {
            try {
                RequestContextHolder.setRequestAttributes(attributes);
                runnable.run();
            } finally {
                RequestContextHolder.resetRequestAttributes();
            }
        };
    }
}

⚠️ 重要警告 ：RequestAttributes 底层持有的是 HttpServletRequest 的引用。如果异步任务执行时原始请求已经完成（连接已关闭），访问 Request 的某些属性（如 InputStream）会抛异常。因此，建议在捕获时仅提取需要的数据，而非传递整个 RequestAttributes 对象。

5.4 组合式 Decorator：多上下文同时传递

实际生产环境中，我们往往需要同时传递多种上下文。可以设计一个组合装饰器：

java 复制代码 
public class CompositeTaskDecorator implements TaskDecorator {

    private final List<TaskDecorator> decorators;

    public CompositeTaskDecorator(List<TaskDecorator> decorators) {
        this.decorators = decorators;
    }

    @Override
    public Runnable decorate(Runnable runnable) {
        Runnable decorated = runnable;
        for (TaskDecorator decorator : decorators) {
            decorated = decorator.decorate(decorated);
        }
        return decorated;
    }
}

使用方式：

java 复制代码 
executor.setTaskDecorator(new CompositeTaskDecorator(List.of(
    new MdcTaskDecorator(),
    new SecurityContextTaskDecorator(),
    new RequestContextTaskDecorator()
)));

装饰的顺序遵循"洋葱模型"------最先添加的装饰器在最外层，最后添加的在最内层，执行顺序由外向内层层包裹。

六、进阶用法与设计模式

6.1 基于 Spring Boot 的自动配置

在 Spring Boot 中，可以通过 TaskExecutorCustomizer 更优雅地注入 TaskDecorator：

java 复制代码 
@Configuration
public class AsyncConfig {

    @Bean
    public TaskExecutorCustomizer taskExecutorCustomizer() {
        return executor -> executor.setTaskDecorator(new MdcTaskDecorator());
    }
}

这种方式的好处是：不需要完全自定义 ThreadPoolTaskExecutor Bean，而是在 Spring Boot 自动配置的基础上进行增强。

6.2 与 CompletableFuture 的配合

TaskDecorator 对 ThreadPoolTaskExecutor 有效，但如果直接使用 CompletableFuture.supplyAsync(task, executor)，装饰器同样生效吗？

答案是：生效的。 因为 CompletableFuture.supplyAsync 最终调用的是 Executor.execute(Runnable)，而 ThreadPoolTaskExecutor 的 execute 方法中已经包含了装饰逻辑。

java 复制代码 
// 这里的 taskExecutor 是配置了 TaskDecorator 的 ThreadPoolTaskExecutor
CompletableFuture<String> future = CompletableFuture.supplyAsync(() -> {
    // MDC 上下文在这里可用
    log.info("异步任务执行中...");
    return "result";
}, taskExecutor);

6.3 与 @Scheduled 的关系

@Scheduled 默认使用的是 TaskScheduler（通常是 ThreadPoolTaskScheduler），而非 TaskExecutor。ThreadPoolTaskScheduler 同样支持 setTaskDecorator（Spring 6.1+）。

对于早期版本，可以通过自定义 SchedulingConfigurer 来实现类似效果：

java 复制代码 
@Configuration
public class SchedulerConfig implements SchedulingConfigurer {

    @Override
    public void configureTasks(ScheduledTaskRegistrar taskRegistrar) {
        ThreadPoolTaskScheduler scheduler = new ThreadPoolTaskScheduler();
        scheduler.setPoolSize(5);
        scheduler.setTaskDecorator(new MdcTaskDecorator());
        scheduler.initialize();
        taskRegistrar.setTaskScheduler(scheduler);
    }
}

6.4 Lambda 与函数式编程风格

由于 TaskDecorator 是 @FunctionalInterface，可以直接用 Lambda 表达式：

java 复制代码 
executor.setTaskDecorator(runnable -> {
    Map<String, String> context = MDC.getCopyOfContextMap();
    return () -> {
        try {
            MDC.setContextMap(context != null ? context : Map.of());
            runnable.run();
        } finally {
            MDC.clear();
        }
    };
});

简洁场景下可以使用 Lambda，但当逻辑较复杂或需要复用时，建议提取为独立的类。

七、横向对比：上下文传递的其他方案

7.1 方案对比总览

维度 TaskDecorator TransmittableThreadLocal (TTL) InheritableThreadLocal 手动传参
原理 任务装饰 Agent 字节码增强 / 手动包装 线程创建时父→子拷贝 显式方法参数
侵入性 低（仅配置线程池） 极低（Agent 模式零侵入） 无 高（修改方法签名）
线程池支持 ✅ ✅ ❌（仅新建线程有效） ✅
适用范围 Spring 线程池 任意线程池 父子线程 任意场景
框架依赖 Spring Framework 阿里 TTL 库 JDK 原生 无
维护成本 低 中（Agent 部署） 低 高（参数膨胀）

7.2 InheritableThreadLocal 为何不适用于线程池

InheritableThreadLocal 在创建子线程时会将父线程的值拷贝过去。但线程池中的线程只创建一次，后续任务复用已有线程，因此不会触发拷贝逻辑。这导致：

  • 第一个任务可能拿到正确的值（恰好是新创建的线程）
  • 后续任务要么拿到过时的值 （上一次创建时拷贝的），要么拿到空值

这是一个隐蔽的 Bug，在低并发时可能不会暴露，但在高并发下必然出问题。

7.3 TransmittableThreadLocal (TTL) 的优势

阿里开源的 TransmittableThreadLocal 通过 Java Agent 在字节码层面增强了线程池的 execute 方法，自动完成上下文的捕获与恢复。

java 复制代码 
// 使用 TTL 后，无需任何配置，ThreadLocal 自动跨线程传递
TransmittableThreadLocal<String> context = new TransmittableThreadLocal<>();
context.set("value");

executorService.submit(() -> {
    System.out.println(context.get()); // 输出 "value"
});

TTL vs TaskDecorator 的选型建议：

  • 如果你的项目完全基于 Spring，且只需要对 Spring 管理的线程池做上下文传递，TaskDecorator 足够优雅。
  • 如果你的项目中存在非 Spring 管理的线程池（如 Dubbo 线程池、Netty EventLoop 等），或者希望零侵入地解决问题，TTL 是更好的选择。
  • 两者可以共存，不冲突。

八、生产踩坑与最佳实践

8.1 坑1：忘记 clear 导致数据污染

这是最常见的错误：

java 复制代码 
// ❌ 错误示范：没有 finally 清理
public Runnable decorate(Runnable runnable) {
    Map<String, String> contextMap = MDC.getCopyOfContextMap();
    return () -> {
        MDC.setContextMap(contextMap);
        runnable.run();
        // 如果 run() 抛异常，MDC 不会被清理
        // 下一个复用该线程的任务会"继承"这些脏数据
    };
}
java 复制代码 
// ✅ 正确做法：try-finally 确保清理
public Runnable decorate(Runnable runnable) {
    Map<String, String> contextMap = MDC.getCopyOfContextMap();
    return () -> {
        try {
            if (contextMap != null) {
                MDC.setContextMap(contextMap);
            }
            runnable.run();
        } finally {
            MDC.clear();
        }
    };
}

铁律：凡是在 decorate 中向 ThreadLocal 写入数据的，都必须在 finally 中清理。

8.2 坑2：RequestAttributes 的生命周期陷阱

java 复制代码 
// ⚠️ 危险：异步任务可能在请求完成后才执行
public Runnable decorate(Runnable runnable) {
    RequestAttributes attributes = RequestContextHolder.getRequestAttributes();
    return () -> {
        try {
            RequestContextHolder.setRequestAttributes(attributes);
            // 如果此时原始请求已完成，request.getInputStream() 等调用会抛异常
            runnable.run();
        } finally {
            RequestContextHolder.resetRequestAttributes();
        }
    };
}

安全做法 ：在捕获阶段提取需要的数据，而非传递整个 RequestAttributes：

java 复制代码 
public Runnable decorate(Runnable runnable) {
    // 在主线程中提取需要的数据
    HttpServletRequest request = ((ServletRequestAttributes)
        RequestContextHolder.getRequestAttributes()).getRequest();
    String tenantId = request.getHeader("X-Tenant-Id");
    String userId = request.getHeader("X-User-Id");

    return () -> {
        try {
            TenantContext.set(tenantId);
            UserContext.set(userId);
            runnable.run();
        } finally {
            TenantContext.clear();
            UserContext.clear();
        }
    };
}

8.3 坑3：嵌套异步调用的上下文传递链断裂

如果异步任务 A 中又提交了异步任务 B，上下文能否传递到 B？

复制代码 
主线程 → 异步任务 A（通过 TaskDecorator 拿到上下文）
              ↓
         异步任务 B（能否拿到上下文？）

答案是：可以的 ，前提是任务 B 也是通过配置了 TaskDecorator 的线程池提交的。因为 TaskDecorator 的捕获发生在"提交时"，此时任务 A 的线程中已经恢复了上下文，所以任务 B 提交时可以正确捕获。

但要注意：如果任务 A 在 finally 中过早清理了上下文，而任务 B 的提交发生在 finally 之后（比如通过回调触发），就会出现断裂。

8.4 最佳实践清单

# 实践 说明
1 始终在 finally 中清理 防止线程复用导致的数据污染
2 null 值防御 MDC.getCopyOfContextMap() 可能返回 null
3 优先提取数据而非传递引用 特别是 RequestAttributes，避免生命周期问题
4 统一管理 Decorator 使用 CompositeTaskDecorator 集中配置
5 为所有线程池配置 Decorator 包括 @Async、@Scheduled、手动创建的线程池
6 编写单元测试验证传递 确保上下文在异步线程中可用
7 监控线程池状态 配合 Micrometer 监控队列积压，避免任务过期后上下文失效
8 文档化上下文契约 明确哪些上下文会被传递，团队达成共识

九、总结与思考

9.1 TaskDecorator 的设计哲学

TaskDecorator 是一个只有一个方法的接口，但它体现了 Spring 框架设计中的几个核心原则：

  • 关注点分离：上下文传递逻辑与业务逻辑完全解耦，业务代码无需感知。
  • 非侵入式扩展：通过装饰器模式在框架层面提供扩展点，而非要求开发者修改代码。
  • 约定优于配置：一次配置，全局生效。所有通过该线程池执行的任务都自动享受上下文传递。

9.2 Spring 的"扩展点"思维

回顾 Spring 框架，类似 TaskDecorator 的扩展点设计比比皆是：

  • BeanPostProcessor ------ 在 Bean 初始化前后插入逻辑
  • HandlerInterceptor ------ 在请求处理前后插入逻辑
  • ClientHttpRequestInterceptor ------ 在 HTTP 调用前后插入逻辑
  • TaskDecorator ------ 在任务执行前后插入逻辑

它们共同的设计范式是：识别出一个横切关注点，在生命周期的关键节点提供可插拔的扩展接口。

9.3 从 TaskDecorator 到"上下文工程"

在云原生和微服务架构下，"上下文"的概念已经远远超出了单个 JVM 的范畴：

  • 线程级上下文 ：ThreadLocal（TaskDecorator 解决的问题）
  • 请求级上下文 ：HTTP Header 传递（如 X-Request-Id、X-B3-TraceId）
  • 服务级上下文：分布式追踪（OpenTelemetry、SkyWalking）
  • 会话级上下文：Session、Token

如何在这些不同粒度之间无缝传递上下文，是一个值得深思的系统性问题。TaskDecorator 只是这个宏大图景中的一个精巧拼图，但它提供的思路------在边界处自动捕获与恢复------具有普遍的参考价值。

附录

A. 完整配置示例

java 复制代码 
@Configuration
@EnableAsync
public class AsyncConfiguration implements AsyncConfigurer {

    @Override
    public Executor getAsyncExecutor() {
        ThreadPoolTaskExecutor executor = new ThreadPoolTaskExecutor();
        executor.setCorePoolSize(10);
        executor.setMaxPoolSize(50);
        executor.setQueueCapacity(200);
        executor.setThreadNamePrefix("async-");
        executor.setRejectedExecutionHandler(new ThreadPoolExecutor.CallerRunsPolicy());
        executor.setTaskDecorator(new CompositeTaskDecorator(List.of(
            new MdcTaskDecorator(),
            new SecurityContextTaskDecorator()
        )));
        executor.initialize();
        return executor;
    }

    @Override
    public AsyncUncaughtExceptionHandler getAsyncUncaughtExceptionHandler() {
        return (ex, method, params) ->
            log.error("Async method {} threw exception: {}", method.getName(), ex.getMessage(), ex);
    }
}

B. 单元测试验证

java 复制代码 
@SpringBootTest
class TaskDecoratorTest {

    @Autowired
    private ThreadPoolTaskExecutor taskExecutor;

    @Test
    void shouldPropagateContextToAsyncThread() throws Exception {
        MDC.put("traceId", "test-trace-123");

        CompletableFuture<String> future = CompletableFuture.supplyAsync(() -> {
            return MDC.get("traceId");
        }, taskExecutor);

        assertThat(future.get(5, TimeUnit.SECONDS)).isEqualTo("test-trace-123");

        MDC.clear();
    }
}

C. 参考资料

本文基于 Spring Framework 6.x / Spring Boot 3.x 编写，核心概念同样适用于 Spring 5.x / Spring Boot 2.x。

相关推荐
云烟成雨TD2 小时前
Spring AI 1.x 系列【51】可观测性技术选型
java·人工智能·spring
unicrom_深圳市由你创科技2 小时前
基于Spring AI框架的RAG应用
人工智能·spring·机器学习
七老板的blog4 小时前
当 Spring StateMachine 遇见大模型：构建工业级 AI 写作流水线
java·人工智能·spring
云烟成雨TD4 小时前
Spring AI 1.x 系列【46】MCP Security 模块
java·人工智能·spring
小旭95275 小时前
Spring AI Alibaba 从入门到实战：一站式掌握企业级 AI 应用开发
java·人工智能·spring
云烟成雨TD7 小时前
Spring AI 1.x 系列【50】可观测性：接入 Prometheus + Grafana
人工智能·spring·prometheus
phltxy8 小时前
MCP 从协议到 Spring AI 实战
人工智能·spring·oracle
Volunteer Technology10 小时前
SpringSecurity请求流转的本质
java·spring
云烟成雨TD12 小时前
Spring AI 1.x 系列【42】MCP 服务端 Spring Boot 启动器
java·人工智能·spring
云烟成雨TD12 小时前
Spring AI 1.x 系列【38】模型上下文协议（MCP）
java·人工智能·spring
热门推荐
01GitHub 镜像站点02【AI】2026 年具身智能模型和世界模型总结03Codex 下载安装指南：Windows 和 macOS 官方版下载042026 年 AI 编程工具终极横评：Cursor vs Claude Code vs Copilot vs Windsurf052026 AI 编程工具终极实战指南：Cursor vs Claude Code vs Copilot，开发者该怎么选？06【踩坑记录 | 第一篇】微软商店无法使用时，如何手动安装 OpenAI Codex？附`.msix`文件系统错误解决方法07CC-Switch 下载、安装与使用配置指南【2026.5.29】08Agnes AI 全模态 API 免费实测报告：文生图 + 文生视频完整测试09CC-Switch & Claude 基于 Linux 服务器安装使用指南10AI科技热点日报 | 2026年6月1日