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