1. 為什么要在單頁 HTML 里做「決策點」這件事第一次看到answer-me-with-html這個思路時我腦子里蹦出來的不是某個具體框架而是一個很樸素的場景你手上有一份說明文檔、一份操作手冊、一份選型指南讀者讀完之后往往卡在「那我到底該選哪個」這一步。傳統(tǒng)做法是寫一堆「如果……那么……」的段落讀者自己在大腦里做條件判斷讀起來累還容易漏掉分支。ask組件想解決的就是這個問題——把決策點從文字里拎出來變成一個可以點、可以選、可以立刻看到結(jié)果的交互塊而且整個東西就塞在一頁 HTML 里不需要后端、不需要構(gòu)建工具、不需要裝任何依賴。這個定位很關(guān)鍵。它不是要做一個完整的問卷系統(tǒng)也不是要替代正經(jīng)的表單引擎而是服務(wù)于「單頁、靜態(tài)、可分發(fā)」這個約束。你可以把這一頁 HTML 直接發(fā)給同事、丟進(jìn)內(nèi)網(wǎng)共享盤、塞進(jìn)郵件附件對方雙擊就能用。ask組件承擔(dān)的角色就是頁面里那些「由你決定」的岔路口用戶點一個選項頁面就地給出對應(yīng)的下一步內(nèi)容而不是跳轉(zhuǎn)、不是刷新、不是等接口返回。適合誰來參考三類人最對口。第一類是經(jīng)常寫內(nèi)部文檔、操作手冊的人想讓文檔從「讀」變成「用」第二類是做輕量工具的前端手頭沒有后端資源但又想交付帶交互的東西第三類是對「漸進(jìn)增強(qiáng)」這套理念感興趣、想看看純靜態(tài)頁面能把交互做到什么程度的開發(fā)者。哪怕你只會寫最基礎(chǔ)的 HTML 和一點點 JavaScript這篇里的思路和代碼都能直接抄。我先把核心結(jié)論擺出來ask組件的本質(zhì)是一個聲明式的分支容器。你用一段結(jié)構(gòu)化的數(shù)據(jù)描述「問題是什么、有哪些選項、每個選項通向哪段內(nèi)容」組件負(fù)責(zé)渲染、負(fù)責(zé)狀態(tài)管理、負(fù)責(zé)把選中的結(jié)果反饋到頁面上。它不發(fā)明新語法而是盡量貼著 HTML 的原生能力走這樣即使腳本沒跑起來頁面也不至于變成一片空白。下面我從設(shè)計取舍講起一路講到能跑起來的實現(xiàn)和踩過的坑。2. 整體設(shè)計與思路拆解2.1 為什么是「單頁 內(nèi)嵌數(shù)據(jù)」而不是多頁跳轉(zhuǎn)多頁方案聽起來更「正規(guī)」每個分支一個頁面用鏈接串起來。但我實測下來單頁內(nèi)嵌數(shù)據(jù)在這個場景里優(yōu)勢明顯。原因有三條都是實打?qū)嵉墓こ炭剂?。第一是分發(fā)成本。多頁意味著多個文件接收方要保證目錄結(jié)構(gòu)不亂、相對路徑不斷。一旦有人把其中一頁單獨轉(zhuǎn)發(fā)出去鏈接就廢了。單頁 HTML 把樣式、腳本、數(shù)據(jù)全打包在一個文件里天然是「一個文件即一個完整應(yīng)用」轉(zhuǎn)發(fā)、歸檔、版本管理都簡單。第二是狀態(tài)連續(xù)性。決策往往不是一次性的用戶選了 A 之后可能想回頭改成 B看看結(jié)果差多少。單頁方案里歷史選擇可以留在內(nèi)存甚至留在 URL 的 hash 里回退和對比都很自然多頁方案要么靠瀏覽器前進(jìn)后退要么靠服務(wù)端會話前者體驗割裂后者直接違背了「無后端」的前提。第三是渲染時機(jī)。單頁里所有分支內(nèi)容在初始加載時就已存在于 DOM 或數(shù)據(jù)里切換只是顯示與隱藏沒有網(wǎng)絡(luò)往返點下去是即時的。這種「零延遲」的反饋感是讓讀者愿意去點、去試的關(guān)鍵。人對等待的容忍度很低哪怕只有 200 毫秒的加載態(tài)也會打斷「我在探索」的心流。當(dāng)然單頁也有代價所有分支內(nèi)容都堆在一個文件里文件體積會隨分支數(shù)量線性增長。這就引出下一個取舍——數(shù)據(jù)怎么組織。2.2 數(shù)據(jù)驅(qū)動的聲明式結(jié)構(gòu)把「分支邏輯」和「渲染邏輯」分開我見過不少同類實現(xiàn)是把分支邏輯直接寫死在事件回調(diào)里點按鈕 A就document.getElementById(resultA).style.display block。這種寫法在分支少的時候沒問題一旦分支超過五六個回調(diào)里全是 DOM 操作改一個文案要翻半天加一個分支要復(fù)制粘貼一大段維護(hù)性很差。ask組件采用的是數(shù)據(jù)驅(qū)動分支關(guān)系用一份純數(shù)據(jù)描述渲染和交互由通用代碼處理。數(shù)據(jù)結(jié)構(gòu)大致長這樣——一個問題對象帶id、prompt問題文案、options選項數(shù)組每個選項帶label顯示文字、value內(nèi)部值、next選中后要展示的內(nèi)容標(biāo)識或下一問的 id。這份數(shù)據(jù)可以是頁面里一段script typeapplication/json也可以是 JS 里一個常量對象。這么拆的好處很直接。改文案不用碰邏輯你只動數(shù)據(jù)里的字符串加分支不用改渲染代碼往options里追加一項、在內(nèi)容區(qū)補(bǔ)一段對應(yīng)標(biāo)識的 HTML 就行測試也容易數(shù)據(jù)是純對象可以單獨校驗有沒有懸空引用某個next指向了不存在的內(nèi)容。這就是「聲明式」相對「命令式」的典型收益描述「是什么」而不是「怎么做」。提示數(shù)據(jù)里所有next引用建議在初始化時做一次完整性校驗發(fā)現(xiàn)指向不存在的內(nèi)容標(biāo)識就拋錯并在控制臺打印出來。這個校驗只花幾行代碼卻能擋掉絕大多數(shù)「點了沒反應(yīng)」的低級問題。2.3 漸進(jìn)增強(qiáng)的底線腳本掛了頁面還得能讀這是我在實際項目里最看重的一條。單頁交互組件最容易犯的錯是把所有內(nèi)容都藏在 JS 里腳本一報錯用戶看到的就是一片空白。ask組件的設(shè)計原則是分支內(nèi)容默認(rèn)就在 HTML 里只是被折疊腳本的作用是「讓折疊可交互」而不是「憑空生成內(nèi)容」。具體做法是每個分支結(jié)果塊用原生details或者帶hidden屬性的容器承載初始狀態(tài)是收起或隱藏。腳本加載成功后接管這些容器的顯隱控制并給選項按鈕綁定事件。如果腳本因為某種原因沒執(zhí)行比如被安全策略攔了、語法寫錯了用戶至少還能看到問題文案和所有分支的原始內(nèi)容雖然體驗降級但信息沒丟。這個底線思維還帶來一個附帶好處對搜索引擎和讀屏軟件更友好。內(nèi)容在 DOM 里是真實存在的不是運行時拼出來的可訪問性和可索引性都更好。做靜態(tài)頁面的人容易忽略這點但一旦你的頁面要被歸檔、被檢索、被輔助技術(shù)讀取這個差別就出來了。2.4 狀態(tài)模型單選、多選與「可回退」ask組件支持兩種基本模式單選radio 語義和多選checkbox 語義。單選適合「二選一、三選一」的排他決策多選適合「勾選你需要的功能我告訴你組合結(jié)果」這類場景。狀態(tài)用一個普通對象維護(hù)鍵是問題 id值是選中的 value單選或 value 數(shù)組多選。「可回退」是我特意加的設(shè)計。用戶改主意時不應(yīng)該被迫刷新頁面重來。實現(xiàn)上每次選擇變化都觸發(fā)一次「重算」清空當(dāng)前問題下游的所有結(jié)果塊顯隱狀態(tài)再根據(jù)新選擇重新展示。這里有個細(xì)節(jié)——下游的連鎖問題也要一并重置否則會出現(xiàn)「上一問改了下一問還停留在舊答案」的錯位。我的做法是給每個問題標(biāo)記它屬于哪條鏈路重算時按鏈路順序清理。3. 核心細(xì)節(jié)解析與實操要點3.1 一份能直接用的數(shù)據(jù)結(jié)構(gòu)長什么樣先看數(shù)據(jù)。我把一個完整的ask配置寫成下面這樣字段命名盡量直白不搞縮寫const askConfig { questions: [ { id: q-deploy, prompt: 你的部署環(huán)境更接近哪種, mode: single, options: [ { label: 完全離線不能連外網(wǎng), value: offline, next: r-offline }, { label: 可以訪問公網(wǎng), value: online, next: r-online }, { label: 不確定需要先確認(rèn), value: unknown, next: r-unknown } ] }, { id: q-scale, prompt: 預(yù)計同時使用的人數(shù)規(guī)模, mode: single, options: [ { label: 10 人以內(nèi), value: small, next: r-small }, { label: 10 到 100 人, value: medium, next: r-medium }, { label: 100 人以上, value: large, next: r-large } ] } ] };幾個字段的用意值得說清楚。mode決定渲染成單選還是多選控件next指向結(jié)果塊的標(biāo)識結(jié)果塊本身在 HTML 里用>.ask-option input { position: absolute; opacity: 0; width: 1px; height: 1px; } .ask-option label { display: block; padding: 12px 16px; border: 1px solid #d0d5dd; border-radius: 8px; cursor: pointer; } .ask-option input:checked label { border-color: #2563eb; background: #eff6ff; } .ask-option input:focus-visible label { outline: 2px solid #2563eb; outline-offset: 2px; }這段 CSS 里:focus-visible那一條別省。很多人做自定義控件時把焦點樣式去掉了鍵盤用戶按 Tab 鍵完全不知道焦點在哪這是實打?qū)嵉目捎眯匀毕荨?.3 結(jié)果塊的顯隱控制與過渡結(jié)果塊我建議用hidden屬性控制顯隱而不是display:none內(nèi)聯(lián)樣式。原因是hidden是語義化的讀屏軟件會跳過它而且用 JS 切換時只需el.hidden true/false比操作style干凈。如果要做淡入過渡可以在hidden切換后加一個 class 觸發(fā) CSS 動畫但注意hidden元素本身不參與布局動畫要配合starting-style或者先移除hidden再加 class 的兩步走。實測下來最穩(wěn)的過渡方案是移除hidden的同時加.is-entering類下一幀移除該類CSS 里.is-entering { opacity: 0; transform: translateY(4px); }配合transition。這樣既有動畫又不會因為hidden和display的沖突導(dǎo)致動畫不觸發(fā)。3.4 事件委托別給每個選項單獨綁事件分支一多選項按鈕可能幾十個。給每個都addEventListener不是不行但沒必要而且動態(tài)增刪選項時還要記得解綁。更穩(wěn)的做法是在問題容器上做事件委托監(jiān)聽change事件原生控件會冒泡從event.target往上找最近的.ask-option讀出它的>container.addEventListener(change, (e) { const input e.target.closest(input[data-question]); if (!input) return; handleSelect(input.dataset.question, input.value, input.type checkbox); });事件委托還有個隱性好處新增的問題塊自動生效不用重新綁定。如果你的頁面是分步加載問題比如先展示第一問答完再展示第二問這個特性省掉不少初始化代碼。4. 實操過程與核心環(huán)節(jié)實現(xiàn)4.1 從零搭一個可運行的最小版本我把完整流程拆成五步照著做半小時能跑起來。第一步建 HTML 骨架。一個main容器里面放問題區(qū)div idask-questions和結(jié)果區(qū)div idask-results。結(jié)果區(qū)里預(yù)先寫好所有分支內(nèi)容塊每個帶>main div idask-questions/div div idask-results section>function syncHash(state) { const params new URLSearchParams(); Object.entries(state).forEach(([k, v]) { params.set(k, Array.isArray(v) ? v.join(,) : v); }); history.replaceState(null, , # params.toString()); }這個技巧的價值在于零成本的可分享性。對方打開鏈接直接看到你選的那條路徑的結(jié)果不用重新點一遍。注意多選值用逗號連接時要確保 value 里不含逗號前面說的「value 用英文短橫線命名」在這里又派上用場。4.4 實操現(xiàn)場一次真實的分支調(diào)試記錄說個我實際調(diào)試時遇到的場景。當(dāng)時配了一個三問的決策鏈第二問的選項next指向了第三問的問題 id而不是結(jié)果塊標(biāo)識。結(jié)果就是用戶答完第二問第三問沒出現(xiàn)頁面卡住。問題出在數(shù)據(jù)里——我把「指向下一問」和「指向結(jié)果」用了同一個next字段但渲染邏輯只處理了結(jié)果塊的情況。修復(fù)方案是給next加類型區(qū)分值以q-開頭視為下一問以r-開頭視為結(jié)果塊。渲染時先判斷前綴再決定是展開問題還是顯示結(jié)果。這個約定簡單但有效比在數(shù)據(jù)里加nextType字段更省事也更好記。教訓(xùn)是數(shù)據(jù)契約里的隱式約定要寫進(jìn)注釋否則過兩周自己都忘了q-和r-是什么意思。5. 常見問題與排查技巧實錄5.1 點了選項沒反應(yīng)從三個方向排查這是最高頻的問題。我的排查順序是固定的基本能在兩分鐘內(nèi)定位。先看事件有沒有綁上。在change監(jiān)聽里打一行console.log點選項看有沒有輸出。沒有輸出說明監(jiān)聽沒生效常見原因是容器選擇器寫錯或者腳本在 DOM 就緒前執(zhí)行了腳本放在head里又沒加defer。再看狀態(tài)有沒有更新。有輸出但頁面沒變就在handleSelect里打印state看值有沒有進(jìn)去。沒進(jìn)去多半是dataset讀錯了比如 HTML 里寫>:root { --ask-border: #d0d5dd; --ask-bg-checked: #eff6ff; --ask-accent: #2563eb; } media (prefers-color-scheme: dark) { :root { --ask-border: #3a3f4a; --ask-bg-checked: #1e2a44; --ask-accent: #60a5fa; } }5.4 獨家避坑別在結(jié)果塊里再嵌ask組件我試過在結(jié)果塊內(nèi)部再放一個ask問題想做「答完這問還有下一問」的嵌套。技術(shù)上能跑但狀態(tài)管理會變得很繞——外層重算時要不要清空內(nèi)層內(nèi)層的選擇要不要參與 URL 序列化用戶回退時內(nèi)層狀態(tài)怎么恢復(fù)這些問題疊加起來代碼復(fù)雜度陡增。后來我改成扁平化鏈路所有問題平鋪在一個問題區(qū)用next指向下一問的 id 來表達(dá)順序結(jié)果塊只放最終結(jié)論不再嵌套問題。這樣狀態(tài)是一維的重算邏輯簡單URL 序列化也直觀。嵌套看起來優(yōu)雅實際是給自己挖坑除非你的決策樹真的需要「不同分支走完全不同的子問題集」否則別碰。提示如果你的分支確實需要不同的子問題用「問題可見性」來控制——所有問題都在 DOM 里但只有當(dāng)前鏈路激活的問題才顯示。這比嵌套容器好維護(hù)得多。6. 組件之外這套思路還能怎么延展ask組件跑通之后我發(fā)現(xiàn)它的核心模式——「聲明式數(shù)據(jù) 原生控件 結(jié)果塊顯隱」——可以遷移到不少相鄰場景。比如做一個配置推薦器用戶勾選自己的使用場景頁面實時拼出一段推薦配置文本或者做一個故障自查向?qū)О船F(xiàn)象逐層排除最后定位到具體原因和處置步驟。這些場景的共同點是「輸入是有限選項、輸出是預(yù)置內(nèi)容」正好落在ask的能力圈里。延展時唯一要守住的是那條漸進(jìn)增強(qiáng)的底線結(jié)果內(nèi)容始終在 HTML 里腳本只負(fù)責(zé)顯隱和狀態(tài)。守住這條你的單頁工具就能在任何環(huán)境下至少「可讀」而不是把全部價值押在一段可能出錯的腳本上。我在實際交付里越來越覺得靜態(tài)頁面的可靠性不來自代碼多精巧而來自「最壞情況下還剩多少可用信息」這個冗余設(shè)計。ask組件把冗余留在了 DOM 里這是我愿意在多個項目里復(fù)用它最主要的原因。