一、前言

DeepSeek 作为国内高性能开源+商用双模式大模型，凭借代码能力强、推理精度高、响应速度快、中文适配优秀、性价比突出的优势，成为 Java 企业级 AI 项目的主流选型。相比于其他大模型，DeepSeek 接口规范简单、适配性广、兼容 SpringAI、原生 SDK 双接入方案，非常适合快速落地智能问答、代码生成、RAG 知识库、业务推理等场景。

本文面向 Java 开发者，从零讲解 DeepSeek 完整接入流程：前置环境准备、项目依赖引入、基础初始化调用、流式调用优化、核心参数配置详解，同时拆解每种调用方式的优缺点、适用场景和配置修改逻辑，看完即可独立完成企业级落地。

二、前置环境准备（零门槛快速搭建）

DeepSeek Java 接入无需复杂本地部署，基于官方开放 API 即可快速调用，仅需完成 4 项前置准备，个人开发、企业测试均可直接复用。

2.1 基础环境要求

  • Java 版本：JDK 17+（SpringAI 最新适配版本）、JDK8 可兼容原生 SDK 接入

  • 项目框架：SpringBoot 2.x / 3.x、普通 Java 工程均可适配

  • 网络环境：可正常访问外网 API 地址，企业内网需放行 api.deepseek.com 域名

2.2 账号与密钥准备（核心前提）

所有 DeepSeek 接口调用必须依赖合法 API Key，步骤如下：

  1. 进入 DeepSeek 开放平台 注册个人/企业账号；

  2. 进入密钥管理页面，新建 API Key，系统会自动生成密钥并赠送体验额度；

  3. 重点注意：API Key 仅展示一次，务必提前复制保存，丢失无法找回；

  4. 企业商用需完成实名认证，解锁更高并发、更高额度与正式商用权限。

2.3 项目依赖引入（两种主流方案）

目前 Java 接入 DeepSeek 有两套标准方案，按需选择：SpringAI 官方适配（推荐企业项目）、原生 SDK（轻量化老项目），本文以最通用的 SpringAI 方案为主，适配绝大多数 Spring 微服务项目。

方案一：SpringAI 官方依赖（首选，标准化、易维护）

适配 SpringBoot3 生态，官方自动装配，零手动初始化，配置简洁、兼容性强。

<dependency>
    <groupId>org.springframework.ai</groupId>
    <artifactId>spring-ai-starter-model-deepseek</artifactId>
    <version>1.0.0-M1</version>
</dependency>
方案二：DeepSeek4j 原生 SDK（轻量化、无框架绑定）

适配老旧 SSM、非 Spring 项目，依赖轻量、无冗余组件，适合简单对接场景。

<dependency>
    <groupId>io.github.plexpt</groupId>
    <artifactId>deepseek4j</artifactId>
    <version>最新版本号</version>
</dependency>

2.4 基础全局配置（yml 统一配置）

统一配置密钥、接口地址、默认模型，避免代码硬编码，方便环境切换与运维管理，同时通过环境变量读取密钥，规避代码泄露风险。

spring:
  ai:
    deepseek:
      api-key: ${DEEPSEEK_API_KEY}  # 环境变量配置，保障密钥安全
      base-url: https://api.deepseek.com/v1  # 官方固定接口地址
      chat:
        options:
          model: deepseek-chat  # 默认模型，可替换为 deepseek-coder 代码模型

三、基础初始化与普通同步调用（入门必学）

普通同步调用是最基础的接入方式，流程简单、代码简洁，适合后台批量处理、离线生成、非实时问答场景。核心逻辑：请求发起后，等待模型完整生成全部内容，一次性返回结果。

3.1 自动初始化原理

引入 SpringAI 依赖并配置 yml 参数后，框架会自动完成模型客户端初始化、连接池创建、鉴权绑定，无需手动 new 客户端、无需手动拼接请求头，直接注入即可使用，极大降低接入成本。

3.2 完整同步调用代码示例

import org.springframework.ai.chat.model.ChatModel;
import org.springframework.ai.chat.prompt.Prompt;
import org.springframework.ai.chat.prompt.PromptTemplate;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RequestParam;
import org.springframework.web.bind.annotation.RestController;

import javax.annotation.Resource;
import java.util.Map;

@RestController
public class DeepSeekChatController {

    // 框架自动注入初始化完成的模型客户端
    @Resource
    private ChatModel deepSeekChatModel;

    @GetMapping("/chat/sync")
    public Map<String, String> syncChat(@RequestParam String message) {
        // 构建提示词
        PromptTemplate promptTemplate = new PromptTemplate("{message}");
        Prompt prompt = promptTemplate.create(Map.of("message", message));
        // 同步调用，等待完整结果返回
        String result = deepSeekChatModel.call(prompt).getResult().getOutput().getContent();
        return Map.of("result", result);
    }
}

3.3 普通同步调用优缺点

✅ 优点

  • 代码极简、零学习成本、无需处理流式数据解析；

  • 结果完整返回，无需拼接分段数据，业务处理简单；

  • 适合离线任务、批量文档总结、后台数据处理场景。

❌ 缺点

  • 响应阻塞，用户需等待全部内容生成完毕才能看到结果，体验卡顿；

  • 长文本生成场景超时概率高，极易触发接口超时、连接断开；

  • 占用服务线程，高并发下线程容易耗尽，吞吐量极低。

适配场景：后台离线任务、批量数据处理、非实时业务生成、简单内部工具。

四、流式调用实现与深度优化（C端用户必备）

针对前端实时对话、智能客服、在线问答等 C 端场景，同步调用体验极差，必须使用流式调用（Stream）。流式调用是大模型落地用户交互场景的核心方案，也是企业 AI 项目必备优化手段。

4.1 流式调用核心作用

普通同步调用是「全量生成后一次性返回」，流式调用是模型逐字、逐段实时推送 Token，服务端分段推送、前端实时渲染，实现类似 ChatGPT 的打字机效果。核心价值：

  • 彻底解决长文本接口超时问题，拆分大数据量为分段小数据；

  • 用户无需等待，秒级看到首字响应，交互体验大幅提升；

  • 服务端不阻塞线程，基于 Reactor 响应式编程，高并发吞吐量更高。

4.2 流式调用完整代码实现

基于 SpringAI + WebFlux 响应式流式推送，标准 SSE 协议，前端可直接监听渲染。

import org.springframework.ai.chat.model.ChatModel;
import org.springframework.ai.chat.prompt.Prompt;
import org.springframework.ai.chat.prompt.PromptTemplate;
import org.springframework.http.MediaType;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RequestParam;
import org.springframework.web.bind.annotation.RestController;
import reactor.core.publisher.Flux;

import javax.annotation.Resource;
import java.util.Map;

@RestController
public class DeepSeekStreamController {

    @Resource
    private ChatModel deepSeekChatModel;

    // 声明SSE流式响应协议
    @GetMapping(value = "/chat/stream", produces = MediaType.TEXT_EVENT_STREAM_VALUE)
    public Flux<String> streamChat(@RequestParam String message) {
        PromptTemplate promptTemplate = new PromptTemplate("{message}");
        Prompt prompt = promptTemplate.create(Map.of("message", message));
        // 流式返回，逐段推送内容
        return deepSeekChatModel.stream(prompt)
                .map(chatResponse -> chatResponse.getResult().getOutput().getContent());
    }
}

4.3 流式调用优缺点深度拆解

✅ 核心优点

  • 首响应极快：无需等待全文生成，毫秒级推送首段内容，解决用户等待焦虑；

  • 杜绝超时问题：长文本、万字文档生成全程分段推送，规避 HTTP 超时限制；

  • 并发性能更强：响应式非阻塞模型，同等服务器资源支撑更多并发对话；

  • 用户体验最优：适配所有在线实时交互场景，是商用 AI 产品标配。

❌ 缺点

  • 前后端对接复杂度提升，前端需要监听 SSE 流、拼接分段数据、处理异常中断；

  • 服务端需要维护流式连接，长连接过多会占用连接资源；

  • 不适合离线批量处理场景，仅适配实时交互业务。

4.4 企业级流式优化方案

原生流式调用存在连接堆积、异常断连、重复推送问题，落地需做三层优化：

  1. 流式超时熔断：设置单对话最大流式时长，空闲自动断开连接，释放服务资源；

  2. 异常重连兜底：前端监听断连事件，自动重连并接续上下文，避免对话中断；

  3. 内容去重拼接：针对模型分段重复推送问题，后端做内容去重，前端高效拼接。

适配场景：智能客服、在线问答、AI 对话助手、实时文案生成、前端交互式 AI 功能。

五、DeepSeek 深度思考模式完整实战

5.1 什么是深度思考模式（CoT 思维链）

普通对话模型：收到问题后直接输出答案，复杂多步骤问题容易跳步骤、逻辑断层、出现幻觉。 深度思考模式：模型内部先分步拆解问题、推导演算、校验逻辑，将推理内容（reasoning_content） 单独返回，再输出最终回复content。 接口返回双层结构：

  1. reasoning_content：模型思考、演算、推导全过程（可前端展示、后台留存用于溯源）

  2. content：最终总结答案

5.1.1 控制思考模式核心 API 参数

参数

取值

作用

thinking.type

enabled / disabled

全局开关，启用 / 关闭深度思考

reasoning_effort

high / max

推理强度：high 标准推理，max 极致推理（耗时更长、准确率更高）

extra_body

{"thinking":{...}}

SpringAI 中透传自定义扩展参数

5.2 两种模型开启思考的区别

  1. deepseek-reasoner（推理专用模型） 默认thinking.type=enabled，无需手动传参，响应天然携带reasoning_content，复杂数学、代码、逻辑题首选。

  2. deepseek-chat（通用对话模型） 默认关闭思考，必须在请求扩展参数手动传入thinking: enabled才会输出推理过程，适合简单文案、闲聊场景按需开启。

5.3 同步调用实战（获取思考过程 + 最终答案）

5.3.1 基础同步代码
import org.springframework.ai.chat.model.ChatModel;
import org.springframework.ai.chat.prompt.Prompt;
import org.springframework.ai.chat.prompt.PromptTemplate;
import org.springframework.ai.model.deepseek.DeepSeekAssistantMessage;
import org.springframework.ai.model.deepseek.DeepSeekChatOptions;
import javax.annotation.Resource;
import java.util.Map;

@RestController
@RequestMapping("/deepseek/reason")
public class DeepSeekReasonController {

    @Resource
    private ChatModel deepSeekChatModel;

    @GetMapping("/sync")
    public Map<String, Object> reasonSync(@RequestParam String question) {
        PromptTemplate template = new PromptTemplate("{question}");
        Prompt prompt = template.create(Map.of("question", question));

        // 构建扩展参数：开启深度思考、拉满推理强度
        DeepSeekChatOptions options = DeepSeekChatOptions.builder()
                .extraBody(Map.of(
                        "thinking", Map.of("type", "enabled"),
                        "reasoning_effort", "max"
                ))
                .build();
        Prompt fullPrompt = new Prompt(prompt.getInstructions(), options);

        // 发起底层API请求
        var chatResponse = deepSeekChatModel.call(fullPrompt);
        // 核心分层获取：getOutput()是SpringAI标准封装入口
        DeepSeekAssistantMessage message = (DeepSeekAssistantMessage) chatResponse.getResult().getOutput();

        // 分别拿到思考过程、最终回答
        String reasoning = message.getReasoningContent();
        String answer = message.getContent();

        return Map.of(
                "reason_content", reasoning,
                "final_answer", answer
        );
    }
}
5.3.2 执行返回结构示例
{
  "reason_content": "1.先拆解问题：计算1-100所有奇数之和...2.推导等差数列公式...3.代入数值计算总和...",
  "final_answer": "1到100奇数总和为2500"
}

5.4 流式深度思考实战（SSE 打字机分段输出思考）

流式场景下，reasoning_content与content会分段逐块推送，前端可分区域实时展示「思考区」和「答案区」，用户体验更强。

@GetMapping(value = "/stream", produces = MediaType.TEXT_EVENT_STREAM_VALUE)
public Flux<String> streamReason(@RequestParam String question) {
    PromptTemplate template = new PromptTemplate("{question}");
    Prompt prompt = template.create(Map.of("question", question));
    DeepSeekChatOptions options = DeepSeekChatOptions.builder()
            .extraBody(Map.of("thinking", Map.of("type", "enabled")))
            .stream(true)
            .build();
    Prompt fullPrompt = new Prompt(prompt.getInstructions(), options);

    // 流式流处理，分段读取思考+内容
    return deepSeekChatModel.stream(fullPrompt)
            .map(resp -> {
                DeepSeekAssistantMessage msg = (DeepSeekAssistantMessage) resp.getResult().getOutput();
                // 拼接分段思考与文本
                StringBuilder sb = new StringBuilder();
                if (msg.getReasoningContent() != null) {
                    sb.append("【推理过程】").append(msg.getReasoningContent());
                }
                if (msg.getContent() != null) {
                    sb.append("\n【结论】").append(msg.getContent());
                }
                return sb.toString();
            });
}

5.5 深度思考模式优缺点与业务选型

✅ 优势

  1. 复杂问题准确率大幅提升：数学、算法、业务逻辑推导、财务计算、代码 Debug 场景减少幻觉；

  2. 推理过程可溯源，用于客服、审计、知识库场景可追溯模型判断依据；

  3. 推理强度可自定义，兼顾速度与精度（high 快速推理 /max 极致严谨）；

  4. 流式下思考与答案分开推送，前端分层展示交互效果更好。

❌ 缺点

  1. Token 消耗翻倍：思考内容会额外计费，同等问题成本高于普通对话；

  2. 响应延迟更高：模型需要额外运算推理步骤，简单问答场景没必要开启；

  3. 多轮对话上下文限制：历史消息不能携带reasoning_content字段，否则接口返回 400 报错，业务需手动过滤推理文本再拼接上下文。

适配场景（什么时候必须开深度思考）

  • 代码生成、Bug 修复、算法解题；

  • 财务、风控、法律咨询等严谨推理业务；

  • RAG 知识库复杂多条件问答；

  • 数学计算、逻辑证明、数据统计分析。

不建议开启场景

  • 简单闲聊、短文案生成、商品介绍等无逻辑推导需求；

  • 高并发实时客服、毫秒级低延迟需求系统。

5.6 关键落地避坑点

  1. 多轮对话存储上下文时，必须丢弃 reasoning_content，只保留用户消息 + 最终 content；

  2. 普通deepseek-chat频繁开 max 推理会显著提升成本，默认用 high 即可；

  3. 流式场景需要做判空处理，部分分片只会返回推理、部分只返回答案，避免前端空白；

  4. 不需要推理的接口统一在 options 关闭thinking.type=disabled，节约 Token。

六、SpringAI 请求底层原理：完整链路 + getOutput () 深度拆解

6.1 SpringAI 整体分层架构（调用链路总览）

业务代码 call(prompt)
    ↓
DeepSeekChatModel#call() 实现类（统一适配层）
    ↓
1. createRequest：SpringAI通用Prompt → DeepSeek原生API请求体转换（适配器模式）
    ↓
2. HTTP网络请求（带重试、超时、鉴权、限流捕获）
    ↓
3. 接收DeepSeek原始JSON响应
    ↓
4. parseResponse：原生JSON → SpringAI统一ChatResponse模型
    ↓
外层获取：chatResponse.getResult().getOutput()

核心三层对象定义：

  1. ChatResponse：顶层响应包装，包含全部元数据（token 消耗、模型 ID、结束原因）

  2. Generation：单次生成结果（getResult()返回此对象）

  3. AssistantMessage：模型输出消息（getOutput()返回，DeepSeek 专属子类携带 reasoning_content）

6.2 getOutput () 逐层源码执行逻辑

6.2.1 第一层：chatResponse.getResult ()

返回Generation对象，代表模型一轮完整生成结果，内部封装：

  • 模型输出消息（AssistantMessage）

  • 生成元数据：消耗 token、finish_reason、模型名称

6.2.2 第二层：generation.getOutput ()

核心方法，源码逻辑：

public AssistantMessage getOutput() {
    return this.outputMessage;
}

作用：提取 AI 完整输出消息对象，通用 SpringAI 顶层抽象，兼容 OpenAI/DeepSeek/ 通义千问所有模型。

  • 通用场景：AssistantMessage仅提供getContent()获取文本；

  • DeepSeek 扩展：强转为DeepSeekAssistantMessage后，新增getReasoningContent()专属方法读取思考过程。

6.3 完整数据映射流程（API 返回 → getOutput ()）

  1. DeepSeek 原始 HTTP 响应 JSON 字段：

{
  "choices": [
    {
      "message": {
        "reasoning_content": "推导过程",
        "content": "最终答案",
        "role": "assistant"
      }
    }
  ],
  "usage": {"prompt_tokens": 100, "completion_tokens": 200}
}

  1. SpringAI 底层解析器（DeepSeekResponseConverter）自动映射：

  • message.content → AssistantMessage 基础 content

  • message.reasoning_content → DeepSeekAssistantMessage 扩展字段

  • usage 消耗存入ChatResponseMetadata

  1. 上层调用链路： chatResponse.getResult()拿到 Generation → .getOutput()拿到消息对象 → 强转后读取思考 / 答案

6.4 同步调用底层完整执行步骤（代码逻辑拆解）

  1. 参数适配转换 传入业务层Prompt（用户提问、自定义 options），框架通过DeepSeekChatOptions读取extra_body中的 thinking、reasoning_effort 参数，组装为符合 DeepSeek 规范的 HTTP 请求体。

  2. 网络通信层 内置 RestTemplate/WebClient，自动填充 Header 鉴权Authorization: Bearer {api-key}，配置全局超时、指数退避重试（429 限流、5xx 服务异常自动重试）。

  3. 接收服务商 JSON 响应，捕获异常：限流、密钥错误、额度不足、模型不存在统一封装为 SpringAI 标准异常。

  4. 反向序列化映射 将服务商私有字段reasoning_content存入 DeepSeek 专属消息子类，通用 content 存入父类。

  5. 封装统一ChatResponse对外暴露，屏蔽各厂商 API 差异，实现模型无感切换。

6.5 流式调用 getOutput 差异点

流式 Flux每一个分片都独立执行一次完整映射：

  • 每个 SSE 数据包单独封装 ChatResponse；

  • getOutput()每次返回增量片段，思考、答案分段分开；

  • 业务侧需要自行拼接全量推理文本与最终答案。

6.6 为什么 SpringAI 要设计 getOutput 这种分层封装？

  1. 多模型统一抽象 不管是 DeepSeek、OpenAI、文心一言，都统一使用getResult().getOutput().getContent()获取基础文本，切换模型无需修改业务代码。

  2. 厂商扩展字段隔离 通用逻辑走标准接口，DeepSeek 专属思考过程、字节专属工具返回等扩展能力通过子类实现，不破坏顶层统一 API。

  3. 元数据解耦 token 消耗、结束原因、模型标识等信息放在顶层 ChatResponse，业务按需读取，不与输出文本耦合。

  4. 分层容错设计 可单独判断 Generation 是否生成成功，再读取 Output，空响应、截断场景方便做兜底处理。

七、DeepSeek 通用可配置项全解析（企业调优核心）

很多开发者接入模型后效果差、输出不稳定、随机性高、字数超限，核心原因是未根据业务场景修改模型参数。DeepSeek 提供全套可自定义参数，每一项参数都对应明确的业务优化方向，下面列举所有高频核心配置、修改作用、适用场景，可直接按需配置。

7.1 model（模型名称）

  • 可配置值：deepseek-chat（通用对话）、deepseek-coder（代码专用）

  • 配置作用：切换模型赛道，精准匹配业务场景

  • 选型逻辑：业务问答、文案写作用 chat 模型；代码生成、Bug 修复、工程重构用 coder 模型，杜绝大材小用或能力不足。

7.2 temperature（温度系数，核心控参）

  • 取值范围：0～1，默认 0.7

  • 配置作用：控制模型输出的随机性、创造性

  • 场景适配： 0.1～0.3：极低随机，答案固定、严谨，适合知识库问答、数据推理、专业答题； 0.5～0.7：均衡模式，适合日常对话、文案生成； 0.8～1.0：高创造、高随机，适合创意写作、头脑风暴、营销文案。

7.3 max_tokens（最大生成 Token 数）

  • 配置作用：限制模型单次输出最大字数，避免无限生成、超时、资源浪费

  • 场景适配：简短问答设置 512/1024；长文档总结、报告生成设置 2048/4096；超长业务文档可按需扩容。

  • 优化价值：精准控制流量成本，避免无效长文本导致的计费超标。

7.4 top_p（核采样阈值）

  • 取值范围：0～1，默认 0.9

  • 配置作用：控制模型候选词筛选范围，辅助控制随机性

  • 调优逻辑：追求精准答案调小 top_p；追求内容丰富度调大 top_p，常与 temperature 搭配使用。

7.5 presence_penalty / frequency_penalty（重复惩罚系数）

  • 配置作用：抑制模型重复语句、重复段落、循环赘述问题

  • 场景适配：长文本生成、报告写作、对话上下文场景，适当调高惩罚系数，大幅提升内容质量。

7.6 stream（流式开关）

  • 配置值：true / false

  • 作用：全局开启/关闭流式响应，统一项目调用模式

  • 规范：C端交互开启 true，后台离线任务关闭 false。

7.7 timeout（请求超时时间）

  • 配置作用：自定义接口超时时间，解决长文本生成超时报错

  • 调优逻辑：短问答默认 30s，长文档生成调整为 60s/120s，适配业务复杂度。

7.8 完整参数配置示例（还有一些额外的配置就没单独赘述，只是在配置文件中点明）

  ai:
    deepseek:
      api-key: ${DEEPSEEK_API_KEY}  # 环境变量配置，保障密钥安全
      base-url: https://api.deepseek.com/v1  # 官方固定接口地址
      options:
        model: deepseek-chat  # 默认模型，可替换为 deepseek-coder 代码模型
        #温度系数 控制模型输出的随机性、创造性
        temperature: 0.3
        #最大生成 Token数 限制模型单次输出最大字数，避免无限生成、超时、资源浪费
        max-tokens: 2048
        #核采样阈值 控制模型候选词筛选范围，辅助控制随机性 追求精准答案调小 top_p；追求内容丰富度调大 top_p，常与 temperature 搭配使用
        top-p: 0.4
        #流式开关
        stream: true
        #请求超时时间
        timeout: 60000
        #thinking.type：enabled 开启思考，disabled 关闭
        thinking:
          type: enabled
        #high/max，控制推理详细程度
        reasoning_effort: high
        #承载所有厂商私有扩展参数（思考、工具调用等）
        # extra_body 自定义扩展参数，map格式
        extra-body:
          enable_search: true    # 开启联网搜索（DeepSeek专属扩展）
          search_options:
            search_mode: auto
            search_result_num: 3
          cache_enabled: false
          reasoning_depth: high  # R1深度思考扩展参数

八、同步 VS 流式调用 最终选型总结

调用方式

核心优势

短板问题

适用业务场景

普通同步调用

代码简单、无需数据拼接、稳定性高、易排查问题

阻塞线程、长文本易超时、用户体验差、并发低

后台离线处理、批量总结、内部工具、非实时业务

流式调用

秒级响应、无超时问题、高并发、用户体验极佳

前后端对接复杂、需处理流数据拼接与断连

智能客服、在线对话、C端交互式AI、实时文案生成

九、全文总结与落地心法

DeepSeek Java 接入的核心落地思维可以总结为 一套环境、两种调用、按需配参、场景适配：

1、环境极简：依托 SpringAI 自动装配，无需手动初始化客户端，仅需配置密钥与基础参数，5 分钟即可完成接入；

2、调用分层：后台离线用同步调用，简化开发、稳定可靠；C 端交互用流式调用，优化体验、提升并发；

3、参数精细化调优：不要使用默认参数上线，根据业务严谨度、内容长度、创意需求调整 temperature、max_tokens 等核心参数，是提升模型效果、控制成本的关键；

4、性能取舍：流式解决体验与超时问题，参数调优解决输出质量问题，分层调用解决并发与稳定性问题，三者结合即可实现企业级稳定落地。

整套方案适配 99% 的 Java 企业 AI 场景，无论是简单的智能问答，还是复杂的 RAG 知识库、代码助手、业务推理系统，均可在此基础上快速迭代扩展。

# java # 开发语言
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 亚马逊云科技技术品牌专区