1. 项目概述：一个为Spring Boot应用注入AI对话能力的“启动器”

如果你正在开发一个基于Spring Boot的Java应用，并且想快速、优雅地集成类似ChatGPT的大语言模型对话能力，那么你很可能已经厌倦了手动处理HTTP请求、解析JSON响应、管理API密钥和设计重试逻辑这些繁琐的步骤。这正是 lzhpo/chatgpt-spring-boot-starter 这个开源项目诞生的背景。它本质上是一个Spring Boot Starter，一个“启动器”，其目标是将复杂的AI服务调用封装成简单、声明式的Java接口，让开发者能以最熟悉、最Spring Boot的方式，像调用本地服务一样调用远程的AI大模型。

想象一下，你不再需要写一堆 RestTemplate 或 WebClient 的样板代码，不再需要手动拼接请求体、处理错误码。你只需要在 application.yml 里配置好你的API密钥和端点，然后在你的Service层注入一个由这个Starter自动配置好的 ChatGPTClient Bean，调用它的 chat 方法，传入一个消息列表，就能直接拿到结构化的AI回复。这极大地降低了集成门槛，让后端开发者可以更专注于业务逻辑的创新，而不是底层通信的细节。

这个Starter的核心价值在于“标准化”和“便捷化”。它定义了一套与主流AI服务提供商（如OpenAI、国内各大模型平台）API兼容的交互模型，包括消息角色（用户、助手、系统）、聊天完成请求/响应体等。通过Spring Boot的自动配置机制，它将这些模型和客户端无缝集成到你的应用上下文中。无论是构建一个智能客服机器人、一个代码生成工具，还是一个内容创作助手，这个Starter都能让你在几分钟内完成核心AI能力的接入，剩下的就是如何利用AI的输出来创造价值了。

2. 核心架构与设计思路拆解

2.1 为什么选择Starter模式？

Spring Boot Starter是Spring Boot生态中实现“约定大于配置”理念的核心组件。一个优秀的Starter应该做到“开箱即用”。对于AI服务集成这种通用性极强的需求，采用Starter模式是再合适不过的选择。它解决了几个关键问题：

  1. 依赖管理 ：Starter的 pom.xml 或 build.gradle 文件会声明所有必要的依赖，比如HTTP客户端（可能是OkHttp、Apache HttpClient或Spring自带的WebClient）、JSON处理库（如Jackson）以及可能需要的连接池、重试库等。用户只需引入这一个Starter依赖，所有传递依赖都会被自动管理，避免了版本冲突。
  2. 自动配置 ：通过 spring.factories 文件或 META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports 文件（取决于Spring Boot版本），Starter可以声明自己的自动配置类。这个类会基于类路径上存在的依赖和用户的配置文件（ application.yml/properties ），条件化地创建和配置所需的Bean。例如，只有当配置了 chatgpt.api-key 属性时，才会创建 ChatGPTClient Bean。
  3. 外部化配置 ：Starter通常会定义一个或多个 @ConfigurationProperties 类，将相关的配置项（如API端点、密钥、超时时间、模型名称等）绑定到前缀下（如 chatgpt ）。用户可以在配置文件中以统一、清晰的方式进行配置，享受IDE的自动提示支持。
  4. 易于扩展 ：Starter内部可以采用模板方法、策略模式等设计模式，使得支持新的AI服务提供商（如从OpenAI切换到Azure OpenAI或国内的文心一言、通义千问）变得相对容易，只需实现特定的适配器即可，对上层业务代码透明。

lzhpo/chatgpt-spring-boot-starter 正是遵循了这一最佳实践。它将调用AI服务所需的全部“脏活累活”封装在Starter内部，对外暴露一个干净、易用的客户端接口。

2.2 核心交互模型设计

一个健壮的AI客户端Starter，其内部模型设计至关重要。它需要能够灵活地映射到不同服务商的API，同时为Java开发者提供友好的编程体验。通常，其核心模型会包含以下几个部分：

  • 请求模型 ( ChatCompletionRequest ) ：封装一次聊天完成请求的所有参数。这远不止是“消息”那么简单。一个完整的请求可能包括：

    • model : 字符串，指定使用的模型，如 gpt-3.5-turbo , gpt-4 等。
    • messages : List<ChatMessage> ，对话消息列表。每个 ChatMessage 应包含 role (如 user , assistant , system ) 和 content 。
    • temperature : 浮点数，控制输出的随机性（创造性）。值越高，输出越随机。
    • top_p : 浮点数，另一种控制随机性的方式（核采样），通常与 temperature 二选一。
    • max_tokens : 整数，限制生成回复的最大令牌数。
    • stream : 布尔值，是否启用流式输出（Server-Sent Events）。这对于需要实时显示生成内容的场景非常有用。
    • ... 其他提供商特定的参数。

  • 响应模型 ( ChatCompletionResponse ) ：封装AI服务返回的结果。关键字段包括：

    • id : 本次调用的唯一标识。
    • choices : List<ChatChoice> ，包含生成的候选回复。每个 Choice 通常包含 message (一个 ChatMessage 对象) 和 finish_reason (如 stop , length )。
    • usage : 包含本次调用消耗的令牌数 ( prompt_tokens , completion_tokens , total_tokens )，用于成本核算。
    • created : 时间戳。

  • 消息模型 ( ChatMessage ) ：最基础的单元，包含 role 和 content 。为了支持更复杂的场景（如多模态输入）， content 字段可能被设计为可以包含文本、图片URL等多种类型，但这会增加复杂性。一个简单可靠的实现是先支持纯文本。

  • 客户端接口 ( ChatGPTClient ) ：这是面向开发者的主要接口。其核心方法可能像这样： 

    public interface ChatGPTClient {
    ChatCompletionResponse chat(ChatCompletionRequest request);
    // 可能还有异步版本
    CompletableFuture<ChatCompletionResponse> chatAsync(ChatCompletionRequest request);
    // 流式响应版本（如果支持）
    Flux<ChatCompletionResponse> chatStream(ChatCompletionRequest request);
}

lzhpo/chatgpt-spring-boot-starter 的实现应该紧密围绕这些模型展开，确保数据在Java对象、JSON以及HTTP请求体之间正确、高效地转换。

2.3 配置属性设计

一个灵活的Starter必须提供丰富的可配置项。以下是一个典型的配置属性类 ( ChatGPTProperties ) 可能包含的字段： 

chatgpt:
  enabled: true # 是否启用自动配置
  api-key: ${CHATGPT_API_KEY:sk-xxx} # API密钥，支持从环境变量读取
  api-host: https://api.openai.com/v1 # API基础地址，方便切换代理或不同服务商
  model: gpt-3.5-turbo # 默认模型
  connect-timeout: 10s # HTTP连接超时
  read-timeout: 30s # 读取响应超时，对于长文本生成可能需要更久
  max-retries: 3 # 失败重试次数（针对网络抖动或服务端限流）
  retry-backoff: 1s # 重试回退时间
  proxy: # 代理配置（如果需要）
    host: 127.0.0.1
    port: 7890
  # 可能还有日志级别、请求/响应日志拦截器等配置

通过这样的设计，用户可以根据自己的网络环境、业务需求和成本考量，灵活地调整客户端行为。

3. 核心细节解析与实操要点

3.1 HTTP客户端的选型与封装

在Starter内部，需要一个可靠的HTTP客户端来执行网络请求。常见的选择有：

  1. Spring WebClient ：响应式、非阻塞，是Spring 5以来的推荐方式，尤其适合在响应式编程栈中使用。它功能强大，但学习曲线相对陡峭，配置稍显复杂。
  2. OkHttp ：Square公司出品，以高效、简洁著称，支持连接池、GZIP压缩、HTTP/2等特性，是Android和Java后端非常流行的选择。它的拦截器机制非常适合添加认证头、日志、重试逻辑。
  3. Apache HttpClient ：老牌、稳定、功能全面，但API相对陈旧和冗长。
  4. RestTemplate ：Spring传统的同步客户端，简单易用，但在Spring 5中已标记为“维护模式”，不推荐用于新项目。

对于 lzhpo/chatgpt-spring-boot-starter 这类追求轻量、高效和易用的Starter， OkHttp 是一个非常好的选择。它性能优异，拦截器机制能优雅地处理公共逻辑（如添加 Authorization: Bearer {apiKey} 请求头）。我们可以通过 OkHttpClient.Builder() 来构建客户端，并集成超时、重试、代理等配置。

注意 ：如果你决定使用OkHttp，需要将其依赖设置为 optional （在Maven中是 <optional>true</optional> ），这样不会强制所有使用该Starter的项目都引入OkHttp，他们可以使用自己项目已有的HTTP客户端库（如WebClient），只要Starter的接口设计得当，可以通过SPI机制来适配不同的实现。

3.2 认证与请求头处理

调用AI服务API，认证是关键。绝大多数服务都使用Bearer Token认证，即在HTTP请求的 Authorization 头中携带API密钥。这个逻辑应该封装在HTTP客户端的拦截器中，对使用者透明。

一个典型的认证拦截器实现如下（以OkHttp为例）： 

public class AuthenticationInterceptor implements Interceptor {
    private final String apiKey;

    public AuthenticationInterceptor(String apiKey) {
        this.apiKey = apiKey;
    }

    @Override
    public Response intercept(Chain chain) throws IOException {
        Request originalRequest = chain.request();
        Request requestWithAuth = originalRequest.newBuilder()
                .header("Authorization", "Bearer " + apiKey)
                .header("Content-Type", "application/json")
                .build();
        return chain.proceed(requestWithAuth);
    }
}

然后在构建 OkHttpClient 时添加这个拦截器： clientBuilder.addInterceptor(new AuthenticationInterceptor(apiKey)); 。这样，所有由这个客户端发出的请求都会自动带上认证头。

3.3 错误处理与重试机制

网络调用充满不确定性，完善的错误处理是生产级Starter的必备特性。我们需要考虑：

  • HTTP状态码处理 ：AI服务API通常会返回标准的HTTP状态码，如 401 （未授权）、 429 （请求过多/限流）、 500 （服务器内部错误）等。Starter应该将这些状态码转换为更有意义的运行时异常（如 AuthenticationException , RateLimitException , ServerErrorException ），并向上抛出。
  • 业务错误码处理 ：即使HTTP状态码是200，响应体里也可能包含业务层面的错误信息（如 {"error": {"message": "The model does not exist", "type": "invalid_request_error"}} ）。需要在解析响应JSON时检查是否存在错误字段，并抛出相应的异常。
  • 重试机制 ：对于因网络波动或服务端限流（ 429 ）导致的临时性失败，自动重试可以显著提高成功率。重试逻辑应具备以下特性：
    • 可配置 ：允许用户设置最大重试次数和重试间隔。
    • 退避策略 ：建议使用指数退避（Exponential Backoff）或至少是固定间隔退避，避免加重服务器压力。
    • 条件重试 ：只对特定的异常（如 IOException , RateLimitException ）进行重试，对于认证失败（ 401 ）或请求格式错误（ 400 ）则应立即失败。

实现重试可以借助OkHttp的拦截器，也可以使用专门的库如 resilience4j 或 Spring Retry。对于Starter来说，在拦截器中实现一个简单的固定间隔重试是常见且有效的方式。

3.4 流式响应（Streaming）的支持

对于生成较长文本的场景，流式响应（Server-Sent Events, SSE）能极大地提升用户体验，让用户看到文字逐字生成的过程。OpenAI的API支持通过设置 stream: true 来开启此功能。

支持流式响应会显著增加Starter的复杂度：

  1. 响应解析 ：流式响应不是单个JSON对象，而是一系列以 data: 开头的行，最后以 data: [DONE] 结束。每行 data: 后面是一个独立的JSON对象，包含部分生成结果。
  2. 客户端设计 ：需要提供一种方式，让调用者能够消费这个数据流。在响应式编程中，可以返回一个 Flux<ChatCompletionChunk> （Spring WebFlux）。在命令式编程中，可能需要提供一个回调接口或返回一个 Stream 对象。
  3. 资源管理 ：需要确保在流结束或发生错误时，正确关闭网络连接。

如果 lzhpo/chatgpt-spring-boot-starter 的目标是保持简洁，初期可以不实现流式支持。但如果要追求功能的完备性，这是一个值得投入的高级特性。

4. 实操过程与核心环节实现

4.1 项目引入与基础配置

假设你有一个全新的Spring Boot 3.x项目，集成这个Starter的第一步是在 pom.xml 中添加依赖。 

<dependency>
    <groupId>io.github.lzhpo</groupId>
    <artifactId>chatgpt-spring-boot-starter</artifactId>
    <version>{最新版本号}</version>
</dependency>

接下来，在 application.yml 中进行最小化配置。最关键的是API密钥， 强烈建议不要将密钥硬编码在配置文件中 ，而是通过环境变量注入。 

# application.yml
chatgpt:
  api-key: ${OPENAI_API_KEY} # 从环境变量OPENAI_API_KEY读取
  # 其他配置使用默认值即可

然后在你的操作系统或容器环境中设置环境变量 OPENAI_API_KEY=sk-你的真实密钥 。对于本地开发，可以在IDE的运行配置中设置环境变量，或者使用 .env 文件配合 dotenv 之类的库。

4.2 在Service层中注入并使用客户端

配置完成后，Spring Boot的自动配置机制会为你创建一个 ChatGPTClient 的Bean。你可以在任何Spring管理的组件（如 @Service , @Controller ）中直接注入它。

下面是一个简单的Service示例，它接受用户问题，调用AI，并返回回答： 

@Service
@Slf4j
public class AIChatService {

    @Autowired
    private ChatGPTClient chatGPTClient;

    public String getAnswer(String userQuestion) {
        // 1. 构建请求消息
        ChatMessage userMessage = new ChatMessage("user", userQuestion);
        List<ChatMessage> messages = Collections.singletonList(userMessage);

        // 2. 构建请求对象，使用默认模型或指定模型
        ChatCompletionRequest request = ChatCompletionRequest.builder()
                .model("gpt-3.5-turbo") // 可以覆盖配置文件中的默认值
                .messages(messages)
                .temperature(0.7)
                .maxTokens(500)
                .build();

        // 3. 发起调用
        ChatCompletionResponse response;
        try {
            response = chatGPTClient.chat(request);
        } catch (Exception e) {
            log.error("调用AI服务失败", e);
            // 这里可以根据异常类型进行更精细的处理，如重试、降级等
            return "抱歉，AI服务暂时不可用，请稍后再试。";
        }

        // 4. 解析响应
        if (response.getChoices() != null && !response.getChoices().isEmpty()) {
            ChatChoice choice = response.getChoices().get(0); // 通常取第一个结果
            ChatMessage message = choice.getMessage();
            return message.getContent();
        } else {
            return "未收到有效回复。";
        }
    }
}

这个例子展示了最基本的同步调用。在实际生产中，你可能需要考虑异步调用以避免阻塞主线程，特别是当请求耗时较长时。

4.3 实现一个带上下文记忆的对话场景

单次问答很简单，但真正的对话需要上下文记忆。AI模型本身是无状态的，它需要我们将历史对话作为消息列表的一部分发送过去，模型才能理解上下文。Starter的客户端通常不负责管理对话状态，这部分业务逻辑需要开发者自己实现。

一个简单的实现思路是使用一个 Map<String, List<ChatMessage>> 来存储每个会话（可以用sessionId标识）的历史消息。每次用户发言时，取出该会话的历史消息列表，追加新的用户消息，然后发送给AI。收到AI回复后，再将AI的回复追加到历史列表中，并更新存储。 

@Service
public class ConversationService {
    @Autowired
    private ChatGPTClient client;
    private final Map<String, List<ChatMessage>> sessionHistory = new ConcurrentHashMap<>();

    public String chat(String sessionId, String userInput) {
        // 获取或创建该会话的历史
        List<ChatMessage> history = sessionHistory.computeIfAbsent(sessionId, k -> new ArrayList<>());

        // 添加用户新消息到历史
        history.add(new ChatMessage("user", userInput));

        // 构建请求（发送整个历史）
        ChatCompletionRequest request = ChatCompletionRequest.builder()
                .model("gpt-3.5-turbo")
                .messages(new ArrayList<>(history)) // 发送副本
                .build();

        ChatCompletionResponse response = client.chat(request);
        String aiReply = response.getChoices().get(0).getMessage().getContent();

        // 添加AI回复到历史
        history.add(new ChatMessage("assistant", aiReply));

        // 可选：限制历史长度，防止token超限或内存占用过大
        // keepLastMessages(history, 10);

        return aiReply;
    }

    private void keepLastMessages(List<ChatMessage> messages, int maxCount) {
        if (messages.size() > maxCount) {
            // 保留最后的 maxCount 条，可以根据需要更智能地裁剪（如优先保留system和最近的对话）
            messages.subList(0, messages.size() - maxCount).clear();
        }
    }
}

实操心得 ：管理对话上下文时，需要警惕令牌数（Token）限制。模型有最大上下文长度（例如 gpt-3.5-turbo 是16385个令牌）。历史消息越长，消耗的令牌越多，费用也越高，并且可能超过限制导致请求失败。上述代码中的 keepLastMessages 是一个简单的裁剪策略。更复杂的策略可能涉及总结历史对话、丢弃最早的非关键消息等。

4.4 高级功能：函数调用（Function Calling）的集成

OpenAI等模型提供了函数调用能力，允许模型在对话中请求执行你定义好的函数，并将执行结果返回给模型，从而完成更复杂的任务（如查询天气、操作数据库）。这需要更复杂的交互模式。

  1. 定义函数 ：你需要将你的函数（工具）用JSON Schema描述出来，作为请求的一部分发送给模型。
  2. 模型决策 ：模型根据对话内容，判断是否需要调用函数。如果需要，它会在回复中提供一个包含函数名和参数的 function_call 对象。
  3. 本地执行 ：你的代码解析这个 function_call ，在本地执行对应的Java方法。
  4. 返回结果 ：将函数执行的结果作为一条新的消息（ role: function ）发送给模型，让模型生成面向用户的最终回答。

要在Starter中优雅地支持函数调用，需要扩展请求/响应模型，增加 tools （函数定义列表）和 tool_calls 等字段，并可能提供一个更高级的客户端方法，它接受函数定义和对应的执行器（Java方法引用或回调），自动完成上述循环。这是一个相当高级的特性，如果 lzhpo/chatgpt-spring-boot-starter 实现了它，那将大大提升其竞争力。

5. 常见问题与排查技巧实录

在实际集成和使用过程中，你肯定会遇到各种各样的问题。下面是一些典型问题及其排查思路。

5.1 连接超时或读取超时

  • 现象 ：调用 chat 方法时，抛出 SocketTimeoutException 或 ConnectTimeoutException 。
  • 可能原因与排查 ：
    1. 网络问题 ：你的服务器无法访问AI服务的API地址（如 api.openai.com ）。使用 ping 或 telnet 命令测试网络连通性。
    2. 代理配置 ：如果你需要通过代理访问，请确保在 chatgpt.proxy 配置中正确设置了代理主机和端口。
    3. 超时时间过短 ：生成一个长回复可能需要几十秒。检查你的 chatgpt.read-timeout 配置，适当调大（例如 60s ）。
    4. 服务端问题 ：AI服务提供商可能暂时不可用或响应缓慢。查看其官方状态页面。

5.2 认证失败（401 Unauthorized）

  • 现象 ：调用失败，异常信息提示 401 或 AuthenticationException 。
  • 可能原因与排查 ：
    1. API密钥错误或过期 ：这是最常见的原因。请仔细检查配置的 chatgpt.api-key 值是否正确，是否包含了多余的空白字符。去AI服务商的控制台确认密钥是否有效、是否有额度。
    2. 密钥格式问题 ：某些服务商的密钥可能有特定前缀（如 sk- ），确保完整复制。
    3. 配置未生效 ：确认你的配置属性前缀是否正确（ chatgpt ），以及配置是否被正确加载（可以通过 /actuator/env 端点查看，如果引入了Spring Boot Actuator）。
    4. 环境变量未设置 ：如果你使用 ${VAR} 语法引用环境变量，请确保在运行环境中该变量已正确设置。在Java代码中可以用 System.getenv("VAR") 测试。

5.3 速率限制（429 Too Many Requests）

  • 现象 ：请求频繁失败，返回 429 状态码或 RateLimitException 。
  • 可能原因与排查 ：
    1. 请求频率过高 ：免费或低阶的API套餐有严格的RPM（每分钟请求数）和TPM（每分钟令牌数）限制。你需要降低调用频率。
    2. 未处理重试 ：如果Starter没有内置重试机制，或者重试策略过于激进（立即重试），可能会加剧限流。确保Starter使用了带有退避策略的重试逻辑。
    3. 解决方案 ：
      • 客户端限流 ：在你的业务代码中实现一个限流器（如使用Guava的 RateLimiter ），将请求速率控制在服务商限制之下。
      • 队列与异步处理 ：将AI调用请求放入队列，由后台Worker按可控速率消费。
      • 升级套餐 ：如果业务需求大，考虑升级到更高限制的付费套餐。

5.4 响应解析错误或空回复

  • 现象 ：HTTP请求成功（状态码200），但解析响应体时出错，或者 response.getChoices() 为空。
  • 可能原因与排查 ：
    1. JSON结构不匹配 ：服务商API升级，返回了新的字段或结构，但Starter使用的响应模型类未更新。检查Starter版本是否过时，查看官方API文档对比响应格式。
    2. 模型参数问题 ：某些请求参数可能导致服务端返回一个空或结构异常的响应。尝试使用最简化的请求（只包含 model 和 messages ）进行测试。
    3. 启用日志 ：将Starter或底层HTTP客户端（如OkHttp）的日志级别调到 DEBUG ，查看完整的请求和响应日志，这是最直接的排查手段。你可以在 application.yml 中添加： 
      logging:
  level:
    com.lzhpo.chatgpt: DEBUG # 假设这是Starter的包名
    okhttp3: DEBUG # 如果使用OkHttp
    4. 检查 finish_reason ：响应中每个 Choice 都有一个 finish_reason 字段。如果是 length ，说明生成的回复因达到 max_tokens 限制而被截断，你需要增加 max_tokens 值。如果是 content_filter ，说明生成的内容触发了服务端的内容过滤策略。

5.5 内存泄漏与资源管理

  • 现象 ：应用运行一段时间后，内存占用持续增长，甚至发生OOM（OutOfMemoryError）。
  • 可能原因与排查 ：
    1. HTTP客户端未复用 ：确保 ChatGPTClient 或底层的 OkHttpClient 是单例的，由Spring容器管理。每次调用都创建新的客户端会导致连接池和线程无法释放。
    2. 流式响应未关闭 ：如果使用了流式响应（SSE），务必确保在流结束或发生错误时，正确关闭响应体或断开连接。否则，连接资源会一直占用。
    3. 大对象驻留 ：如果缓存了过长的对话历史（ List<ChatMessage> ），且会话数量很多，可能导致内存堆积。实现会话的LRU淘汰机制或定期清理不活跃的会话。
    4. 使用内存分析工具 ：使用VisualVM、YourKit或Arthas等工具分析堆内存，查看哪些对象实例数量异常多。

5.6 性能优化建议

  1. 连接池 ：确保底层的HTTP客户端（如OkHttp）启用了连接池，并合理设置大小。这能显著减少建立TCP连接的开销。
  2. 异步非阻塞 ：对于高并发场景，考虑使用客户端的异步方法（如 chatAsync ），或者将AI调用封装到 @Async 方法中，避免阻塞Web容器的线程。
  3. 请求批量化 ：如果业务允许，可以将多个独立的、不相关的用户请求合并成一个批处理请求发送给AI（如果API支持的话），但这需要仔细设计。
  4. 本地缓存 ：对于一些常见的、答案固定的问题（如“你是谁？”），可以将AI的回复缓存起来，直接返回，避免不必要的API调用和费用。
  5. 监控与告警 ：对AI调用的耗时、成功率、令牌消耗进行监控。设置告警，当平均响应时间过长或失败率升高时及时通知。这能帮助你发现服务端问题或自身的调用模式问题。

集成 lzhpo/chatgpt-spring-boot-starter 这类工具，最大的价值在于它帮你处理了所有基础设施的复杂性，让你能快速验证想法、构建原型。但在将其用于生产环境时，务必深入理解其原理，做好错误处理、限流降级和监控，这样才能构建出既智能又稳健的应用。

Logo
亚马逊云科技技术品牌专区

更多推荐

open-code-review Codex 插件教程：对话式调用评审技能指南

本文是一份面向新手的 **open-code-review Codex 插件教程**，教你在 Codex 中通过对话式方式调用 open-code-review 的 AI 代码评审技能。open-code-review 是阿里巴巴开源的 AI 代码评审工具，采用"确定性流水线 + LLM Agent"混合架构，内置多语言评审规则（NPE、线程安全、XSS、SQL 注入等），可在 Codex 里用一

avatar 亚马逊云科技技术品牌专区

OBS Studio 完整指南：免费开源录屏与直播软件从零上手

想做一场像模像样的直播，或者把屏幕内容录成教程视频，但一想到商用软件的订阅费就有些犹豫？其实你不需要花一分钱。OBS Studio 是一款免费开源的直播与录屏软件，支持 Windows、macOS 和 Linux，采集、混音、编码、推流、录制，一条流水线全包了。## 先搞清楚 OBS Studio 是什么OBS Studio 是一个"场景化"的采集合成工具：你把摄像头、窗口、浏览器、图片、

avatar 亚马逊云科技技术品牌专区

如何用MediaCrawler爬取小红书抖音数据？7大平台爬虫从安装到实战完整指南

MediaCrawler 是一个支持小红书、抖音、快手、B站、微博、百度贴吧、知乎的开源自媒体数据采集工具。它能按关键词、按帖子、按创作者主页三种方式抓取笔记/视频内容、评论甚至二级评论，并把结果存成 JSON、CSV、Excel 或数据库。适合做市场调研、竞品监控、内容选题的运营人员，以及想要现成爬虫框架而不想从零写 JS 逆向的开发者。## 从一次"手动抄数据"说起想象这个场景：你负责

avatar 亚马逊云科技技术品牌专区