1. 从一句话需求到可交付页面整体设计思路上周同事甩过来一句话能不能做个 HTML 选择题页面给新来的实习生练手用需求就一行但真做起来能拆出的东西不少——题型怎么定、判分在哪算、答到一半刷新了要不要保住进度、手机上行不行。这篇文章就把我从零做这个页面的完整过程摊开讲包括代码、参数选择和我自己踩过的坑。不管你是刚学 HTML 想找个练手项目还是需要给团队做一个轻量随堂小测这套方案都能直接拿去改。先用一句话说清楚这东西是什么它是一个跑在浏览器里的单页应用用原生 HTML 搭结构、CSS 管样式、JavaScript 管题库渲染和判分不依赖任何框架和构建工具双击打开就能用。适合的场景很具体内部培训随堂测、在线课程的小节测验、面试笔试题原型、给学生演示前端交互的教学素材。1.1 先把需求拆成四件事拿到做个选择题页面这种模糊需求我习惯先把边界定死。第一步问题型只有单选还是单选多选混排第二步问判分时机边答边判还是交卷后统一给结果第三步问题库规模十道题和三百道题的架构完全不同前者可以直接内联在 JS 里后者必须有独立数据文件甚至后端接口。第四步问使用环境只在自己的电脑上演示还是要发给别人用手机打开这四个问题的答案直接决定后面的技术走向。我这个项目最终定的是单选为主、多选题混排、交卷后统一判分并展示解析、题库二十道左右用独立 JSON 存放、必须支持手机。定完边界剩下的就是纯执行不会再中途反复改结构。提示需求越模糊越要在动手前把上面四个问题问清楚。我见过太多人闷头写完八十行 CSS结果对方一句我要能在手机上答题就得重做布局。1.2 技术选型为什么是原生 HTML CSS JS很多人第一反应是上框架觉得用组件库搭表单更省事。但这类页面恰恰是原生方案的主场。原因有三其一一个选择题页面的核心交互只有选中和提交两个动作状态量极小用原生表单元素自带的选中状态就够了引入状态管理反而是杀鸡用牛刀。其二用框架就要考虑构建、依赖安装、打包产物交付物从一个 HTML 文件变成一堆资源发给不懂技术的人根本用不起来。其三原生方案的文件体积通常在几十 KB 以内弱网环境下也是瞬间打开。反过来说什么情况该上框架当你要做的是一个题库后台——需要题目增删改查、分类管理、成绩统计分析、多角色权限——那原生就撑不住了老老实实用成熟框架加服务端。选型判断的标准不是哪个更先进而是这个项目的复杂度到底落在哪一层。1.3 文件结构和命名约定我最终的文件长这样只有五个文件结构一目了然quiz/ ├── index.html # 页面骨架 ├── style.css # 全部样式 ├── quiz.js # 渲染 判分逻辑 ├── questions.json # 题库数据 └── README.md # 使用说明命名上我坚持几个习惯类名用 BEM 风格的block__element--modifier比如.question__stem、.option__key、.option--right好处是半年后回来看代码光看类名就知道这元素属于哪块。ID 只留给 JS 要抓的少数几个节点比如#quizForm、#submitBtn绝不拿 ID 当样式钩子。CSS 变量统一放在:root里改主题色只需要动一处不用全局搜索替换。2. 页面骨架从 DOCTYPE 开始的每个细节HTML 骨架是这个项目里最容易被轻视的部分但恰恰是出错最多的地方。乱码、样式在手机上比例不对、点击热区太小这些问题八成能追溯到头部那几行元信息或者一个没写对的标签上。这一章把骨架逐块拆开说。2.1 头部三行元信息写错一行就出问题!DOCTYPE html html langzh-CN head meta charsetUTF-8 meta nameviewport contentwidthdevice-width, initial-scale1.0 titleHTML 基础随堂小测/title link relstylesheet hrefstyle.css /head第一行!DOCTYPE html必须写而且建议就放在文件第一行。漏掉它会触发浏览器的怪异模式盒模型按老式规则计算——你设的width会把padding和border一起算进去明明写了width: 300px实际内容区只剩两百多像素怎么调都觉得别扭。规范上允许 DOCTYPE 前面有空白和注释但养成第一行就写的习惯没坏处。meta charsetUTF-8决定中文能不能正常显示。它必须出现在文档前 1024 字节以内所以紧跟head是稳妥做法。中文页面用 UTF-8别用 GBK否则你本地看着正常发给别人就全是问号。lang属性写zh-CN——BCP 47 标签大小写不敏感zh-cn和zh-CN等价写成前者也不会报错只是规范写法是后者。这个属性影响屏幕阅读器的发音、字体回退策略和浏览器断词规则别省。viewport 那一行决定移动端表现。widthdevice-width让页面宽度等于设备逻辑宽度initial-scale1.0让初始缩放为 1。没有这行手机上会按 980 像素的虚拟宽度渲染字小得像蚂蚁用户得双指放大才能看。2.2 用 fieldset 和 legend 搭出语义化题目容器题目的容器我用的不是div而是fieldset配legend。原因在于一组单选按钮天然就是一组表单控件fieldset的语义就是将相关控件分组而legend是这组的标题。屏幕阅读器读到这一组时会先念题干再念选项体验完全不同。这是免费的可用性提升不花一分力气。form idquizForm novalidate fieldset classquestion>:root { --brand: #2f6fed; --right: #16a34a; --wrong: #dc2626; --line: #e5e7eb; --text: #1f2937; --muted: #6b7280; --radius: 10px; } .option { display: flex; align-items: flex-start; gap: 10px; padding: 12px 14px; border: 1px solid var(--line); border-radius: var(--radius); cursor: pointer; transition: background-color .15s, border-color .15s; } .option input:checked ~ .option__key { background: var(--brand); color: #fff; border-color: var(--brand); } .option:has(input:checked) { border-color: var(--brand); background: #f5f8ff; }这里有个值得说的取舍。上色我用的是相邻兄弟选择器input:checked ~ .option__key来控制选项序号小圆点的颜色这个写法兼容性极好从很老的浏览器到最新版本都能跑。而给整行加浅蓝底用了:has()——它让父元素能感知子元素状态语义上更优雅。:has()在近几年的主流浏览器里已经可用但如果你的用户里还有大量老旧设备稳妥做法是额外给.option绑一个类名或者干脆只保留小圆点变色视觉反馈也够用。另外别把input用display: none藏起来。藏掉之后键盘用户没法聚焦也没法用方向键切换选项焦点环也一起消失了。正确做法是把它留在文档流里用position: absolute; opacity: 0或者裁剪方式视觉隐藏。更好的方式是保留它只是让它视觉上不抢戏。3. 题库数据模型与动态渲染结构搭好之后接下来是题从哪来。这一步的设计直接决定了后续维护的难易程度——题库写在 JS 里还是单独存文件字段怎么定都会在后期加题、改题时体现出来。3.1 题库用什么格式存内联数组、JSON、还是接口三种常见做法各有各的适用面。内联在 JS 文件里的数组优点是双击 HTML 就能用没有任何加载问题缺点是题目多了文件臃肿而且改题要动 JS 代码。独立的 JSON 文件优点是题库和代码分离非技术人员也能照着格式加题缺点是通过fetch加载时如果直接用file://协议双击打开页面会被浏览器的跨源策略拦住控制台报错页面一片空白。这几乎是所有人第一次做这个项目时都会撞上的墙。提示本地双击打开 HTML 时fetch(questions.json)会失败。解决办法有两个一是起一个本地静态服务比如用 Python 的http.server模块在项目目录跑一个二是把题库直接内联成 JS 变量牺牲一点可维护性换零配置。我的做法是两套都留questions.json作为标准题库quiz.js里保留一段内联的后备数据。加载逻辑先尝试fetch失败就退回内联数据这样无论用户怎么打开都能跑起来。题库字段最后定成这样{ version: 1.0, questions: [ { id: q1, type: single, stem: 下面哪个声明用于把文档标记为 HTML5, options: [ { key: A, text: !DOCTYPE html }, { key: B, text: meta charset\utf-8\ }, { key: C, text: html lang\zh-CN\ }, { key: D, text: !DOCTYPE HTML PUBLIC \-//W3C//DTD HTML 4.01//EN\ } ], answer: [A], analysis: HTML5 把文档类型声明简化为一种写法不区分大小写。 } ] }version字段看着多余等你要做断点续答时就知道它的价值了——题库一改旧的作答记录可能对不上题目靠版本号判断要不要丢弃旧数据。answer我统一用数组哪怕单选题只有一个正确项这样判分函数只需要写一套。3.2 渲染逻辑一趟生成整份卷子渲染我写成一个纯函数输入题库和容器输出完整 DOM。整个过程只操作一次真实 DOM先把所有题目拼成文档片段再插入避免在循环里反复触发重排。function renderQuiz(questions, formEl) { const frag document.createDocumentFragment(); questions.forEach((q, i) { const fs document.createElement(fieldset); fs.className question; fs.dataset.qid q.id; fs.dataset.type q.type; const lg document.createElement(legend); lg.className question__stem; lg.innerHTML span classquestion__no${i 1}/span${escapeHtml(q.stem)}; const box document.createElement(div); box.className question__options; q.options.forEach(opt { const label document.createElement(label); label.className option; label.innerHTML input type${q.type single ? radio : checkbox} name${q.id} value${opt.key} span classoption__key${opt.key}/span span classoption__text${escapeHtml(opt.text)}/span ; box.appendChild(label); }); fs.appendChild(lg); fs.appendChild(box); frag.appendChild(fs); }); formEl.innerHTML ; formEl.appendChild(frag); } function escapeHtml(str) { return String(str).replace(/[]/g, c ({ : amp;, : lt;, : gt;, : quot;, : #39; }[c])); }escapeHtml这个函数别省。你的题干和选项来自 JSON里面大概率包含、这种字符——毕竟考的就是 HTML 标签。不转义的话浏览器会把它当成真标签解析要么内容凭空消失要么页面结构被撕开一个口子。3.3 只保留一份状态FormData 是天然的状态容器新手常见做法是额外维护一个对象记录每道题选了啥然后在change事件里手动更新。问题是这个对象和 DOM 里的真实选中状态是两份数据一旦哪次忘了同步就会出现界面上选了但判分说没选的诡异 bug。我的做法是彻底不维护额外状态需要的时候直接从表单读function collectAnswers(formEl) { const data new FormData(formEl); const result {}; QUESTIONS.forEach(q { result[q.id] data.getAll(q.id).sort(); }); return result; }FormData有个非常适合这个场景的特性没被选中的复选框不会出现在结果里getAll返回空数组。这意味着没答和答了但没选这项天然区分开了不需要额外判断。单选框因为是同name互斥getAll也只会返回一个值套用同一套逻辑毫无问题。这样一来整个项目里关于作答状态就只有一个真理来源——DOM 本身。4. 交互与判分把逻辑写对比写炫更重要前面的都是铺垫这一章才是真正决定这个页面能不能用的部分。判分逻辑写错界面再漂亮也是白搭。4.1 单选与多选的判定差异单选判定简单选中值等于正确值就对。多选题麻烦一些要处理选少了和选多了两种情况而且顺序不能影响结果。function isCorrect(q, picked) { const right q.answer.slice().sort(); const mine picked.slice().sort(); if (right.length ! mine.length) return false; return right.every((k, i) k mine[i]); }先比数量再比内容三步下来逻辑是完备的。数量不等直接判错覆盖了多选和少选数量相等时逐项比对因为两边都排过序顺序不影响结果。这种集合相等的判定思路在很多场景都能复用比如权限比对、标签匹配。还有一个容易被忽略的规则问题多选题少选算不算对有些考试里少选给一半分多选则零分。我在项目里加了个可配置项strictMode: true表示必须完全匹配false时少选给部分分。这个决定权应该交给用的人而不是写死在代码里。4.2 事件委托与作答进度统计选项是动态生成的如果给每个input都绑一个change监听二十道题四五个选项就是上百个监听器虽然现代浏览器扛得住但这写法本身不优雅而且重新渲染一次就得重新绑。更好的做法是在form上绑一个委托监听formEl.addEventListener(change, e { if (!e.target.matches(input[typeradio], input[typecheckbox])) return; updateProgress(); }); function updateProgress() { const answers collectAnswers(formEl); const done Object.values(answers).filter(v v.length 0).length; document.getElementById(answered).textContent done; document.getElementById(total).textContent QUESTIONS.length; }事件冒泡到form才处理一个监听器搞定全部。updateProgress顺便还能用来做顶部进度条——把done / total塞进 CSS 变量的--progress宽度就跟着动实现成本极低但用户感知很强。另外表单右上角那个已答 X 题的提示不只是好看。实测下来用户在二十道题的卷子里很容易漏答有了这个计数交卷前扫一眼就知道还差几道减少了交完才发现空了三题的尴尬。4.3 交卷、反馈与结果汇总判分结果我分三层呈现避免用户一次被塞太多信息。第一层是每题下方的小标记答对的选项边框变绿并加一个小对勾答错的变红同时把正确选项也高亮出来。第二层是顶部的结果条得分 85 分答对 17 题用时 8 分 32 秒。第三层是答案解析默认收起想看的人点开。function grade(pickedMap) { let score 0; QUESTIONS.forEach(q { const fs formEl.querySelector([data-qid${q.id}]); const picked pickedMap[q.id] || []; const ok isCorrect(q, picked); fs.classList.add(ok ? question--right : question--wrong); fs.querySelectorAll(.option).forEach(label { const key label.querySelector(input).value; const hit picked.includes(key); const truth q.answer.includes(key); if (truth) label.classList.add(option--truth); if (hit !truth) label.classList.add(option--wrong); }); if (q.analysis) { const tip document.createElement(p); tip.className question__analysis; tip.textContent 解析 q.analysis; fs.appendChild(tip); } if (ok) score; }); return score; }判分完后要禁用表单防止用户发现自己答错后偷偷改答案——虽然这是个随堂小测没人较真但从交互设计上说提交后进入只读状态是必要的。做法很简单遍历所有input设disabled true同时把下方按钮从交卷切换成重做。5. 值得加的四个进阶功能基础版本做完功能上其实是够用的。但有几个小功能加进来的性价比特别高几乎不增加复杂度体验提升却很直观。5.1 倒计时与超时自动交卷计时器有个经典坑用setInterval每秒把剩余秒数减一。这个写法在页面切到后台时会被浏览器节流——切回来发现计时器慢了十几秒时间就不准了。稳妥做法是记下截止时间戳每次只算和当前时间的差值const deadline Date.now() 15 * 60 * 1000; function tick() { const left Math.max(0, deadline - Date.now()); const m String(Math.floor(left / 60000)).padStart(2, 0); const s String(Math.floor(left % 60000 / 1000)).padStart(2, 0); timerEl.textContent ${m}:${s}; timerEl.classList.toggle(is-warning, left 60000); if (left 0) { clearInterval(timerId); doSubmit(true); return; } } const timerId setInterval(tick, 250);250 毫秒刷新一次界面上秒数跳动看起来是连续的不会出现跳过一秒的视觉抖动。切后台再回来因为每次都是用时间戳算误差立刻被吸收。最后一分钟给倒计时加上红色闪烁提醒这个细节在实际使用中很有用——我就见过有人在最后十秒还在纠结然后被迫自动交卷。5.2 题目和选项乱序以及乱序后的判分陷阱同一套题连续刷两遍第二遍基本靠记忆。把选项顺序打乱能有效缓解这个问题实现也很简单function shuffle(arr) { const a arr.slice(); for (let i a.length - 1; i 0; i--) { const j Math.floor(Math.random() * (i 1)); [a[i], a[j]] [a[j], a[i]]; } return a; }但这里有个必须提醒的陷阱乱序的只是选项的显示顺序判定依据仍然是每个选项的 key。如果你的判分逻辑不小心改成了按索引比对比如判断第一个选项是否是正确答案那么一旦乱序判分就会全盘错乱——答对的显示错了答错的显示对了而且你很难第一眼看出问题在哪。所以我在渲染时始终把value${opt.key}写死为原始 key判分时也永远比对 key。展示顺序和逻辑标识彻底解耦这是这类功能不出错的关键。题目顺序乱序要谨慎些。如果题库本身有难度递进的设计比如前五题是基础概念、后五题是综合应用那打乱之后学习曲线就断了。我在项目里默认只乱序选项题目乱序做成一个开关。5.3 localStorage 断点续答这个功能解决的是真实痛点答到第十五题手机来条消息切出去回来浏览器把页面回收了前面的答案全没了。用localStorage存一份作答快照就够const STORAGE_KEY quiz-progress-v1; function saveProgress() { try { localStorage.setItem(STORAGE_KEY, JSON.stringify({ version: QUESTIONS_VERSION, answers: collectAnswers(formEl), deadline, savedAt: Date.now() })); } catch (e) { console.warn(本地存储不可用, e); } }几个细节要处理。第一包一层try/catch——无痕模式下localStorage会直接抛异常不处理的话整个页面脚本崩掉。第二存进去的数据带version恢复时和当前题库版本对不上就丢弃避免旧作答配上新题目的错位。第三设置有效期超过两小时的记录直接无视不然用户三个月后打开页面发现还留着上次的答案反而困惑。恢复逻辑放在渲染之后、事件绑定之前读数据遍历答案对象找到对应的input设置checked true然后刷新一次进度计数就行。5.4 一键返回顶部与移动端细节卷子长了之后交卷按钮在页面底部用户答完最后一题想交卷得往下滚或者干脆滚回顶部看倒计时。加个返回顶部的小圆钮成本几行代码window.scrollTo({ top: 0, behavior: smooth }); // 滚动超过一屏才显示按钮 new IntersectionObserver( ([entry]) btn.classList.toggle(is-visible, !entry.isIntersecting), { threshold: 0 } ).observe(document.querySelector(.quiz__head));用IntersectionObserver监听顶部那个标题块是否离开视口比监听scroll事件再计算scrollTop性能好得多不会在滚动时频繁触发计算。移动端还有两个细节值得处理。一是所有可点元素的可点区域不低于 44×44 像素这基本是行业共识选项行加了内边距之后轻松达标。二是禁用双击缩放带来的干扰用touch-action: manipulation能去掉部分浏览器上点击的延迟感让选中反馈更跟手。如果题目是请给下面这项打个分这种场景用下拉选择框select会更省空间但要注意它的样式定制能力有限在部分移动端浏览器上会以系统原生控件弹出跟页面的视觉风格对不上。我的经验是选项文本短、数量少于六个用单选按钮选项文本长或者数量多才考虑下拉并且要接受它样式上不那么听话。6. 常见问题与排查实录功能都实现对之后真正的磨人环节才开始。下面这几个问题我几乎每次做类似页面都会遇到至少一个。6.1 中文乱码、样式不生效、按钮点不动先列三个最高频的。中文乱码——八成的锅在meta charset上要么漏写要么位置太靠后超出文档前 1024 字节要么文件本身被编辑器存成了 GBK 编码。判断方法很直接打开开发者工具看 Network 面板的响应头或者直接看文件保存格式。样式完全不生效——按这个顺序排查路径对不对hrefstyle.css还是根目录下的./css/style.css文件名大小写对不对本地文件系统不区分大小写但部署到 Linux 服务器就区分了Style.css和style.css是两个文件控制台有没有 404。按钮点不动——最常见的原因是元素被别的元素盖住了通常是某个绝对定位的装饰层或者遮罩没有设置pointer-events: none。其次是 JS 报错导致监听器根本没绑上。打开控制台看有没有红色报错这一步能解决一半以上的点不动问题。还有一个隐蔽的给label包了input之后又给label绑了click事件去手动切换checked结果浏览器默认行为和你的代码各切一次看起来就像点了没反应。记住label包input已经有免费的点击联动别重复造轮子。6.2 问题速查表现象最可能的原因处理方式页面中文显示为乱码charset 缺失或位置靠后或文件编码不是 UTF-8meta charsetUTF-8紧跟head编辑器另存为 UTF-8盒模型宽度对不上漏写 DOCTYPE触发怪异模式第一行补上!DOCTYPE html手机上字太小缺少 viewport 元信息补widthdevice-width, initial-scale1.0双击打开页面空白fetch读取本地 JSON 被跨源策略拦截起本地静态服务或把题库内联成 JS 变量选项文本显示不全内容含、被当成标签解析渲染前统一做 HTML 转义多选题乱序后判分错乱判分按显示索引而不是选项 key判分永远比对 key展示顺序与逻辑标识解耦切后台后倒计时变慢setInterval累减被浏览器节流改用截止时间戳计算剩余时间无痕模式下脚本崩溃localStorage写入抛异常存储操作全部包try/catch交卷后还能改答案未禁用表单控件提交后遍历input设disabled6.3 我踩过的三个坑第一个坑是空格和换行被算进答案。有次从文档里复制题干和选项尾随了几个全角空格题目在页面上看着一模一样但字符串比对永远不相等判分全错。后来我在数据清洗阶段统一做了trim()并且在选项文本首尾加了不可见标记做过对比才定位到问题。从外部文档往题库里粘贴内容时这个问题出现的概率非常高。第二个坑是事件绑定时机。一开始我把事件绑定的代码写在渲染函数调用之前结果form元素还是空的委托监听虽然绑上了没问题但另一段直接querySelector取某个选项的代码拿到了null抛异常之后后面的脚本全停了。教训是所有依赖 DOM 结构的操作要么放在渲染之后要么放进DOMContentLoaded回调里。第三个坑是移动端横竖屏切换后布局错乱。原因是我用 JS 读取了初始视口高度算容器高度旋转屏幕后没有重算。后来把这类尺寸交给 CSS 处理用min-height: 100vh加dvh单位彻底不碰 JS 计算问题自然消失。凡是能用 CSS 表达的布局都别用 JS 去算这算是我做前端这些年最省心的一条原则。题库的维护也是个体力活。二十道题的时候手动写 JSON 完全没问题超过五十道就该考虑写个简单的录入脚本了读 CSV 转 JSON或者做个表单页面自己生成。我现在的习惯是把题目先在一个表格里维护好导出一份 CSV然后用一段十几行的转换脚本生成 JSON避免手写的时候漏逗号、漏引号——这种语法错误在编辑器里看着是红色波浪线但如果编辑器没开语法检查浏览器给报的错会含糊得让人抓狂。如果后面还要继续扩展我打算加两个东西一是成绩导出把作答结果拼成一段文本配一个复制按钮方便发到群里二是错题重练把判错的题筛出来重新组一份小卷子。这两个功能都不复杂本质上是在现有的数据结构上再套一层筛选逻辑。真做起来最花时间的往往不是代码而是想清楚交互上要不要给一个重练错题的引导页以及答完之后怎么回到完整卷子——这类小决定堆积起来才是一个页面好不好用的分水岭。