1. 项目概述：从点击到思考，前端工程师的AI流式输出实践

作为一名在前端领域摸爬滚打了十多年的老兵，我亲眼见证了从jQuery到三大框架，再到如今Serverless、低代码的浪潮。最近两年，AI的冲击波终于从前沿实验室，实实在在地拍到了我们每一个开发者的工位上。不再是“未来可期”，而是“现在就得会”。很多前端兄弟开始焦虑：是不是要被替代了？我的答案是：恰恰相反，这是前端能力边界一次史诗级的扩展。我们最擅长的，不就是把数据和逻辑，以优雅、实时、交互的方式呈现给用户吗？AI，尤其是大语言模型，为我们提供了前所未有的“智能数据源”。

今天要聊的这个“前端转型AI，实现流式输出”项目，就是一次非常具体的能力跃迁尝试。它不是一个宏大的理论研究，而是一个聚焦于“流式输出”这个具体技术点的实战演练。想象一下，你不再需要等待一个完整的AI回复全部生成完毕，再一股脑地塞给用户一个巨大的文本块。相反，回复可以像聊天一样，一个字一个字、一个词一个词地“流”到页面上。这种体验的丝滑度，对于构建类ChatGPT应用、智能客服、代码辅助工具等场景，是质的飞跃。这背后，是前端工程师对 HTTP流（Streaming） 、 Server-Sent Events (SSE) 或 WebSocket 等实时通信技术的深度应用，以及对后端AI服务API调用方式的重新理解。接下来，我会把我从零搭建一个具备流式输出能力的AI对话前端的完整过程、踩过的坑和核心心得，毫无保留地分享给你。

2. 核心思路与技术选型：为什么是SSE？

当我们决定要做一个流式输出的AI前端时，摆在面前的第一道选择题就是：用什么技术来实现“流”？

2.1 技术方案对比：SSE vs. WebSocket vs. 长轮询

首先排除长轮询（Long Polling），它是一种在流式技术不普及时期的妥协方案，效率低、延迟高，不适合我们这种对实时性要求高的场景。真正的角逐在SSE和WebSocket之间。

WebSocket 大家都很熟悉，全双工通信，能双向实时传递数据，功能强大。像在线游戏、协同编辑、实时弹幕，它是首选。但它的强大也带来了复杂：你需要自己管理连接、定义消息协议、处理心跳和重连，服务端也要有相应的WebSocket服务支持。

Server-Sent Events 可能很多前端同学相对陌生。它是一种允许服务器主动向客户端推送数据的HTML5技术。关键点在于：它是 单向 的（服务器到客户端），基于普通的HTTP协议。这意味着什么？

  1. 简单至极 ：客户端使用标准的 EventSource API 连接，服务端只需要返回一个 Content-Type: text/event-stream 的HTTP响应，并按照特定格式（ data: 开头）流式写入数据即可。
  2. 天然兼容 ：因为基于HTTP，所以几乎不需要改造现有的网络基础设施（防火墙、代理通常对HTTP更友好），后端现有的AI服务接口稍作改造就能支持。
  3. 自动重连 ： EventSource 内置了连接管理和自动重连机制，省去了我们自己写心跳包的麻烦。

对于“AI流式输出”这个场景——本质上就是客户端发起一个请求，然后服务器持续不断地推送生成的文本片段——SSE的“单向服务器推送”特性完美匹配。我们不需要客户端频繁地向服务器发送数据（除了最初的请求），我们需要的是稳定、高效地接收一个持续的数据流。

注意 ：如果你的应用场景后续需要复杂的双向交互（比如在生成过程中实时调整参数），那么WebSocket可能更合适。但对于绝大多数“一问一答”的流式输出，SSE的简洁和高效是压倒性优势。

所以，我的技术选型非常明确： 前端使用 EventSource 连接，后端AI服务（或中间层）提供SSE接口 。这个组合能让我们用最小的代价，最快地实现目标。

2.2 前端架构设计：状态管理与UI更新

确定了通信协议，接下来要设计前端如何优雅地处理这个数据流。

核心挑战在于：数据是分片、异步、持续到达的。我们不能简单地把所有片段用 += 拼接到一个字符串里，然后频繁地重写整个DOM节点，那会非常低效且可能导致页面闪烁。

我的方案是：

  1. 状态集中管理 ：使用 React（Vue同理）的状态管理。定义一个状态，比如 messageStream ，来存储当前流式回复的 完整内容 。
  2. 增量更新 ：当通过 EventSource 收到一个新的数据片段（ chunk ）时，不是替换整个状态，而是执行 setMessageStream(prev => prev + chunk) 。这能确保React进行高效的差异比对（Diffing）。
  3. UI绑定 ：将 messageStream 状态绑定到UI组件（如一个 <div> 或 <pre> 标签）。React的状态更新会触发UI的重新渲染，但由于是增量追加，浏览器可以非常高效地只更新文本中新增的部分。
  4. 辅助功能 ：还需要管理加载状态（ isLoading ）、错误状态（ error ），以及一个用于中断请求的控制器（ AbortController ）。

这个架构清晰地将数据流、状态和视图分离，是构建稳定流式应用的基础。

3. 前端核心实现：从连接到渲染

理论说完了，我们上代码。这里以React函数组件为例，因为Hooks的写法更直观。

3.1 建立SSE连接与处理数据流

首先，我们需要一个函数来处理发送消息和建立流式连接。

import { useState, useRef } from 'react';

function ChatApp() {
  const [inputText, setInputText] = useState('');
  const [messages, setMessages] = useState([]); // 存储对话历史
  const [isStreaming, setIsStreaming] = useState(false);
  const [currentStream, setCurrentStream] = useState(''); // 当前正在流式接收的消息
  const eventSourceRef = useRef(null); // 用于保存EventSource实例

  const handleSendMessage = async () => {
    if (!inputText.trim() || isStreaming) return;

    // 1. 将用户消息加入历史
    const userMessage = { role: 'user', content: inputText };
    setMessages(prev => [...prev, userMessage]);
    setInputText('');
    setIsStreaming(true);
    setCurrentStream(''); // 清空当前流

    // 2. 如果有旧的连接，先关闭
    if (eventSourceRef.current) {
      eventSourceRef.current.close();
    }

    // 3. 构建请求参数，这里假设后端需要对话历史
    const payload = {
      messages: [...messages, userMessage], // 包含最新用户消息的历史
      stream: true // 明确要求流式输出
    };

    // 4. 将参数编码为URL查询字符串（SSE GET请求更常见）或使用POST + 特殊端点
    // 这里演示GET方式，实际项目可能用POST
    const queryParams = new URLSearchParams({ q: inputText }).toString();
    const sseUrl = `https://your-ai-backend.com/stream?${queryParams}`;

    try {
      // 5. 创建EventSource连接
      const eventSource = new EventSource(sseUrl);
      eventSourceRef.current = eventSource;

      // 6. 监听消息事件
      eventSource.onmessage = (event) => {
        // 假设后端返回的数据格式是 { data: "文本片段" } 或直接是文本
        const chunk = event.data;
        // 处理可能的特殊标记，如 [DONE] 表示结束
        if (chunk === '[DONE]') {
          eventSource.close();
          // 将完整的流式消息存入历史
          setMessages(prev => [...prev, { role: 'assistant', content: currentStream }]);
          setCurrentStream('');
          setIsStreaming(false);
          eventSourceRef.current = null;
          return;
        }
        // 增量更新当前流式内容
        setCurrentStream(prev => prev + chunk);
      };

      // 7. 监听错误事件
      eventSource.onerror = (error) => {
        console.error('EventSource failed:', error);
        eventSource.close();
        setIsStreaming(false);
        // 可以选择将已接收的部分存入历史，并标记为不完整
        if (currentStream) {
          setMessages(prev => [...prev, { role: 'assistant', content: currentStream + '（响应中断）' }]);
        }
        setCurrentStream('');
        eventSourceRef.current = null;
      };

    } catch (error) {
      console.error('Failed to create EventSource:', error);
      setIsStreaming(false);
    }
  };

  // 8. 中断流式请求的函数
  const handleStopStreaming = () => {
    if (eventSourceRef.current) {
      eventSourceRef.current.close();
      eventSourceRef.current = null;
      setIsStreaming(false);
      if (currentStream) {
        setMessages(prev => [...prev, { role: 'assistant', content: currentStream + '（已停止）' }]);
        setCurrentStream('');
      }
    }
  };

  // ... UI渲染部分
}

代码关键点解析：

  • EventSource 对象 ：核心API。传入SSE端点URL即可创建连接。它默认会监听名为 message 的事件。
  • onmessage 事件 ：每当服务器发送一个数据块时触发。 event.data 包含了该块的内容。我们需要在这里进行累加。
  • 流式结束标记 ：像OpenAI的API，会在流式响应结束时发送一个特殊的 data: [DONE] 消息。我们需要检测这个标记来正确地关闭连接并完成消息的保存。
  • 错误处理 ( onerror ) ：网络中断、服务器错误等都会触发。 非常重要 的是，一旦发生错误， EventSource 会自动尝试重连（这是它的默认行为）。但有时我们希望在错误时完全停止，所以需要手动调用 close() 并更新状态。
  • 引用 ( useRef ) ：用于保存 EventSource 实例，以便在组件不同生命周期（如发送新消息、组件卸载）中能够访问和控制它。
  • 中断控制 ：提供了 handleStopStreaming 函数，允许用户主动停止生成。这对于生成长文本时控制成本或纠正错误提问非常有用。

3.2 UI渲染与优化体验

流式接收数据只是第一步，如何优雅地展示给用户同样关键。

// 接上面的组件代码
return (
  <div className="chat-container">
    <div className="messages-list">
      {messages.map((msg, idx) => (
        <div key={idx} className={`message ${msg.role}`}>
          {msg.content}
        </div>
      ))}
      {/* 关键：单独渲染当前正在流式接收的消息 */}
      {isStreaming && currentStream && (
        <div className="message assistant streaming">
          {currentStream}
          {/* 可以添加一个闪烁的光标，增强“正在输入”的视觉效果 */}
          <span className="blinking-cursor">▌</span>
        </div>
      )}
    </div>
    <div className="input-area">
      <textarea
        value={inputText}
        onChange={(e) => setInputText(e.target.value)}
        onKeyDown={(e) => e.key === 'Enter' && !e.shiftKey && handleSendMessage()}
        disabled={isStreaming}
        placeholder={isStreaming ? 'AI正在思考...' : '输入您的问题...'}
      />
      <button onClick={handleSendMessage} disabled={isStreaming || !inputText.trim()}>
        发送
      </button>
      {isStreaming && (
        <button onClick={handleStopStreaming} className="stop-button">
          停止生成
        </button>
      )}
    </div>
  </div>
);

UI设计要点：

  1. 分离渲染 ：不要将流式中的消息（ currentStream ）和已完成的历史消息（ messages ）混在一起渲染。将它们分开，可以避免在流式更新时触发整个历史消息列表的重渲染，提升性能。
  2. 视觉反馈 ：
    • 禁用输入 ：在流式响应期间，禁用输入框和发送按钮，防止用户连续发送。
    • 加载状态 ：通过 isStreaming 状态改变按钮文字或输入框占位符。
    • 光标动画 ：在流式消息末尾添加一个闪烁的光标，能极大地提升“实时生成”的感知，让体验更接近真人聊天。这只需要一点CSS即可实现： 
      .blinking-cursor {
  display: inline-block;
  width: 1ch;
  animation: blink 1s step-end infinite;
  margin-left: 2px;
}
@keyframes blink {
  0%, 100% { opacity: 1; }
  50% { opacity: 0; }
}
  3. 提供控制权 ：“停止生成”按钮是必须的。它赋予了用户控制感，特别是在AI“胡言乱语”或生成方向错误时，可以及时止损。

3.3 处理复杂数据格式与错误边界

上面的例子假设后端返回的是纯文本片段。但在实际中，尤其是使用类似OpenAI的API时，返回的可能是结构化的JSON数据块。

eventSource.onmessage = (event) => {
  try {
    // 解析JSON数据块
    const parsed = JSON.parse(event.data);
    // OpenAI格式示例: { choices: [{ delta: { content: "hi" } }] }
    const chunkContent = parsed.choices?.[0]?.delta?.content || '';
    if (chunkContent) {
      setCurrentStream(prev => prev + chunkContent);
    }
    // 检查是否结束
    if (parsed.choices?.[0]?.finish_reason) {
      // 处理结束逻辑
    }
  } catch (e) {
    // 如果不是JSON，可能直接是文本或结束标记
    if (event.data === '[DONE]') {
      // 结束逻辑
    } else {
      // 当作纯文本处理
      setCurrentStream(prev => prev + event.data);
    }
  }
};

此外，一定要做好 错误边界 处理。SSE连接可能因为网络波动、服务器超时、认证失败等原因中断。除了 onerror 事件，还要考虑在组件卸载时清理连接，防止内存泄漏。

useEffect(() => {
  // 组件卸载时清理
  return () => {
    if (eventSourceRef.current) {
      eventSourceRef.current.close();
    }
  };
}, []);

4. 后端接口协作与模拟

前端写得再漂亮，也需要后端配合。作为前端，我们至少需要知道一个“合格”的SSE接口长什么样，甚至能在开发初期自己模拟一个。

4.1 理想的SSE接口规范

一个良好的AI流式SSE接口应该：

  • 响应头 ： Content-Type: text/event-stream 、 Cache-Control: no-cache 、 Connection: keep-alive 。
  • 数据格式 ：每个消息以 data: 开头，后跟实际数据（可以是JSON字符串或纯文本），以两个换行符 \n\n 结束。例如： 
    data: {"token": "Hello"}\n\n
data: {"token": " world"}\n\n
data: [DONE]\n\n
  • 心跳 ：为了保持连接活跃，防止代理或负载均衡器超时断开，服务器应定期发送注释行（以 : 开头），如 : keepalive\n\n 。
  • 错误处理 ：如果发生错误，可以发送一个包含错误信息的 data 事件，然后关闭流。

4.2 前端开发环境模拟（Mock）

在后端接口就绪前，我们可以用Node.js（或浏览器）快速模拟一个SSE服务，用于前端联调。

// server/mock-sse.js (使用Node.js + Express)
const express = require('express');
const app = express();

app.get('/api/stream', (req, res) => {
  // 设置SSE必需的响应头
  res.setHeader('Content-Type', 'text/event-stream');
  res.setHeader('Cache-Control', 'no-cache');
  res.setHeader('Connection', 'keep-alive');
  res.setHeader('Access-Control-Allow-Origin', '*'); // 开发环境允许跨域

  const question = req.query.q || '';
  const simulatedResponse = `这是关于“${question}”的模拟流式回复。`;
  const words = simulatedResponse.split('');

  // 每隔一段时间发送一个字
  let index = 0;
  const intervalId = setInterval(() => {
    if (index < words.length) {
      // 发送数据，格式必须为 `data: <内容>\n\n`
      res.write(`data: ${JSON.stringify({ content: words[index] })}\n\n`);
      index++;
    } else {
      // 发送结束标记
      res.write('data: [DONE]\n\n');
      clearInterval(intervalId);
      res.end(); // 结束响应
    }
  }, 100); // 每100毫秒发送一个字符

  // 客户端断开连接时清理定时器
  req.on('close', () => {
    clearInterval(intervalId);
    console.log('Client closed connection.');
  });
});

app.listen(3001, () => console.log('Mock SSE server running on port 3001'));

运行这个脚本，前端就可以连接到 http://localhost:3001/api/stream?q=你的问题 进行流式交互测试了。这个模拟服务虽然简单，但完全具备了SSE的核心特征，能让你在前端完整地走通整个流式逻辑。

5. 性能优化与高级技巧

当基础功能跑通后，我们需要关注性能和体验的细节。

5.1 防抖与渲染优化

在极快的流式传输下（比如每秒几十个token），如果每次收到一个字符就更新一次React状态并触发渲染，可能会导致页面卡顿。虽然React的Diff算法很高效，但过于频繁的更新仍有成本。

优化策略：缓冲更新 我们可以引入一个缓冲区（buffer），累积一小段时间或一小段长度的数据后再一次性更新状态。

const [currentStream, setCurrentStream] = useState('');
const bufferRef = useRef(''); // 使用ref作为缓冲区，避免状态更新
const updateTimerRef = useRef(null);

eventSource.onmessage = (event) => {
  const chunk = event.data; // 假设是纯文本
  bufferRef.current += chunk;

  // 清除之前的定时器
  if (updateTimerRef.current) {
    clearTimeout(updateTimerRef.current);
  }

  // 设置一个新的定时器，比如每50毫秒或缓冲区超过10个字符时更新一次状态
  updateTimerRef.current = setTimeout(() => {
    if (bufferRef.current) {
      setCurrentStream(prev => prev + bufferRef.current);
      bufferRef.current = ''; // 清空缓冲区
    }
  }, 50); // 调整这个时间间隔以平衡实时性和性能
};

这个技巧在低性能设备或生成速度极快时效果显著。但要注意，这会引入微小延迟，需要根据实际情况调整缓冲阈值。

5.2 自动滚动与焦点管理

在聊天界面中，新消息应该自动滚动到可视区域。对于流式消息，我们需要在每次 currentStream 更新后，都尝试将视图滚动到底部。

const messagesEndRef = useRef(null);

// 一个用于滚动到底部的函数
const scrollToBottom = () => {
  messagesEndRef.current?.scrollIntoView({ behavior: 'smooth' });
};

// 使用useEffect在流式内容更新后触发滚动
useEffect(() => {
  if (isStreaming) {
    scrollToBottom();
  }
}, [currentStream, isStreaming]); // 依赖currentStream和isStreaming

// 在消息列表末尾放置一个空的div作为滚动锚点
return (
  <div className="messages-list">
    {/* ... 渲染历史消息 ... */}
    {isStreaming && <div className="message assistant">{currentStream}<span className="cursor"/></div>}
    <div ref={messagesEndRef} /> {/* 滚动锚点 */}
  </div>
);

同时，良好的 焦点管理 能提升可访问性。在发送消息后，可以将焦点移回输入框；在流式响应结束时，也可以将焦点移动到新生成的消息上，方便屏幕阅读器用户。

5.3 处理大模型输出的格式（如Markdown、代码块）

很多AI模型（如GPT）的输出包含Markdown格式。如果我们直接将其作为纯文本渲染， **粗体** 或 # 标题 这样的标记会显得很乱。我们需要在前端进行Markdown解析。

方案一：在流式过程中实时解析 这比较有挑战性，因为Markdown是上下文相关的（比如一个代码块需要开始和结束标记）。在流式片段中，你可能会收到不完整的标记，导致解析错误或闪烁。

方案二：流式接收，完成后统一解析（推荐） 这是更稳妥的方案。我们将原始的、包含Markdown标记的文本流式接收并存储。当流式结束时，再将完整的文本一次性传递给Markdown渲染库（如 marked 、 react-markdown ）进行渲染。

// 1. 状态存储原始文本
const [rawStreamText, setRawStreamText] = useState('');
// 2. 流式结束时，将 rawStreamText 交给 Markdown 渲染组件
{!isStreaming && rawStreamText && (
  <ReactMarkdown>{rawStreamText}</ReactMarkdown>
)}
// 3. 流式过程中，可以暂时用纯文本展示，或者也尝试用轻量级解析（体验稍差）
{isStreaming && (
  <div>{/* 简单显示纯文本，或使用一个能容忍不完整标记的轻量解析器 */}</div>
)}

对于代码块， react-markdown 配合 prism.js 或 highlight.js 语法高亮组件，能获得非常好的展示效果。这需要在流式结束后进行处理。

6. 常见问题与排查实录

在实际开发中，我遇到了不少坑。这里总结几个最典型的：

6.1 连接秒断或收不到数据

  • 症状 ： EventSource 连接很快进入 onerror 状态，或者一直没触发 onmessage 。
  • 排查 ：
    1. 检查响应头 ：这是最常见的原因。后端接口 必须 返回 Content-Type: text/event-stream 。用浏览器开发者工具的“网络（Network）”选项卡查看响应头，确认无误。
    2. 检查数据格式 ：服务器发送的每条消息必须严格遵循 data: <内容>\n\n 格式。多一个空格、少一个换行都可能导致客户端解析失败。可以查看“网络”选项卡中该SSE请求的“响应（Response）”内容，看看原始数据流是否符合规范。
    3. 跨域问题 ：如果前端和后端不在同一个域，需要后端配置CORS。SSE的CORS要求除了常见的 Access-Control-Allow-Origin ，最好也加上 Access-Control-Allow-Credentials （如果带cookie）等。注意， EventSource 不支持自定义请求头（如Authorization），如果需要认证，通常通过URL查询参数或Cookie传递。更复杂的认证可能需要一个前端代理或使用WebSocket。

6.2 流式响应不连贯或卡顿

  • 症状 ：文字不是逐字平稳流出，而是成段地、有延迟地出现。
  • 排查 ：
    1. 网络延迟与缓冲 ：可能是网络问题，也可能是服务器端或客户端的缓冲区设置。检查服务器是否在累积一定数据后才发送（比如使用了错误的缓冲方式）。
    2. 前端渲染性能 ：如前所述，过于频繁的React状态更新可能导致UI线程阻塞。尝试使用“缓冲更新”的优化技巧。
    3. 后端生成速度 ：AI模型本身生成token的速度有波动。如果后端是调用云端API，网络延迟也会影响。可以在前端数据块接收事件中打印时间戳，分析延迟是均匀的还是集中在某处。

6.3 内存泄漏与连接管理

  • 症状 ：页面切换或多次发起流式请求后，浏览器内存占用持续上升，或出现重复消息。
  • 排查与解决 ：
    1. 严格关闭旧连接 ：在发起新请求或组件卸载时，务必检查并关闭（ .close() ）之前的 EventSource 连接。
    2. 清理副作用 ：在React的 useEffect 清理函数中关闭连接。
    3. 使用AbortController ：虽然 EventSource 原生不支持 AbortController ，但我们可以将其与 fetch API结合实现更精细的控制（ fetch 支持流式响应体 response.body ，但处理起来比SSE复杂）。对于纯SSE，用 ref 保存实例并手动关闭是标准做法。

6.4 如何与现有状态管理（如Redux、Zustand）集成？

流式数据本质上是异步的、连续的副作用。将其集成到Redux等状态管理中，推荐使用 Redux Thunk或Redux Saga （对于Redux），或者直接在组件内管理，通过dispatch action来更新存储。

例如，使用Redux Thunk：

const startStreaming = (inputText) => async (dispatch, getState) => {
  dispatch({ type: 'STREAM_START' });
  const eventSource = new EventSource(`/api/stream?q=${encodeURIComponent(inputText)}`);
  window.currentEventSource = eventSource; // 临时挂载，便于中止

  eventSource.onmessage = (event) => {
    const chunk = event.data;
    if (chunk === '[DONE]') {
      eventSource.close();
      dispatch({ type: 'STREAM_COMPLETE' });
    } else {
      dispatch({ type: 'STREAM_CHUNK', payload: chunk });
    }
  };
  eventSource.onerror = () => {
    // 处理错误，dispatch错误action
    eventSource.close();
  };
};

// 在组件中 dispatch 这个 thunk action

关键是将流式数据的“碎片”也视为一系列可预测的action，纳入统一的状态管理流。

7. 从项目到产品：流式输出的价值延伸

实现基础流式输出只是第一步。当我们把它放到一个真实产品中思考，会发现更多可以打磨的点：

  1. 打字机效果与速度控制 ：即使数据是瞬间收到的，我们也可以模拟“打字机”效果，控制字符逐个出现的速度，这能营造一种更自然、更具亲和力的交互感。这完全是一个前端动画问题，可以用 setInterval 或 requestAnimationFrame 实现。
  2. 中途干预与引导 ：在流式生成过程中，能否提供“停止”、“重说”、“更详细”等按钮，让用户实时干预生成方向？这需要前端将中断信号或新指令实时发送给后端，可能就需要升级到WebSocket或使用额外的API调用。
  3. 错误恢复与断点续传 ：对于生成长文档、代码等场景，如果网络中断，能否从断点处恢复，而不是重新开始？这需要后端支持某种“会话状态”记录，并给每个数据块分配ID，前端在重连时携带最后收到的ID。
  4. 性能监控 ：在前端埋点，记录从发送请求到收到第一个字的时间（首字时间TTFT），以及生成完整回复的总耗时。这些数据对于评估AI服务性能和用户体验至关重要。

前端工程师在AI时代的新角色，正是将这些冰冷的、异步的数据流，转化为温暖、实时、富有表现力的交互体验。流式输出不是一个炫技功能，而是AI应用基础体验的核心构成。掌握它，意味着你拥有了构建下一代人机交互界面的关键能力。

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

更多推荐

cover

大 硬 仗14小时：用2009年的上古亮机卡跑完深度学习，CPU满载但代码没崩

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

原来AI、画图、导航都在用向量！

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

害虫检测和识别3：基于深度学习YOLO26神经网络实现害虫检测和识别(含训练代码、数据集和GUI交互界面）

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