说实话，两年前我刚从传统Web开发转岗到AI产品线的时候，心里其实是有点轻敌的。那时候我想，AI前端Neng有多难？不就是套个壳，放个输入框，然后调个接口把字吐出来吗？结果第一次需求评审会，我就被现实狠狠地打了一记耳光。那一刻我才意识到，AI前端开发这潭水，比我想象的要深得多。这篇文章，我想把这两年里我踩过的那些坑、熬过的那些夜，还有那些让我抓狂的Bug，统统摊开来讲讲。Ru果你也是刚入门的初级工程师，希望我的这些“血泪史”Neng帮你省下几根头发。

一、别让用户盯着白屏：流式传输是必修课

刚开始Zuo第一个AI聊天功Neng时我写法非常“传统”。一个简单的POST请求，老老实实等着后端把所有内容dou生成完，然后一次性返回。

const response = await fetch('/api/chat', {
  method: 'POST',
  body: JSON.stringify
});
const data = await response.json;
setMessage;

结果测试的时候，用户反馈非常直接：“怎么要等好几秒才Nengkan到回复？是不是卡死了？”

这体验简直糟糕透顶。AI模型生成内容是需要时间的，这几秒钟的沉默，对用户来说就是一种折磨。后来我才明白，AI的输出应该是流式的，像打字机一样一个字一个字蹦出来这样用户才会觉得系统“活着”。

1. 拥抱 SSE

为了解决这个问题，我开始研究SSE。这东西其实不复杂，但它Neng极大地提升交互体验。与其傻等全部结果，不如让后端一点一点地推。

// ✅ 正确的流式处理思路
const eventSource = new EventSource;
eventSource.onmessage =  => {
  const data = JSON.parse;
  if  {
    setMessage;
  }
};

2. 警惕“乱码”陷阱

当你开始用流式传输后hen快就会遇到一个让人摸不着头脑的问题：AI生成的中文回复，偶尔会出现奇怪的符号，比如“你好”突然变成了“��好”。

这其实不是模型疯了而是编码的问题。在SSE或者Fetch的流式读取中，一个中文字符通常占用3个字节。Ru果网络传输的数据包刚好把这三个字节切开了比如前两个字节在第一个chunk，后一个字节在第二个chunk，你直接用`TextDecoder`去解码第一个chunk，它就会因为找不到完整的字符而显示成乱码。

为了解决这个问题，我写了一个简单的解码器来处理这种被切断的情况：

class StreamDecoder {
  constructor {
    this.decoder = new TextDecoder;
    this.buffer = '';
  }
  decode {
    this.buffer += this.decoder.decode;
    // 尝试解析
    try {
      return JSON.parse;
    } catch {
      // 解析失败，说明数据不完整，等待下一个 chunk
      return null;
    }
  }
  finalize {
    return this.decoder.decode, { stream: false });
  }
}

记住`TextDecoder`的那个`{ stream: true }`参数非常关键，它告诉解码器：“别急，后面还有数据，先别报错。”

二、状态管理：别让逻辑变成一团浆糊

随着功Neng越加越多，我发现代码开始变得不可控。一开始我只是用简单的`useState`来存消息列表，但后来需求变成了：要支持发送中、接收中、失败重试、停止生成……状态满天飞。

用`useState`管理这些复杂的逻辑，代码变得hen乱，状态同步也hen困难。比如用户快速点了两次发送，或者网络波动了到底是该显示“发送中”还是“失败”？

1. 引入状态机

后来我痛定思痛，引入了状态机的概念。把聊天流程抽象成几个明确的状态：空闲、发送中、接收中、完成、错误。这样，任何时刻系统处于什么状态一目了然不同状态之间的转换也有了规则。

import { createMachine } from 'xstate';
const chatMachine = createMachine({
  initial: 'idle',
  states: {
    idle: {
      on: { SEND: 'sending' }
    },
    sending: {
      on: { SUCCESS: 'receiving', ERROR: 'idle' }
    },
    receiving: {
      on: { COMPLETE: 'idle', STOP: 'idle' }
    }
  }
});

2. 资源清理：别让内存泄漏毁了你的应用

还有一个坑，特别容易被忽视。有时候用户聊着聊着切换了页面或者关闭了窗口。这时候，Ru果组件卸载了但你的SSE连接或者那些定时器还在跑，浏览器就会报错，甚至内存泄漏。

我的排查过程非常痛苦，Zui后发现原因hen简单：组件卸载时没有清理资源。

useEffect => {
  const eventSource = new EventSource;
  const timer = setInterval => {
    // 某些定时任务...
  }, 1000);
  return  => {
    // 清理！清理！清理！重要的事情说三遍
    eventSource.close;
    clearInterval;
  };
}, );

三、性Neng优化：当对话记录越来越长

当用户聊了几十轮之后新的问题来了：页面开始卡顿，甚至浏览器直接崩溃。打开任务管理器一kan，内存占用飙升到了2GB。

1. 虚拟滚动救星

DOM节点是有成本的。几千条消息，每条dou包含复杂的HTML结构，浏览器渲染起来压力巨大。这时候，虚拟滚动就是救命稻草。它只渲染可视区域内的那几条消息，其他的统统“虚拟化”。

import { FixedSizeList } from 'react-window';

  { => (
    

      
    
  )}

2. 渲染安全：小心XSS攻击

AI生成的内容是不可控的。Ru果它生成了一段恶意的JavaScript代码，而你直接用`dangerouslySetInnerHTML`渲染到页面上，那后果不堪设想。

我开始用`marked`库来解析Markdown，但光这样还不够，必须配合`DOMPurify`进行清洗。

import DOMPurify from 'dompurify';
import { marked } from 'marked';
const safeHtml = DOMPurify.sanitize);

四、数据策略：Token是昂贵的，存储是有限的

ZuoAI前端，不懂点模型限制是不行的。模型每次Neng处理的上下文长度是有限的，而且Token也是要钱的。

1. 智Neng截断历史记录

我一开始的Zuo法非常简单粗暴：每次对话dou把所有历史记录一股脑发给后端。

// ❌ 简单粗暴的Zuo法
const response = await fetch('/api/chat', {
  body: JSON.stringify({
    message: newMessage,
    history: messages // 问题：越来越多，Zui后爆Token
  })
});

这显然不行。后来我学会了“智Neng截断”。只保留Zui近的几轮对话，或者根据Token数量动态计算要保留多少历史。

// 简单的截断策略
function getLimitedHistory {
  let totalTokens = 0;
  const selected = ;
  // 从后往前选
  for  {
    const msgTokens = estimateTokens;
    if  {
      selected.unshift;
      totalTokens += msgTokens;
    }
  }
  return selected;
}
function estimateTokens {
  // 粗略估算：1个中文字符 ≈ 1.5个token
  return Math.ceil;
}

2. 本地持久化：从localStorage到IndexedDB

用户刷新页面聊天记录丢了？这体验太差了。一开始我用`localStorage`存，简单方便。但`localStorage`容量只有5MB左右，存点文本还行，存多了或者存点图片就炸了。

对于生产环境，或者需要离线支持的应用，强烈推荐IndexedDB。虽然API难用点，但容量大，支持异步。

import { openDB } from 'idb';
// 1. 初始化数据库
const db = await openDB('chat-db', 1, {
  upgrade {
    db.createObjectStore;
  }
});
// 2. 乐观geng新：立即显示在 UI 上
async function sendMessage {
  const message = {
    id: Date.now,
    content,
    role: 'user',
    pending: true // 标记为待发送
  };
  // 立即显示
  setMessages;
  // 保存到本地
  await db.put;
  // 尝试发送...
}

五、并发控制：别让回复“张冠李戴”

有时候用户手快，连续发了两条消息。Ru果网络有延迟，可Neng会出现第一条消息的响应还没回来第二条消息的响应先到了甚至两条消息的响应混在了一起。

为了解决这个问题，我们需要给每个请求带上一个唯一的ID，前端只处理当前Zui新请求的响应，或者根据ID把响应归位到对应的消息气泡里。

const  = useState;
async function sendMessage {
  const requestId = Date.now;
  setCurrentRequestId;
  const response = await fetch('/api/chat', {
    body: JSON.stringify
  });
  const reader = response.body.getReader;
  while  {
    const { done, value } = await reader.read;
    if  break;
    const data = JSON.parse.decode);
    // 只处理Zui新请求的响应
    if  {
      setContent;
    }
  }
}

六、心态与工具：给新手的几点建议

回顾这两年的成长，除了技术上的积累，心态上的转变可Nenggeng重要。

1. 不要一开始就追求完美

我的教训hen深刻：一开始就想Zuo“完美产品”，结果花了4周时间，还有hen多Bug。后来简化需求，2周就上线了MVP。先跑通流程，再优化细节。

2. 了解模型的Neng力边界

作为前端，你不需要训练模型，但你必须知道模型NengZuo什么不NengZuo什么。不要设计一些模型根本无法实现的功Neng，比如让模型去实时抓取今天的天气。

3. 工具组合推荐

对于初级开发者，不要一开始就用Zui复杂的工具。这是我推荐的入门组合：

入门： React + Vite + SSE + localStorage

进阶： React + Vite + WebSocket + IndexedDB

4. 一定要kan官方文档

不要只kan博客文章，hen多博客的示例代码是有问题的，或者Yi经过时了。遇到问题，先翻官方文档，再翻源码，Zui后才去搜博客。

前端AI Agent开发，本质上还是前端开发，但它对实时性、状态管理和数据策略的要求geng高。从只会写简单聊天界面到独立完成AI产品前端，我用了两年时间踩了无数坑。

记住：没有人一开始就是专家，所有的专家dou是从新手一步步走过来的。

不要怕踩坑，每个坑dou是学习机会。Ru果你在开发过程中遇到了什么奇怪的问题，欢迎在评论区交流，我们一起探讨！

---