企业官网建设流程全解析

1. 这不是一份“面试速成指南”，而是一份9月8日启动的AI前端实战备战日志

如果你准备在9月8号开始准备今年AI前端面试的话——这句话听起来像一句随口提醒，但背后藏着一个正在剧烈变形的职业现场。我带过三届前端校招面试官，也连续两年参与大厂AI产品线的技术选型评审，亲眼看着“前端”这个词的边界，在过去18个月内被AI技术一层层剥开、重铸、再封装。现在坐在面试桌对面的候选人，已经不再需要解释“React怎么写组件”，而是要能说清楚：当一个LLM返回的流式token流撞上React的渲染生命周期时，你用什么机制做缓冲、防抖、错误回退？你如何让Suspense真正“悬”住用户等待的焦虑，而不是变成一个闪烁的loading图标？你写的TypeScript类型定义，能不能覆盖从OpenAI API响应到本地Agent状态机的全链路？这些不是加分项，是入场券。

核心关键词——AI、前端、TypeScript、流式处理、状态管理——不是并列关系，而是一个嵌套结构：AI是业务场景与能力来源，前端是交付界面与交互载体，TypeScript是保障复杂数据流不脱轨的静态护栏，流式处理是应对大模型实时响应的核心技术动作，状态管理则是把上述所有要素粘合成可维护、可调试、可扩展系统的胶水。这五个词串起来，就是2024下半年到2025年初真实存在的岗位JD：AI Agent前端工程师、大模型应用前端架构师、智能UI平台开发岗。它们不要求你会训练模型，但要求你比后端更懂模型输出的不确定性，比算法更懂用户在界面上的等待耐受阈值。

这份日志不面向“零基础想转行”的人，也不面向“只刷LeetCode八股文”的人。它专为那些已经能熟练使用React/Vue、写过中大型项目、对TypeScript有基本工程实践、但第一次面对“AI+前端”复合题型时感到逻辑断层的人而写。它不承诺“7天拿下Offer”，但能确保：从9月8日开始，每天2小时，到10月25日秋招高峰前，你将亲手搭建一个具备真实AI交互特征的前端应用——它能处理流式SSE响应、能用Suspense优雅降级、能用Redux Toolkit + RTK Query管理多源异步状态、能用TypeScript精准约束从API Schema到UI组件Props的每一层数据契约。这不是模拟题，是你简历里可以放GitHub链接、面试时可以打开DevTools现场调试的真实项目。

2. 整体设计思路：为什么必须放弃“传统前端复习路径”？

2.1 传统路径失效的根本原因：AI交互彻底重构了前端的数据流范式

过去三年，前端面试的底层逻辑是“状态驱动视图”。你掌握useState/useReducer，理解props down & events up，能拆解复杂组件树，就能应付大部分业务场景。但AI应用把这套逻辑推翻了：数据不再是静态加载或事件触发后的确定性更新，而是持续涌来的、分块到达的、可能中断或乱序的字节流。举个最典型的例子：当你调用一个支持stream:true的Chat Completion API时，HTTP响应头是text/event-stream，body里不是JSON对象，而是一连串以data:开头的event-stream片段：

data: {"id":"chatcmpl-xxx","object":"chat.completion.chunk","created":1725789012,"model":"gpt-4o","choices":[{"index":0,"delta":{"role":"assistant","content":"Hello"},"finish_reason":null}]} data: {"id":"chatcmpl-xxx","object":"chat.completion.chunk","created":1725789012,"model":"gpt-4o","choices":[{"index":0,"delta":{"content":" world"},"finish_reason":null}]} data: {"id":"chatcmpl-xxx","object":"chat.completion.chunk","created":1725789012,"model":"gpt-4o","choices":[{"index":0,"delta":{},"finish_reason":"stop"}]}

这个流式响应，传统fetch+JSON.parse根本无法处理。你不能等整个响应结束再setState，因为用户需要看到“Hello world”逐字出现；你也不能简单地用useEffect监听一个ref变化，因为流式数据需要缓冲、防抖、错误恢复、取消控制。这就逼出了第一个关键设计决策：必须引入专门的流式处理抽象层，而非在现有状态管理框架上打补丁。

我试过直接用Redux Thunk处理SSE，结果是action creator里塞满了addEventListener、abortController、文本解析逻辑，reducer里充斥着字符串拼接和状态标记。代码耦合度高，测试困难，且无法复用。后来我们团队在内部项目中统一采用了一套基于RxJS的流式状态管理方案，但对面试者来说，RxJS学习成本过高。所以最终选定的方案是：用原生AbortController + ReadableStream + TextDecoder组合构建轻量级流处理器，再将其输出接入RTK Query的自定义queryFn。这样既避免了引入新框架，又保持了与现有Redux生态的无缝集成，更重要的是，它让你在面试中能清晰说出每一步的设计意图：“我选择ReadableStream是因为它是浏览器原生API，兼容性好；用TextDecoder是为了正确处理UTF-8多字节字符；AbortController负责与React组件生命周期同步，防止内存泄漏”。

2.2 TypeScript不是“加类型注解”，而是构建AI交互的契约防火墙

很多候选人以为TypeScript面试就是背interface和泛型语法。但在AI前端场景下，TypeScript的核心价值是建立跨系统、跨时间、跨信任边界的类型契约。一个典型痛点：后端返回的AI响应Schema，和前端实际消费的数据结构，往往存在三重错位：

• Schema错位：OpenAI官方文档写的response type是ChatCompletionChunk，但实际返回的delta.content可能是string | undefined，finish_reason可能是"stop" | "length" | null，而你的组件却假设它永远是string。
• 时序错位：流式响应中，第一块chunk可能只有role字段，第二块才有content，第三块才出现finish_reason。如果用一个统一的ChatMessageinterface去接收所有chunk，TypeScript会报错，因为content在初始状态不存在。
• 信任错位：你调用的不是自家后端API，而是第三方AI服务。它的响应格式可能随时变更（比如某天突然在chunk里加了个usage字段），而你的前端类型定义如果过于刚性，就会导致整个应用崩溃。

因此，我们的TypeScript设计原则是：分层定义、渐进增强、运行时防护。具体落地为三层类型：

1. Raw Stream Type：仅定义SSE event data的最小结构，如{ data: string }，不做任何JSON解析假设；
2. Parsed Chunk Type：用zod进行运行时校验，定义ChatCompletionChunkSchema，允许字段可选，并提供.safeParse()方法；
3. UI State Type：基于parsed chunk动态构建的、完全适配组件需求的类型，如{ id: string; content: string; isComplete: boolean }，这个类型由业务逻辑生成，而非直接映射API。

这种设计让TypeScript从“编译期检查工具”升级为“系统韧性保障机制”。面试时，你可以指着代码说：“这里用zod做运行时校验，不是为了替代TypeScript，而是弥补TypeScript在动态API场景下的不足；而UI State Type的生成函数，保证了即使API变更，只要校验通过，前端就不会挂掉。”

2.3 状态管理：从“管理UI状态”到“协调AI生命周期”

Redux Saga曾是处理复杂异步流程的标杆，但在AI前端场景下，它的优势变成了负担。Saga的核心是“监听action -> 执行side effect -> dispatch新action”，这适合处理支付、表单提交等有明确起止点的流程。但AI交互是长生命周期、多状态交织、需实时反馈的过程：

• 用户发送消息 → 后端开始流式响应 → 前端开始逐块接收 → UI实时渲染 → 用户中途取消 → 后端需收到cancel信号 → 前端需清理缓冲区 → 保存当前已接收内容 → 更新UI显示“已取消” → 可能还要触发重试逻辑。

这个过程里，Saga的“监听-执行-派发”链条太长，状态分散在多个saga文件中，调试困难。相比之下，RTK Query的queryFn+transformResponse+serializeQueryArgs组合，提供了更紧凑、更声明式的解决方案。我们把整个流式请求封装在一个custom hook里：

// features/aiChat/api.ts export const aiChatApi = createApi({ reducerPath: 'aiChatApi', baseQuery: fetchBaseQuery({ baseUrl: '/api' }), endpoints: (builder) => ({ streamChat: builder.query<ChatResponse, ChatRequest>({ queryFn: async (arg, _queryApi, _extraOptions, fetchWithBQ) => { // 核心：在这里实现流式处理逻辑 const controller = new AbortController(); const response = await fetch('/v1/chat/stream', { method: 'POST', headers: { 'Content-Type': 'application/json' }, body: JSON.stringify(arg), signal: controller.signal, }); if (!response.ok) throw new Error(`HTTP ${response.status}`); const reader = response.body?.getReader(); if (!reader) throw new Error('ReadableStream not supported'); let accumulatedContent = ''; const chunks: ChatChunk[] = []; try { while (true) { const { done, value } = await reader.read(); if (done) break; const text = new TextDecoder().decode(value); const lines = text.split('\n').filter(l => l.trim() !== ''); for (const line of lines) { if (line.startsWith('data:')) { const jsonStr = line.slice(5).trim(); if (jsonStr === '[DONE]') continue; try { const chunk = JSON.parse(jsonStr) as RawChunk; const parsed = ChatChunkSchema.safeParse(chunk); if (parsed.success) { chunks.push(parsed.data); accumulatedContent += parsed.data.delta.content || ''; } } catch (e) { console.warn('Invalid chunk:', jsonStr); } } } } } catch (e) { if (e instanceof DOMException && e.name === 'AbortError') { // 用户取消，正常退出 } else { throw e; } } return { data: { chunks, fullContent: accumulatedContent } }; }, // transformResponse用于进一步加工，比如合并chunks、计算tokens transformResponse: (response: any) => { return { ...response, timestamp: Date.now(), }; }, }), }), });

这个设计的关键在于：把流式处理的复杂性封装在queryFn内部，对外暴露的依然是标准的RTK Query接口。组件只需调用useStreamChatQuery()，拿到isFetching、data、error等标准状态，无需关心底层是如何读取流、如何解析、如何取消。这极大降低了组件层的认知负担，也让状态管理回归本质：不是管理数据，而是管理数据的可用性、可靠性与可预测性。

3. 核心细节解析：流式处理、Suspense、状态管理的实操要点

3.1 流式处理：从SSE到React组件的完整链路

流式处理不是简单的“把fetch换成SSE”，而是一整套应对网络不确定性的工程实践。我们以一个真实的AI聊天界面为例，拆解从请求发起、数据接收、到UI渲染的每个环节。

第一步：请求发起与AbortController绑定

关键点在于AbortController必须与React组件生命周期严格同步。常见错误是：在useEffect里创建controller，但忘记在cleanup函数里调用abort()。更隐蔽的错误是：组件卸载后，reader仍在后台读取，导致内存泄漏。我们的做法是：

// hooks/useStreamChat.ts export function useStreamChat(initialMessage: string) { const [messages, setMessages] = useState<ChatMessage[]>([]); const [isStreaming, setIsStreaming] = useState(false); const controllerRef = useRef<AbortController | null>(null); const startStream = useCallback(async () => { // 清理上一次未完成的请求 if (controllerRef.current) { controllerRef.current.abort(); } const controller = new AbortController(); controllerRef.current = controller; setIsStreaming(true); setMessages(prev => [...prev, { id: uuid(), role: 'user', content: initialMessage, timestamp: Date.now() }]); try { const response = await fetch('/api/chat/stream', { method: 'POST', headers: { 'Content-Type': 'application/json' }, body: JSON.stringify({ message: initialMessage }), signal: controller.signal, // 关键：绑定signal }); if (!response.ok) throw new Error(`HTTP ${response.status}`); const reader = response.body?.getReader(); if (!reader) throw new Error('Stream not readable'); let buffer = ''; let currentMessageId = uuid(); // 持续读取流 while (true) { const { done, value } = await reader.read(); if (done) break; buffer += new TextDecoder().decode(value); // 按行分割，处理SSE格式 const lines = buffer.split('\n'); buffer = lines.pop() || ''; // 保留不完整的最后一行 for (const line of lines) { if (line.startsWith('data:')) { const jsonStr = line.slice(5).trim(); if (jsonStr === '[DONE]') continue; try { const chunk = JSON.parse(jsonStr) as RawChunk; const content = chunk.choices?.[0]?.delta?.content || ''; // 实时更新UI：追加到当前消息 setMessages(prev => { const lastMsg = prev[prev.length - 1]; if (lastMsg?.id === currentMessageId && lastMsg.role === 'assistant') { return [ ...prev.slice(0, -1), { ...lastMsg, content: lastMsg.content + content, timestamp: Date.now() } ]; } else { // 创建新消息 const newMsg = { id: currentMessageId, role: 'assistant' as const, content, timestamp: Date.now(), }; return [...prev, newMsg]; } }); } catch (e) { console.error('Parse error:', e, jsonStr); } } } } } catch (e) { if (e instanceof DOMException && e.name === 'AbortError') { console.log('Stream aborted by user'); } else { console.error('Stream error:', e); } } finally { setIsStreaming(false); controllerRef.current = null; } }, [initialMessage]); // 组件卸载时自动取消 useEffect(() => { return () => { if (controllerRef.current) { controllerRef.current.abort(); } }; }, []); return { messages, isStreaming, startStream }; }

这段代码的实操要点：

• buffer管理：SSE数据可能被TCP分片，一行完整的data:{}可能被切成两段到达。必须用buffer暂存不完整的行，否则JSON.parse会失败。
• message ID追踪：流式响应中，一个请求对应一个assistant消息，但chunk是分多次到达的。需要用currentMessageId标识这是同一个消息的连续片段，避免每次chunk都创建新消息。
• setMessages的批量更新：React 18的自动批处理在此场景下可能失效，因为await在循环内。我们显式用函数式更新，确保每次state change都是基于最新prev state。

第二步：Suspense的真正用武之地——不只是loading，而是“等待策略”

很多人误以为Suspense就是替代loading的状态。在AI场景下，Suspense的价值在于定义不同粒度的等待边界与降级策略。例如，在聊天界面中，你可能有三个Suspense区域：

• 顶部Header：显示当前模型名称、token用量。这个区域应该独立于聊天流，用独立的useQuery获取，设置staleTime: 30000，避免每次流式请求都刷新。

• 消息列表：这是Suspense的核心战场。我们不把整个<MessageList />包在Suspense里，而是把每一条消息的渲染逻辑提取为独立的<MessageItem />，并在其内部使用useSuspenseQuery：

  // components/MessageItem.tsx export function MessageItem({ messageId }: { messageId: string }) { const { data } = useSuspenseQuery( aiChatApi.endpoints.getMessage.useQuery({ id: messageId }) ); return <div className="message">{data.content}</div>; }

  这样做的好处是：当某条消息加载慢时，只挂起该消息，其他消息照常显示。用户看到的是“部分消息已加载，这条还在来”，而不是“整个聊天框卡住”。

• 输入框：用户输入时，需要禁用发送按钮，但不应阻塞整个UI。我们用useMutation的isLoading状态控制按钮，而非Suspense。

提示：Suspense的fallback组件必须是纯展示组件，不能包含任何副作用。我见过有人在fallback里调用analytics.track()，结果导致每次fallback渲染都触发埋点，数据严重失真。

3.2 TypeScript类型设计：从API Schema到UI Props的精准映射

TypeScript在AI前端中的最大陷阱，是过度追求“完美类型”而牺牲灵活性。我们采用“最小可行类型+运行时校验”的双保险策略。

Raw API Schema定义（zod）

// schemas/openai.ts import { z } from 'zod'; export const RawChunkSchema = z.object({ id: z.string(), object: z.literal('chat.completion.chunk'), created: z.number(), model: z.string(), choices: z.array( z.object({ index: z.number(), delta: z.object({ role: z.string().optional(), content: z.string().optional(), }).optional(), finish_reason: z.union([z.literal('stop'), z.literal('length'), z.null()]).optional(), }) ), }); export type RawChunk = z.infer<typeof RawChunkSchema>; // 安全解析函数 export function parseChunk(text: string): RawChunk | null { try { const parsed = JSON.parse(text); const result = RawChunkSchema.safeParse(parsed); return result.success ? result.data : null; } catch (e) { return null; } }

这个schema的关键设计：

• .optional()的精确使用：delta.content是optional，因为首块chunk可能只有role；finish_reason是z.union([...])，因为OpenAI文档明确列出三种可能值，但实际响应中可能是null。
• 不定义usage字段：虽然OpenAI文档提到usage，但流式响应中从未出现。强行定义会导致safeParse失败，所以先忽略，等实际遇到再补充。

UI State Type生成（运行时）

// types/chat.ts export interface ChatMessage { id: string; role: 'user' | 'assistant'; content: string; timestamp: number; isComplete?: boolean; // 仅用于UI，表示是否收到finish_reason } // 从RawChunk生成UI Message的工厂函数 export function chunkToMessage(chunk: RawChunk, messageId: string): ChatMessage { const choice = chunk.choices[0]; const delta = choice.delta || {}; return { id: messageId, role: 'assistant', content: delta.content || '', timestamp: Date.now(), isComplete: choice.finish_reason === 'stop' || choice.finish_reason === 'length', }; }

这个工厂函数的意义在于：它把类型安全的决策权，从编译期移交到运行时。即使API返回了意外字段，chunkToMessage也能兜底处理，不会让整个应用崩溃。

Props类型精简（组件层）

// components/ChatInput.tsx interface ChatInputProps { onSend: (message: string) => void; // 不传整个event，只传value disabled: boolean; // 明确控制态，而非依赖全局loading placeholder?: string; // 可选，方便复用 } export function ChatInput({ onSend, disabled, placeholder = '输入消息...' }: ChatInputProps) { const [value, setValue] = useState(''); const handleSubmit = (e: React.FormEvent) => { e.preventDefault(); if (value.trim() && !disabled) { onSend(value.trim()); setValue(''); } }; return ( <form onSubmit={handleSubmit}> <input value={value} onChange={(e) => setValue(e.target.value)} disabled={disabled} placeholder={placeholder} /> <button type="submit" disabled={disabled}>发送</button> </form> ); }

Props类型设计原则：只暴露组件真正需要的、可控的属性。不传isLoading，因为那是父组件的状态；不传onKeyDown，因为输入框的语义就是提交表单；disabled状态由父组件统一管理，保证UI一致性。

3.3 状态管理：RTK Query与Redux Toolkit的协同作战

RTK Query擅长管理“远程数据”，但AI应用还有大量“本地状态”需要管理：用户偏好（默认模型、温度值）、对话历史（非API返回的本地缓存）、UI状态（输入框聚焦、滚动位置）。我们的方案是：RTK Query管“远”，Redux Toolkit管“近”，两者通过createEntityAdapter统一数据结构。

远程状态（RTK Query）

// features/aiChat/api.ts export const aiChatApi = createApi({ reducerPath: 'aiChatApi', baseQuery: fetchBaseQuery({ baseUrl: '/api' }), endpoints: (builder) => ({ getModels: builder.query<Model[], void>({ query: () => 'models', // 自动缓存，30秒内重复请求不发网络 keepUnusedDataFor: 30, }), streamChat: builder.query<ChatResponse, ChatRequest>({ // 如前所述的流式处理 queryFn: async (arg, api, extraOptions, fetchWithBQ) => { /* ... */ }, // 防止相同参数的并发请求 serializeQueryArgs: ({ endpointName, queryArgs }) => { return `${endpointName}-${queryArgs.message}`; }, }), }), });

本地状态（Redux Toolkit Slice）

// features/aiChat/chatSlice.ts import { createSlice, PayloadAction } from '@reduxjs/toolkit'; import { createEntityAdapter } from '@reduxjs/toolkit'; // 使用EntityAdapter管理对话列表，保证ID唯一、查找O(1) const conversationsAdapter = createEntityAdapter<Conversation>({ selectId: (conversation) => conversation.id, }); export const chatSlice = createSlice({ name: 'chat', initialState: conversationsAdapter.getInitialState({ activeConversationId: null as string | null, settings: { model: 'gpt-4o', temperature: 0.7, maxTokens: 1024, } }), reducers: { setActiveConversation: (state, action: PayloadAction<string>) => { state.activeConversationId = action.payload; }, updateSettings: (state, action: PayloadAction<Partial<Settings>>) => { state.settings = { ...state.settings, ...action.payload }; }, addMessage: (state, action: PayloadAction<{ conversationId: string; message: ChatMessage }>) => { const { conversationId, message } = action.payload; // EntityAdapter的upsertOne会自动处理新增或更新 conversationsAdapter.upsertOne(state, { id: conversationId, messages: [...(state.entities[conversationId]?.messages || []), message], }); } }, }); export const { setActiveConversation, updateSettings, addMessage } = chatSlice.actions; export default chatSlice.reducer;

协同关键点：

• 数据流向单向化：RTK Query的streamChat.fulfilledaction，触发chatSlice的addMessage，而不是反过来。这样保证了数据源的单一可信。

• EntityAdapter的性能优势：当一个对话有200条消息时，直接操作数组会很慢。EntityAdapter把数据存为{ [id]: entity }对象，查找、更新都是O(1)。

• Selector复用：用createSelector组合远程和本地状态：

  // features/aiChat/selectors.ts import { createSelector } from '@reduxjs/toolkit'; import { aiChatApi } from './api'; import { chatSlice } from './chatSlice'; export const selectActiveConversation = createSelector( (state: RootState) => state.chat, (state: RootState) => state.aiChatApi, (chatState, apiState) => { const activeId = chatState.activeConversationId; if (!activeId) return null; const conversation = chatState.entities[activeId]; const models = aiChatApi.endpoints.getModels.select()(apiState); return { ...conversation, availableModels: models.data || [], }; } );

这个selector返回的是融合了远程模型列表和本地对话数据的完整视图，组件可以直接订阅，无需自己做useSelector+useQuery的组合。

4. 实操过程：从9月8日到10月25日的每日攻坚计划

4.1 第一阶段：夯实基础（9月8日 - 9月14日，7天）

目标：建立对AI前端核心概念的肌肉记忆，完成环境搭建与最小可行性Demo。

Day 1：环境与工具链初始化

• 初始化Vite + React + TypeScript项目，配置ESLint（@typescript-eslint/recommended）、Prettier、Husky pre-commit hook。
• 安装RTK Query、zod、uuid、@tanstack/react-query（备用）。
• 创建src/app/store.ts，配置Redux Store，注入aiChatApi.middleware。
• 实操心得：不要跳过Husky配置。我见过太多人因为忘记commit前格式化，导致PR被CI拒绝，浪费半天时间。npx husky add .husky/pre-commit "npm run format && npm test"，一行命令搞定。

Day 2：TypeScript Schema实战

• 手动编写OpenAI Chat Completion API的完整Response Schema（包括非流式和流式），用zod验证。
• 编写parseChunk函数，用真实SSE响应片段测试（可用curl模拟：curl -N http://localhost:3000/mock-sse）。
• 避坑提示：zod的.passthrough()和.strip()容易误用。.passthrough()允许未知字段，但不删除；.strip()删除未知字段。AI API经常加新字段，推荐用.passthrough()。

Day 3：流式处理核心逻辑

• 实现useStreamChatHook，完成从fetch到buffer管理的全流程。
• 在App.tsx中调用，用console.log验证chunk逐块到达。
• 关键调试技巧：在reader.read()后加console.debug('Received chunk:', new TextDecoder().decode(value))，观察原始字节流，比看JSON更直观。

Day 4：Suspense与UI集成

• 创建<MessageList />组件，用useSuspenseQuery加载历史消息（模拟API）。
• 实现<MessageItem />，为每条消息设置独立Suspense边界。
• 注意事项：Suspense需要<React.Suspense>包裹，且其子组件必须是异步组件。<MessageList>本身不能是Suspense组件，必须是普通组件，由父组件包裹。

Day 5：状态管理协同

• 创建chatSlice，实现addMessage、setActiveConversation。
• 在useStreamChat的success回调中dispatchaddMessageaction。
• 经验分享：RTK Query的queryFn里dispatch action，要用api.dispatch()，而不是store.dispatch()。后者会绕过middleware，导致aiChatApi的缓存失效。

Day 6：UI打磨与交互

• 实现输入框、发送按钮、消息气泡样式（CSS-in-JS或Tailwind）。
• 添加键盘Enter提交、Shift+Enter换行功能。
• 实操心得：event.key === 'Enter' && !event.shiftKey判断比event.keyCode更可靠，后者已被废弃。

Day 7：整合与测试

• 将所有模块集成，跑通一次完整对话流程。
• 用Jest + React Testing Library写3个核心测试：流式响应解析、消息添加、输入框提交。
• 测试重点：mockfetch，验证reader.read()被调用次数；用waitFor等待异步state更新。

4.2 第二阶段：深度攻坚（9月15日 - 10月10日，26天）

目标：解决真实AI应用中的高频痛点，提升代码健壮性与可维护性。

Week 2：错误处理与用户体验

• 实现网络错误重试（RTK Query的retry选项）。
• 设计优雅的错误UI：区分网络错误、API错误、模型拒绝（如429 rate limit）。
• 添加加载动画（Lottie或CSS animation），避免空白等待。

Week 3：性能优化与内存管理

• 实现消息列表虚拟滚动（react-window），解决长对话卡顿。
• 分析Chrome DevTools Memory Tab，确认无内存泄漏（重点检查reader、AbortController）。
• 用useMemo缓存复杂计算（如token计数、内容摘要）。

Week 4：高级功能与扩展

• 实现“停止生成”按钮，验证AbortController正确触发。
• 添加复制消息、引用回复、导出对话功能。
• 接入真实AI服务（如Anthropic、Gemini），对比API差异，调整Schema。

Week 5：工程化与部署

• 配置Vite PWA，支持离线访问。
• 添加Sentry错误监控，捕获未处理Promise rejection。
• 用Vercel部署，配置环境变量（API密钥）。

4.3 第三阶段：面试冲刺（10月11日 - 10月25日，15天）

目标：将项目转化为面试语言，提炼可复述的技术故事。

Day 1-3：技术故事梳理

• 为每个核心技术点准备1分钟故事：“当时遇到XX问题，我调研了A/B/C方案，选择B因为…，实现时踩了XX坑，最终效果是…”。
• 重点准备3个故事：流式处理设计、TypeScript类型策略、Suspense落地实践。

Day 4-7：白板与代码演练

• 手写useStreamChat核心逻辑（不查文档）。
• 在白板上画出数据流图：UI Event → Action → RTK Query → SSE → Reader → Buffer → Parse → Dispatch → UI Update。
• 模拟面试官提问：“如果用户快速连续发送5条消息，如何防止请求堆积？”

Day 8-10：行为面试准备

• 准备STAR案例：Situation（AI项目需求）、Task（我的职责）、Action（我做了什么技术决策）、Result（性能提升X%，错误率下降Y%）。
• 思考“你最大的技术挑战是什么？”——答案必须是具体技术问题，而非“时间紧任务重”。

Day 11-15：模拟面试与复盘

• 找朋友或录屏做全真模拟，严格计时。
• 复盘录音，检查：技术表述是否准确？有没有堆砌术语？故事是否清晰？
• 最后叮嘱：面试不是考试，是对话。当面试官问“为什么用RTK Query不用Redux Saga？”，回答不是背诵优点，而是说：“在上个项目中，我们用Saga处理支付流程很顺，但迁移到AI聊天时，发现Saga的‘监听-执行’模式让流式状态难以追踪。后来我们尝试RTK Query的queryFn，发现它把副作用封装得更干净，debug时能直接看到queryFn的return值，团队协作效率提升了。”

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

5.1 流式处理类问题

5.2 TypeScript类问题

5.3 状态管理类问题

| 问题现象 | 可能原因