我做前端這些年接觸過不少項目其中一類特別有意思在不接真實大模型接口的前提下把與大模型對話的交互界面先完整做出來。這個活兒的核心關(guān)鍵詞不是模型本身而是“前端模擬”——你要在瀏覽器里還原出那種“流式輸出、逐字蹦字、AI思考中”的感覺讓用戶、產(chǎn)品、甚至自己都覺得這個對話系統(tǒng)已經(jīng)能跑了。這個場景常見得很。比賽演示、產(chǎn)品Demo、界面評審、教學(xué)課件、給客戶的POC概念驗證甚至是在真實接口還沒到位的時候先定UI交互稿全都需要這么一層“假”的交互層來兜底。但這個“假”比你想象中要難做得真難做得像。很多人的第一版模擬界面最后做成了“點擊一下彈出一整段廢話”的靜態(tài)頁面那完蛋了感覺完全不對產(chǎn)品看完會直接說這不是我想要的。真實的對話感藏在細節(jié)里思考狀態(tài)的延遲、逐字輸出的節(jié)奏感、滾動跟隨的平滑度、多輪對話上下文的連續(xù)性。這篇博文我就拆一個我實際打磨過的“簡易版”方案完全平鋪直敘地講清楚怎么做代碼可以直接抄偏往前端領(lǐng)域但沒接觸過前端的朋友也能看懂個七七八八。1. 為什么你極度需要“模擬”而不是直接接接口先聊點務(wù)虛的想清楚再動手可以少走很多彎路。1.1 真實業(yè)務(wù)場景里的三大痛點很多人會問不是有大模型API嗎為什么還要模擬直接把前端代碼接到模型接口上它流式返回打字機效果不就是現(xiàn)成的理論上是這樣但實際開發(fā)中會遇到三個很扎心的問題。第一接口不穩(wěn)定燒錢快。無論是國內(nèi)還是國外的模型服務(wù)大都按token計費。咱們前端同學(xué)一天要反復(fù)刷新頁面幾十次每次刷新都要重新對話、重新發(fā)請求如果是做界面調(diào)試那不是在開發(fā)是在燒錢。尤其是測試多輪對話和超長上下文時一次請求可能就是幾萬個token一天下來賬單數(shù)字真不好看。第二環(huán)境依賴太強。開發(fā)環(huán)境、測試環(huán)境、演示現(xiàn)場這三個環(huán)境的網(wǎng)絡(luò)情況完全不同。現(xiàn)場演示最怕翻車你要是接的是真實模型一旦現(xiàn)場網(wǎng)絡(luò)抖動、API限流或者模型服務(wù)商臨時抽風(fēng)你精心準(zhǔn)備的演示環(huán)節(jié)就毀了。而模擬方案沒有任何外部依賴只要瀏覽器能打開HTML文件它就能跑還跑得穩(wěn)穩(wěn)當(dāng)當(dāng)。第三前后端進度脫節(jié)。在很多項目里后端的智能體編排、知識庫檢索還沒做完前端這邊界面已經(jīng)排期到了。這時候你如果不做模擬層前端只能干等項目周期被拉長。有了模擬接口之后前端可以完全獨立開發(fā)等后端就緒了再把模擬數(shù)據(jù)源換成真實請求就行前端的主體交互邏輯基本不用動。我做過的幾個項目里有做企業(yè)知識庫問答界面的有做AI客服工作臺的有做智能體配置平臺的無一例外都走了“先模擬、后接入”的路子。這根本不是取巧而是嚴謹?shù)拈_發(fā)流程。模擬層不是為了騙人而是為了把“交互體驗”和“后端邏輯”解耦讓兩邊的開發(fā)可以并行。1.2 模擬方案要模擬到什么程度不是隨便加個假接口就完事了。既然要“以假亂真”你就得模擬出這幾個核心環(huán)節(jié)多輪對話管理用戶發(fā)一條模型回一條再發(fā)再回上下文要像真實對話一樣累積。思考狀態(tài)的呈現(xiàn)現(xiàn)在幾乎所有主流的大模型對話產(chǎn)品在模型返回之前都會有一段“思考中”或“正在組織回復(fù)”的過渡。這個必須有而且時間要隨機不能每句話都一樣長。流式輸出的視覺表現(xiàn)這是靈魂。真實的大模型接口基本都是流式返回前端拿到一塊就渲染一塊所以用戶看到的是文字一個字一個字蹦出來的效果。模擬的時候咱們把一整段文字切分成小片段用定時器一個個釋放配合光標(biāo)閃爍視覺上完全一致。交互狀態(tài)管理發(fā)送過程中按鈕要禁用防止重復(fù)提交流式輸出時不能允許用戶插入新的問題打斷節(jié)奏對話消息區(qū)要自動滾動到最新消息。這些狀態(tài)模擬做得越細后面切換真實接口時就越省事。想清楚模擬到哪個層次再動手寫寫出來的東西才不是“玩具”。2. 整體設(shè)計與技術(shù)選型2.1 技術(shù)棧原生三件套居然最合適做這種一體化交互頁面可選的技術(shù)棧太多了。Vue全家桶、ReactState管理、甚至Next.js的流式渲染都能做。但既然是“簡易版”我最后選了最樸素的原生HTML CSS JavaScript直接一個單文件搞定。原因有三。其一零依賴意味著零構(gòu)建成本拿到代碼就能跑雙擊HTML文件就出效果不需要npm install不需要dev server。很多場地演示的時候現(xiàn)場壓根沒網(wǎng)絡(luò)你總不能讓觀眾等你安裝依賴吧。其二單文件方便分發(fā)。直接扔給同事或者塞進PPT里或者放在U盤里帶走都非常方便。其三原生的用requestAnimationFrame和setInterval已經(jīng)足夠處理打字機效果了殺雞不必用牛刀。當(dāng)然了如果你打算把這個模擬層做進正式項目里后續(xù)要接真實API那建議還是用框架封裝成獨立Service。我這篇文章先把最簡版本講透最后再給出一條平滑遷移路徑。2.2 數(shù)據(jù)模型設(shè)計消息列表是絕對核心前端對話界面的本質(zhì)是維護一個消息列表然后根據(jù)列表更新渲染。只要這個數(shù)據(jù)模型設(shè)計得好后面怎么玩都順手。我采用的結(jié)構(gòu)是這樣const state { messages: [], isStreaming: false, isWaiting: false }; // 單條消息 { id: msg_1720000000000_1, role: user | assistant, content: 你好幫我寫一份周報, status: done | waiting | streaming, rawContent: }role用來區(qū)分左右氣泡content是最終展示的文字status是這一條消息當(dāng)前處在什么階段rawContent在消息還沒結(jié)束時存的是已經(jīng)輸出部分的原始內(nèi)容。簡單嗎非常簡單。但就是這個簡單的結(jié)構(gòu)支持了后面所有玩法思考中狀態(tài)、流式輸出、清空對話、多輪上下文。2.3 消息流狀態(tài)機把對話過程抽象成狀態(tài)機思路就清晰了。用戶點擊發(fā)送后整個流程是這樣的用戶消息入列表狀態(tài)置為done立即渲染出左側(cè)氣泡。創(chuàng)建一條空的assistant消息入列表狀態(tài)置為waiting渲染右側(cè)氣泡并顯示“思考中...”動畫。經(jīng)過一個隨機延遲例如800到1500ms將assistant消息狀態(tài)改為streaming啟動定時器逐字追加內(nèi)容。每追加一小段內(nèi)容就更新DOM并滾動到底部。全部追加完畢狀態(tài)改為done收起打字光標(biāo)恢復(fù)輸入框可用。這個狀態(tài)機想清楚之后代碼寫起來就是順著流程往下走一點都不容易亂。這也是整個模擬層的骨架。3. 核心環(huán)節(jié)拆解模擬里最難的三塊這一整個模擬界面里真正有技術(shù)含量并且需要摳細節(jié)的就三塊流式輸出、思考狀態(tài)、滾動跟隨。把這三塊拿捏住了產(chǎn)品經(jīng)理在評審會上的表情就會從皺眉變成點頭。3.1 打字機流式輸出細節(jié)全在這打字機效果的實現(xiàn)本身不復(fù)雜就是定時器里不斷往文本片段上追加字符。但要做到“像”有幾個點必須處理好。第一每幀追加的長度要適中且隨機。如果你每個定時周期只追加一個字符那就太慢了一句幾百字的話要蹦幾十秒用戶早不耐煩了。最好的做法是每次追加1到5個字符偶爾追加一個標(biāo)點符號帶上后面的內(nèi)容模擬出那種“中文按詞組蹦”的節(jié)奏。我的做法是維護一個隊列從剩余文本里隨機截取一段長度然后塞進DOM。第二光標(biāo)要閃爍并且跟文字自然銜接。真實產(chǎn)品在流式輸出時會有一個方塊光標(biāo)或者I型光標(biāo)在文字末尾跳動。前端實現(xiàn)的核心是用CSS動畫處理光標(biāo)的閃爍并把光標(biāo)元素緊跟在文本節(jié)點的后面。第三換行和代碼塊的保留。如果你模擬的回答里帶了換行\(zhòng)u0016n或者Markdown符號直接往innerHTML里塞是會被瀏覽器吞掉的。穩(wěn)妥的做法是先把文本按換行拆成多個段落每個段落獨立渲染段落之間用間距隔開。如果要支持簡單的斜體、加粗可以掛一個輕量的Markdown解析簡易版里我用白名單方式處理了加粗和換行兩種語法。第四也是最容易被忽略的流式追加時要批量操作DOM。如果你每追加一個字符就往DOM里插一次節(jié)點性能會非常恐怖尤其是長回答時頁面會肉眼可見地卡頓。我的做法是計時器每100ms到200ms觸發(fā)一次每次把這一段時間攢下來的文本一次性寫入DOM節(jié)點用textContent更新不做逐字符的createElement。3.2 思考中狀態(tài)隨機延遲才有靈魂思考狀態(tài)的視覺呈現(xiàn)“思考中”這三個字配合呼吸燈式的動畫就夠用了。但要注意暫停時長絕對不能固定固定了就會顯得非常假。真實大模型的響應(yīng)時間跟問題難度強相關(guān)簡單問題一兩秒就回來了復(fù)雜問題可能思考小半分鐘。我的策略是分級隨機延時簡單問題比如“在嗎”“你好”600ms到900ms。普通問題比如“寫一段Python排序代碼”1000ms到1800ms。復(fù)雜問題比如“幫我分析這份數(shù)據(jù)并給出建議”2000ms到3500ms。前端怎么判斷“問題難度”關(guān)鍵詞匹配。命中“分析”“總結(jié)”“對比”“方案”這些詞走長等待分支命中“你好”“謝謝”“在嗎”走短等待分支其他情況走中間檔。雖然這本質(zhì)上是個粗略的映射但觀感上非常接近真實模型的行為。3.3 自動滾動不絲滑等于白做聊天界面最影響體驗的點就是自動滾動。用戶發(fā)出消息后視角會停在輸入框附近這時候回答開始逐步輸出如果頁面沒有平滑地跟著滾動用戶就得手動往下拖體驗直接碎了。自動滾動的核心是每一次更新消息內(nèi)容后都要把滾動容器滾動到底部。但這里有個細節(jié)如果每次都瞬間跳轉(zhuǎn)scrollTopscrollHeight連續(xù)蹦字時看起來就是頁面一抖一抖的。平滑的做法是在每次更新后延遲一幀用requestAnimationFrame再設(shè)置scrollTop并且配合CSS的scroll-behavior: smooth讓動畫有過渡感。另外如果用戶自己向上滾動瀏覽之前的對話內(nèi)容自動滾動應(yīng)該暫停等用戶回到底部再恢復(fù)。簡易版里我加了個判斷如果用戶滾動位置距離底部超過120px則暫不強制滾到底。4. 完整實現(xiàn)與代碼詳解光說不練假把式下面直接上一版能跑的完整代碼。這是一個單文件的HTML頁面復(fù)制到本地就能運行。4.1 核心代碼單文件模擬對話界面!DOCTYPE html html langzh-CN head meta charsetUTF-8 meta nameviewport contentwidthdevice-width, initial-scale1.0 title大模型對話交互模擬-簡易版/title style * { box-sizing: border-box; margin: 0; padding: 0; } body { font-family: -apple-system, BlinkMacSystemFont, Segoe UI, PingFang SC, Microsoft YaHei, sans-serif; background: #f3f4f6; height: 100vh; display: flex; justify-content: center; align-items: center; } .chat-container { width: 480px; height: 720px; background: white; border-radius: 16px; box-shadow: 0 12px 40px rgba(0,0,0,0.08); display: flex; flex-direction: column; overflow: hidden; } .chat-header { padding: 16px 20px; background: white; border-bottom: 1px solid #e7e7e7; display: flex; justify-content: space-between; align-items: center; font-weight: 600; } .chat-main { flex: 1; padding: 20px; overflow-y: auto; background: #fafafa; display: flex; flex-direction: column; gap: 16px; scroll-behavior: smooth; } .msg-row { display: flex; max-width: 85%; } .msg-row.user { align-self: flex-end; } .msg-row.assistant { align-self: flex-start; } .msg-bubble { padding: 12px 14px; border-radius: 12px; line-height: 1.6; font-size: 14px; word-break: break-word; } .msg-row.user .msg-bubble { background: #2563eb; color: white; border-bottom-right-radius: 4px; } .msg-row.assistant .msg-bubble { background: white; border: 1px solid #e7e7e7; border-bottom-left-radius: 4px; } .thinking { display: inline-flex; align-items: center; gap: 4px; color: #888; font-size: 14px; } .dot { width: 6px; height: 6px; border-radius: 50%; background: #aaa; animation: breathe 1.2s infinite ease-in-out; } .dot:nth-child(2) { animation-delay: 0.2s; } .dot:nth-child(3) { animation-delay: 0.4s; } keyframes breathe { 0%, 100% { opacity: 0.3; transform: translateY(0); } 50% { opacity: 1; transform: translateY(-3px); } } .cursor { display: inline-block; width: 2px; height: 16px; background: #2563eb; margin-left: 2px; vertical-align: text-bottom; animation: blink 0.8s step-end infinite; } keyframes blink { 0%, 100% { opacity: 1; } 50% { opacity: 0; } } .chat-input-area { padding: 14px 16px; border-top: 1px solid #e7e7e7; background: white; display: flex; gap: 10px; } #userInput { flex: 1; border: 1px solid #dcdcdc; border-radius: 20px; padding: 10px 16px; font-size: 14px; outline: none; transition: border-color 0.2s; } #userInput:focus { border-color: #2563eb; } #sendBtn { border: none; border-radius: 20px; padding: 10px 20px; background: #2563eb; color: white; font-size: 14px; cursor: pointer; transition: background 0.2s; white-space: nowrap; } #sendBtn:disabled, #sendBtn.disabled { background: #a5b8e8; cursor: not-allowed; } /style /head body div classchat-container div classchat-header spanAI 助手模擬版/span button idclearBtn stylebackground:none;border:none;color:#888;cursor:pointer;font-size:14px;清空/button /div div classchat-main idchatMain div classmsg-row assistant div classmsg-bubble你好我是AI助手。今天有什么可以幫你/div /div /div div classchat-input-area input typetext iduserInput placeholder輸入你的問題... autocompleteoff button idsendBtn發(fā)送/button /div /div script (function() { const chatMain document.getElementById(chatMain); const userInput document.getElementById(userInput); const sendBtn document.getElementById(sendBtn); const clearBtn document.getElementById(clearBtn); const state { messages: [], isStreaming: false, isWaiting: false }; // ------------------- 模擬回答池 ------------------- const REPLY_DATASET [ { keywords: [你好, 在嗎, hi, hello], delayRange: [600, 900], reply: 你好呀我在的有什么想聊的嗎\n\n可以是技術(shù)問題、生活小事也可以只是隨便聊聊天。 }, { keywords: [排序, 代碼, 寫個, 實現(xiàn)], delayRange: [1000, 1800], reply: 給你一個簡單的Python快速排序示例\n\npython\ndef quick_sort(arr):\n if len(arr) 1:\n return arr\n pivot arr[len(arr) // 2]\n left [x for x in arr if x pivot]\n middle [x for x in arr if x pivot]\n right [x for x in arr if x pivot]\n return quick_sort(left) middle quick_sort(right)\n\n\n這段代碼的時間復(fù)雜度是 O(n log n)比較適合入門學(xué)習(xí)。 }, { keywords: [分析, 總結(jié), 對比, 方案, 建議], delayRange: [2000, 3500], reply: 這個問題需要從多個維度來看。\n\n**第一背景梳理**任何建議都離不開具體場景我的理解是你希望得到一套可落地的方案。\n\n**第二關(guān)鍵因素**建議重點關(guān)注可維護性和擴展性優(yōu)先選擇社區(qū)成熟度高的載體。\n\n**第三實操建議**先做最小可用版本驗證核心路徑再逐步疊加后續(xù)能力。\n\n如果你能補充更多細節(jié)我可以進一步細化。 }, { keywords: [], delayRange: [1000, 1800], reply: 收到你的問題我理解了一下大概是這么回事\n\n核心點包括執(zhí)行路徑、預(yù)期效果和潛在風(fēng)險。結(jié)合你已有的情況來看當(dāng)前最關(guān)鍵的是選擇一條阻力最小的執(zhí)行路徑先把主流程跑通再在不斷迭代中一點點修正。\n\n我給我的方案打分的話能拿到75分剩下的25分需要你補充更多上下文。 } ]; // 簡單分詞 關(guān)鍵詞匹配 function pickReply(content) { const lower content.toLowerCase(); for (let i 0; i REPLY_DATASET.length; i) { const item REPLY_DATASET[i]; if (item.keywords.some(kw lower.includes(kw.toLowerCase()))) { return item; } } return REPLY_DATASET[REPLY_DATASET.length - 1]; } // 隨機工具閉區(qū)間 function getRandomRange(min, max) { return Math.floor(Math.random() * (max - min 1)) min; } // ------------------- 渲染 ------------------- function createMsgNode(message) { const row document.createElement(div); row.className msg-row message.role; const bubble document.createElement(div); bubble.className msg-bubble; row.appendChild(bubble); return { row, bubble }; } // 把普通文本轉(zhuǎn)成帶加粗的HTML function formatContent(text) { return text.replace(/\*\*(.?)\*\*/g, strong$1/strong) .replace(/\n/g, br); } function appendUserMessage(content) { const message { id: u_ Date.now(), role: user, content, status: done }; state.messages.push(message); const { row, bubble } createMsgNode(message); bubble.innerHTML formatContent(content); chatMain.appendChild(row); scrollToBottom(); return message; } function appendAssistantMessage() { const message { id: a_ Date.now(), role: assistant, content: , status: waiting }; state.messages.push(message); const { row, bubble } createMsgNode(message); message.domRef { row, bubble }; message.domRef.bubble.innerHTML span classthinkingspan classdot/spanspan classdot/spanspan classdot/span/span; chatMain.appendChild(row); scrollToBottom(); return message; } // ------------------- 流式輸出 ------------------- function streamAssistantMessage(message, fullText, onDone) { message.raw fullText; message.status streaming; const { bubble } message.domRef; let index 0; // 清空思考狀態(tài)準(zhǔn)備打字機輸出 bubble.innerHTML ; const timer setInterval(() { // 每次追加1-5個字符 const step getRandomRange(1, 5); const nextIndex Math.min(index step, fullText.length); message.content fullText.slice(0, nextIndex); index nextIndex; // 更新DOM支持加粗光標(biāo)放在最后 bubble.innerHTML formatContent(message.content) span classcursor/span; scrollToBottom(); if (index fullText.length) { clearInterval(timer); // 移除光標(biāo) bubble.innerHTML formatContent(fullText); message.status done; if (onDone) onDone(); } }, 80); } // 滾動到底部 function scrollToBottom() { requestAnimationFrame(() { chatMain.scrollTop chatMain.scrollHeight; }); } // ------------------- 發(fā)送流程 ------------------- function sendMessage() { const content userInput.value.trim(); if (!content || state.isStreaming || state.isWaiting) return; userInput.value ; appendUserMessage(content); // 思考等待期 const assistantMsg appendAssistantMessage(); state.isWaiting true; setSendBtnDisabled(true); const poolItem pickReply(content); const waitTime getRandomRange(poolItem.delayRange[0], poolItem.delayRange[1]); setTimeout(() { state.isWaiting false; state.isStreaming true; streamAssistantMessage(assistantMsg, poolItem.reply, () { state.isStreaming false; setSendBtnDisabled(false); }); }, waitTime); } function setSendBtnDisabled(flag) { sendBtn.disabled flag; if (flag) { sendBtn.classList.add(disabled); } else { sendBtn.classList.remove(disabled); } } function clearConversation() { state.messages []; state.isStreaming false; state.isWaiting false; setSendBtnDisabled(false); chatMain.innerHTML ; appendAssistantMessage(); // 簡單置為已回復(fù) const firstMsg state.messages[0]; firstMsg.status done; firstMsg.content 你好我是AI助手。今天有什么可以幫你; firstMsg.domRef.bubble.innerHTML formatContent(firstMsg.content); } // ------------------- 事件綁定 ------------------- sendBtn.addEventListener(click, sendMessage); userInput.addEventListener(keydown, (e) { if (e.key Enter) { e.preventDefault(); sendMessage(); } }); clearBtn.addEventListener(click, clearConversation); // 初始化歡迎語 appendAssistantMessage(); const fm state.messages[0]; fm.status done; fm.content 你好我是AI助手。今天有什么可以幫你; fm.domRef.bubble.innerHTML formatContent(fm.content); })(); /script /body /html上面這段代碼直接復(fù)制成html文件用瀏覽器打開就能用。整體流程走下來交互感受和市面上常見的大模型對話產(chǎn)品非常接近。4.2 關(guān)鍵參數(shù)說明打字機節(jié)奏和思考延遲為什么這么定核心參數(shù)我在代碼里都有注釋這里單獨抽出來講一下我調(diào)試多次后的心得。第一打字機定時器間隔設(shè)為80ms。這個值我試過30ms、50ms、80ms、120ms。30ms太急躁字符是一個一個飆出來的完全沒有“正在打字”的感覺120ms又太拖沓一句話要憋很久。80ms配合每次隨機追加1-5個字符平均每個周期輸出3個字符左右也就是每秒差不多37個字符中文場景下這個閱讀節(jié)奏剛剛好不快不慢。第二每次追加的字符長度隨機而不是固定。如果每次都固定追加3個字再看文本輸出你會察覺出一種機械的規(guī)律感。隨機1-5個字符之后輸出節(jié)奏有快有慢像人在敲鍵盤一樣氣口自然很多。隨機算法我用的是Math.random()取整雖然簡單但效果足夠。第三思考等待時間設(shè)置了分級。這個細節(jié)很關(guān)鍵。如果你不管用戶問什么都是固定等1.5秒那短問題就會顯得“反應(yīng)遲鈍”復(fù)雜問題又顯得“過于敷衍”。分級之后感覺完全不同你問“你好”幾乎秒回你問“寫個代碼”肉眼可見地停一下再輸出你問“分析一下數(shù)據(jù)”停下思考的時間明顯更多。真實模型也就是這個行為模式。第四requestAnimationFrame里做滾動。為什么不能用setTimeout因為setTimeout的延遲不可控尤其頁面掉幀時會一頓一頓的。requestAnimationFrame跟瀏覽器渲染同步保證每次內(nèi)容更新后滾動都發(fā)生在渲染完成之前視覺上非常絲滑。4.3 帶代碼塊的回答怎么處理很多前端初學(xué)者模擬對話時會遇到一個尷尬場景回答內(nèi)容里有代碼塊結(jié)果渲染出來要么是代碼消失要么是三個反引號被原樣顯示出來丑得沒法看。簡易版里我做了非?？酥频奶幚碇蛔R別換行和加粗代碼塊用pre標(biāo)簽包裹但代碼塊內(nèi)部的樣式保持等寬字體和背景色。如果你把上面代碼里的formatContent函數(shù)升級成真正支持Markdown的版本完全也行。但這里我有一個忠告簡易版里不要過早引入重型Markdown解析庫。先用白名單方式渲染加粗和代碼塊保留原始文本的能力等真實接入大模型時再決定要不要上完整解析。否則模擬階段的Markdown渲染邏輯和真實環(huán)境不一致到頭來還得返工。5. 常見問題與排坑實錄做這個界面的時候我遇到的坑大概有七八個有些是新手很容易踩進去的有些是我覺得簡單但實際折騰了好一陣的都列一下。5.1 點擊發(fā)送后按鈕沒反應(yīng)這個是最高頻的問題。很多人的實現(xiàn)是點擊發(fā)送立刻append用戶消息然后馬上開始模擬回復(fù)。但因為append和發(fā)送之間沒有做狀態(tài)鎖用戶在思考等待期里連點好幾下就append出了好幾條用戶消息和好幾個assistant氣泡亂七八糟。我處理的方式就是代碼里的開鎖邏輯發(fā)送前先檢查state.isStreaming和state.isWaiting。只要有一個狀態(tài)是true直接return。思考等待期isWaiting和流式輸出期isStreaming結(jié)束后才把鎖釋放。這樣一個簡單狀態(tài)判斷就把重復(fù)提交的問題徹底掐死了。以后你接真實接口這個鎖同樣適用因為真實接口的流式返回期間同樣不允許用戶插話。5.2 打字機輸出時頁面卡頓如果你按最初始的思路每追加一個字符就用createElement創(chuàng)建一個新的文本節(jié)點并且把這個節(jié)點append到bubble里跑一句300字的回復(fù)頁面會創(chuàng)建幾百個DOM節(jié)點卡到飛起。解決思路就是“批量更新”。我的做法是每個定時器周期內(nèi)一次性更新bubble.innerHTML用字符串拼接而不是循環(huán)創(chuàng)建節(jié)點。這種簡單粗暴的innerHTML方式性能比DOM節(jié)點逐個操作強很多。簡易版完全夠用。如果你非要追求極限性能可以用DocumentFragment但innerHTML已經(jīng)能讓這個模擬界面跑得絲滑了。5.3 流式打字中光標(biāo)跑到了奇怪的位置這個問題不常見但一旦出現(xiàn)就很煩。原因是當(dāng)文本內(nèi)容更新時光標(biāo)span如果緊挨著文字沒問題。但如果你把光標(biāo)放在了別的容器里或者bubble內(nèi)部還有其他display:block的子元素光標(biāo)就會掉到下一行。我的建議是光標(biāo)span保持inline-block樣式并且放在文本的最后不要給它加任何外邊距或?qū)挾鹊臉O端值。我用的是width: 2px、height: 16px、vertical-align: text-bottom實戰(zhàn)下來沒出過亂子。5.4 用戶輸入框的回車與中文輸入法沖突當(dāng)你綁定keydown事件時在中文輸入法下按回車是“確認選詞”而不是“發(fā)送消息”。如果你直接監(jiān)聽keydown后就調(diào)用sendMessage會出現(xiàn)一個很尷尬的情況用戶還在選詞字還沒上屏消息就發(fā)出去了。解法有兩個。一是監(jiān)聽keydown時判斷e.isComposing如果為true則直接return。這是最直觀的寫法。二是監(jiān)聽keyup事件再判斷。簡易版里可以用第一種方法但原生input的isComposing屬性部分瀏覽器需要兼容性處理。我這里為了演示簡略直接preventDefault了keydown在正式項目里一定要加上isComposing判斷。5.5 自動滾動與用戶手動滾動打架如果你完全不做判斷用戶往上翻歷史消息時只要新消息還在打字機輸出頁面就會強行把滾動條拉回底部用戶根本沒辦法瀏覽上面的內(nèi)容體驗極差。我引入了一個簡單策略跟蹤用戶是否“靠近底部”。如果當(dāng)前scrollTop clientHeight scrollHeight - 120才執(zhí)行自動滾動否則不滾動。這個120px的閾值是我試出來比較舒適的區(qū)間太近了會導(dǎo)致用戶輕微上滑就被拽回太遠了會導(dǎo)致用戶明明沒在底端內(nèi)容卻一直卡住不動。5.6 清空對話后的狀態(tài)殘留清空對話如果只是把chatMain.innerHTML清空很容易遺漏的是state里isStreaming還鎖著下次發(fā)送直接被return掉用戶會以為程序壞了。所以清空時的完整操作為state.messages重置為空數(shù)組。isStreaming和isWaiting都置為false。sendBtn解除禁用。DOM里清空。重新插入一條歡迎語。狀態(tài)重置和DOM清空缺一不可而且順序不能亂。上面代碼里clearConversation函數(shù)就是標(biāo)準(zhǔn)寫法。5.7 瀏覽器本地直接打開時的跨域警告很多場景下你會直接雙擊本地HTML文件來預(yù)覽如果你在這個文件里通過fetch請求外部媒體資源比如圖片、字體控制臺會報跨域錯誤。這個是瀏覽器安全策略跟你的代碼無關(guān)。簡易版模擬界面不存在這個問題因為所有資源都在頁面內(nèi)部。但如果你參考這個demo往里面加遠程圖標(biāo)、遠程字體就需要考慮本地預(yù)覽時是否會有CORS限制。我的建議是演示用頁面所有靜態(tài)資源一律本地化或者base64內(nèi)置省得出岔子。為了讓你排查時更快定位我把幾個常見問題的速查整理成表了癥狀大概率原因排查順序點擊發(fā)送毫無反應(yīng)狀態(tài)鎖未釋放看isWaiting和isStreaming是否為true檢查是否卡在某個分支光標(biāo)不顯示CSS動畫未觸發(fā)或光標(biāo)被覆蓋檢查.cursor樣式確認其為inline-block且z-index正常打字機速度太快/太慢定時器間隔不合適調(diào)整setInterval的間隔值從80ms起步微調(diào)中文輸入回車誤發(fā)送未判斷isComposing在keydown里加上e.isComposing判斷頁面很卡大量DOM節(jié)點或頻繁重排優(yōu)先改成innerHTML批量更新減少createElement清空后不能聊天狀態(tài)未重置重置isStreaming、isWaiting、messages并恢復(fù)按鈕滾動不跟隨滾動調(diào)用時機太早改為requestAnimationFrame后再設(shè)置scrollTop5.8 現(xiàn)場演示翻車自救指南既然你花力氣做了模擬界面大概率是要拿去演示的。根據(jù)我的教訓(xùn)給你三條現(xiàn)場保命建議。第一提前把頁面用無痕模式打開。無痕模式下不會有瀏覽器緩存、擴展插件干擾樣式和布局最干凈。某些瀏覽器的翻譯插件、去廣告插件會把頁面搞得面目全非。第二展示前先把字體調(diào)大。如果現(xiàn)場是投屏建議把瀏覽器縮放級別提高到120%并把聊天界面的默認字號從14px調(diào)大到15或16px。遠距離觀看時小字號會讓人下意識覺得這界面很“廉價”。第三準(zhǔn)備一個備用頁面。如果現(xiàn)場不幸出現(xiàn)白屏、卡死、瀏覽器崩潰你不用重新來按一下熱鍵直接打開一個純靜態(tài)的備用頁面只需要保留最基本的聊天UI和歡迎語就行。這個備用頁我一般叫做“降級預(yù)案”做一次能用很久。6. 從模擬走向真實接入的平滑過渡方案標(biāo)題里寫的是“簡易版”但我知道你遲早會往真實接口上切。這里給一個遷移路徑保證模擬階段寫好的交互代碼不會白費。6.1 把模擬數(shù)據(jù)源封裝成獨立Service最理想的做法是代碼里所有的數(shù)據(jù)來源都走一個service層。比如你定義一個getAssistantReply(message)函數(shù)模擬階段它返回一個Promise內(nèi)部走定時器和打字機真實階段它換成fetch調(diào)用真實接口返回ReadableStream用await循環(huán)讀取chunk并逐步渲染。模擬階段示例async function getAssistantReply(content, onChunk) { const poolItem pickReply(content); const waitTime getRandomRange(poolItem.delayRange[0], poolItem.delayRange[1]); await sleep(waitTime); // 逐段輸出 const segs splitTextToSegments(poolItem.reply); for (const seg of segs) { await sleep(80); onChunk(seg); } }真實階段示例偽代碼async function getAssistantReply(content, onChunk) { const resp await fetch(/api/chat, { method: POST, body: JSON.stringify({ messages: buildMessages(content) }) }); const reader resp.body.getReader(); const decoder new TextDecoder(); while (true) { const { done, value } await reader.read(); if (done) break; onChunk(decoder.decode(value, { stream: true })); } }可以看到整個頁面的渲染邏輯、狀態(tài)鎖、滾動邏輯完全不變只是數(shù)據(jù)源實現(xiàn)從“模擬延時”換成“真實流式”。這就是你花時間設(shè)計數(shù)據(jù)模型的最大收益。6.2 簡易版的邊界要心里有數(shù)這個簡易版能覆蓋90%的靜態(tài)演示場景但有幾件事它做不到需要你心里有數(shù)它不認識上下文。雖然UI上有歷史消息但模擬回答沒有真正引用前文不會根據(jù)上下文自動變化。真實大模型的上下文關(guān)聯(lián)能力它自然是沒有的。它沒有記憶和人格一致性。你問同一個問題兩次得到的回答完全一樣不會因為聊過之后改了風(fēng)格而換說法。它沒有工具調(diào)用和知識檢索。如果你的產(chǎn)品重點在“AI能查數(shù)據(jù)庫”“AI能調(diào)用API”那模擬層就得做得更厚需要偽造一套工具調(diào)用的UI回顯。清楚邊界你就不會拿模擬版去騙人也不會拿模擬版去應(yīng)付真正的需求評審。模擬版就是模擬版它是你的開發(fā)腳手架不是最終交付物。這一點做的時候要拎得清。6.3 后續(xù)還能擴展的三個方向順著目前的代碼往下走值得立刻嘗試的擴展有三個難度遞增但每個都能讓演示效果再上一個臺階。一是多套角色語氣包。模擬回答池里目前是“通用助手”的口吻你可以再維護一份“毒舌”“嚴謹”“溫柔”等語氣模板演示時切換角色設(shè)定效果會很驚艷。二是Markdown渲染升級。把formatContent函數(shù)換成按行解析支持標(biāo)題、列表、引用、表格代碼塊高亮。接入真實接口后這部分就能直接復(fù)用。三是會話管理。支持多個會話的創(chuàng)建、切換、刪除每個會話獨立維護messages數(shù)組。這是從“單頁Demo”走向“正式產(chǎn)品”的關(guān)鍵一步數(shù)據(jù)模型層面只需在state里加一個sessions對象就行了。我在實際項目里確實遇到過不少次“先把界面做好后端接口還沒影”的情況。早期我也不愛做模擬層總覺得是“搞虛的”后來被現(xiàn)實教育過幾次才明白前端交互的打磨本身就極其依賴一個穩(wěn)定的、可控的、可重復(fù)測試的數(shù)據(jù)源。真實接口太不確定你沒法在上面穩(wěn)定復(fù)現(xiàn)一個布局問題或者滾動問題。反而是模擬數(shù)據(jù)源讓你能精確控制每一輪對話的內(nèi)容長度、延遲時長、輸出節(jié)奏這樣才能把界面調(diào)到真的順手。這版簡易模擬界面的代碼我后來又加了支持多輪上下文、代碼高亮、會話管理的升級版但核心的骨架和狀態(tài)機邏輯一直還是這版的樣子。說句實話想清楚狀態(tài)剩下的活兒都是體力活。希望這版拆解能讓你少踩幾個坑直接把交互體驗做到位。