HTML5测验项目实战：从数据结构到交互逻辑的完整拆解

“HTML5 测验”这个项目名，乍一听像是大学网页设计课或者前端入门教程里的课后作业，但真上手做完一遍你会发现，它其实是一个能把你对 HTML5 的语义化标签、CSS3 的视觉处理、JavaScript 的 DOM 操作、数据存储这几块零散知识全部串起来的综合演练场。

尤其适合两类人：一是刚学完 HTML/CSS/JS 基础、想找个“不那么玩具”的小项目巩固一下的前端新手；二是需要交网页设计作业、但不想随便拼个静态页面交差的学生。这个项目用它就能说明白一个网页应用从“数据怎么组织”到“界面怎么渲染”再到“交互状态怎么管理”的完整链路，而且纯前端就能跑，不需要搭服务器、不需要装框架，一个浏览器加一个编辑器就能开工。这篇就按我实际做完的思路拆一遍：项目怎么做技术选型、题库和数据结构怎么设计、核心逻辑怎么拆、哪些地方最容易踩坑，以及后续能怎么扩展。

1. 项目整体设计与技术选型思路

1.1 这个“测验”项目真正要解决的核心问题

先把需求拆清楚。标题是“HTML5 测验”，那么表面上要做的是一个“能出题、能答题、能判分、能看结果”的网页；但往深一层想，任何一个测验应用背后都逃不开三个核心问题：

• 题目数据如何组织？包括题干、选项、正确答案、题型、难度，甚至知识点分类。
• 答题过程中的界面状态如何切换？从加载题目、用户选择、提交判定、下一题，到最后的成绩展示。
• 一次测验结束后，如何保留记录或回看错题？

如果只用静态 HTML 写一道选择题，那根本谈不上“应用”。只有把这三件事想清楚，写出来的代码才能从一个“页面”变成一个“功能”。这也是为什么我强烈建议别直接用框架（比如 Vue、React）来写这个项目——不是框架不好，而是当你还没吃透“状态变化驱动界面更新”这个底层逻辑时，用框架反而会把问题掩盖掉。用原生 JavaScript 手写一遍 DOM 更新，你才能真实感受到：页面上的每一处变化，背后都是你在操作节点、绑定事件、读写数据。

1.2 为什么选原生 HTML5 + JavaScript 而不是上框架

我在定技术方案的时候，给自己定了几个硬性约束：零依赖、零构建、双击 index.html 就能运行。原因很务实：

1. 项目定位是练习或作业，评审你的人（老师、面试官、看帖子的网友）最关心的是“你到底懂不懂原理”，而不是“你会不会装包”。
2. 一个测验应用的核心复杂度根本不在于 UI 框架，而在于数据结构和交互逻辑。用原生代码写完，别人 review 你的代码能一目了然；用框架包一层，反而显得虚。
3. 双击能跑意味着你可以随时拿给别人演示，不必解释“要先 npm install”。

这里还要提一下“HTML5 测验”里的 HTML5 到底指什么。很多人以为 HTML5 只是几个新标签，但在这种项目里，真正有价值的 HTML5 能力是 localStorage（本地存储）、语义化标签（header/main/section 这类结构标签）、Canvas（如果做成绩展示图表）、Form 表单增强（比如 input 的 type 属性、required 校验）还有 History API（如果要做页面状态管理）。这些不是花架子，是用得上且能体现你技术面的东西。

1.3 核心功能范围划定

为了防止项目越做越膨胀，我把第一版的功能边界划在下面几条，做完再迭代也不迟：

• 支持三种题型：单选题、多选题、判断题。
• 题目按顺序逐题展示，答完当前题自动进入下一题。
• 每题作答后立即反馈对错，并解析答案。
• 全部完成后展示总分、正确率和用时。
• 用 localStorage 保存最近 10 次测验的历史成绩，做一个简单的成绩趋势列表。
• 在 PC 和手机浏览器上都能正常使用（响应式适配）。

这套功能不追求花哨，但每个模块都能独立深挖，做完你对“一个动态网页应用是怎么跑起来的”就会有一个完整认知。

2. 核心细节拆解与数据结构设计

2.1 把题库拆出来管理：JSON 数据结构设计

我见过不少新手写测验项目，第一反应就是把题目直接用 <p> 标签写死在 HTML 里，然后给每道题写一套点击事件。这种做法的问题在于：题目一旦多到 10 道以上，HTML 就会变得臃肿到没法维护，而且改一个错别字都要翻半天页面。

靠谱的做法是先设计一个题目数据模型。我一般把每道题定义成一个对象，字段结构如下：

json复制{
  "id": 1,
  "type": "single",
  "question": "以下哪个标签用于在 HTML5 中定义文章内容？",
  "options": ["<article>", "<section>", "<div>", "<span>"],
  "answer": [0],
  "analysis": "<article> 标签用于包裹独立、完整的内容块；<section> 强调分段与归类；<div> 是无语义容器。"
}

各字段的含义我按实际使用经验说明一下：

• type：题型标识。我定义了三种取值：single 单选、multiple 多选、judge 判断。
• options：选项列表，统一用数组。判断题其实就是两个元素的选项数组，内容约定为“正确/错误”，这样渲染逻辑就完全统一了。
• answer：正确答案索引。这里我故意设计成数组而不是单个数字，原因是多选答案天然是一个集合，如果单选也用数组，判题逻辑就能统一写成“数组完全相等”的比较，不用为题型写分支。
• analysis：题目解析。答完题显示解析是提升项目完成度非常关键的一步，不然用户做错了也不知道为什么。

为了出题时方便，我还把整个题库放进一个 JS 文件而不是直接写在页面里，比如建一个 questions.js，里面定义一个全局变量：

javascript复制const QUESTION_BANK = [ /* 上面格式的题目对象 */ ];

然后在页面底部用 <script src="questions.js"></script> 引入。这样做的好处是：题库数据和页面渲染逻辑彻底分离，以后想从后端接口加载题库，只需要把 QUESTION_BANK 的赋值方式从“写死”改成“fetch 请求返回的数据”，其他代码几乎不用动。

2.2 题目的随机排列：Fisher-Yates 洗牌算法为什么值得写

测验题目如果每次都按同一个顺序出现，用户体验很差，第二次做基本就是背答案。所以我加了一个洗牌逻辑——但这地方有个新手容易犯的错：直接用 array.sort(() => Math.random() - 0.5) 来做乱序。

这个写法很常见，但不是真正的随机洗牌。sort 的参数函数应该返回稳定、可比较的排序结果，你用随机值去干扰它，排序结果会严重偏向原顺序附近的排列，分布不均匀。实际测试数据越多越明显。

更靠谱的做法是 Fisher-Yates 洗牌算法，核心思想是从后往前遍历，每次都把“当前位置的元素”和“它之前（含自身）的某个随机位置的元素”交换。代码很短：

javascript复制function shuffle(arr) {
  const result = arr.slice();
  for (let i = result.length - 1; i > 0; i--) {
    const j = Math.floor(Math.random() * (i + 1));
    [result[i], result[j]] = [result[j], result[i]];
  }
  return result;
}

这样洗出来的序列，任意排列出现的概率都是均等的。我在项目里对题目顺序做了一次 shuffle，对选项顺序也做了 shuffle——前者防止背题，后者防止“选 C”惯性。不过注意一点：选项洗牌之后，answer 里存的下标也必须跟着变，否则答案就对不上了。我的做法是先把选项数组和索引数组一起洗，或者干脆先把 answer 转换为选项文本，洗完后重新定位索引：

javascript复制function shuffleOptions(question) {
  const indices = question.options.map((_, i) => i);
  // 先洗索引数组
  for (let i = indices.length - 1; i > 0; i--) {
    const j = Math.floor(Math.random() * (i + 1));
    [indices[i], indices[j]] = [indices[j], indices[i]];
  }
  const oldOptions = question.options.slice();
  const newOptions = indices.map(idx => oldOptions[idx]);
  // 重新计算正确答案索引
  const newAnswer = question.answer.map(oldIdx => indices.indexOf(oldIdx));
  return { ...question, options: newOptions, answer: newAnswer };
}

2.3 HTML 语义化：别把测验页面做成一堆 div

既然是叫“HTML5 测验”，页面结构最好用上 HTML5 的语义化标签，别一上来就 <div id="root"> 包一切。我的页面骨架大概是这样的：

html复制<header>
  <h1>HTML5 能力测验</h1>
  <p id="progressText"></p>
</header>
<main>
  <section id="quizCard">
    <div id="questionArea"><!-- 题目和选项渲染到这里 --></div>
  </section>
  <aside id="resultPanel" hidden>
    <h2>测验结果</h2>
    <!-- 成绩统计区域 -->
  </aside>
</main>
<footer>
  <p>题目共 <span id="totalCount"></span> 道，祝你好运</p>
</footer>

这里的核心思路是：header 放全局标题和进度，main 里放两个并列区块——答题区和结果区。结果区平时 hidden，全部答完后显示。用语义化标签的好处不只是“显得专业”，更重要的是屏幕阅读器、搜索引擎能正确理解页面层级，这对无障碍访问很有意义，也是课程作业答辩时能拿出来说的加分点。

每道题的渲染结构，我用 article 标签来承载单题内容，fieldset 来分组选项，这样视觉和逻辑都清晰：

html复制<article class="question-card">
  <h3>第 3 题 / 共 10 题</h3>
  <p class="question-text">以下哪些标签属于 HTML5 新增？</p>
  <p class="question-type">题型：多选题</p>
  <fieldset>
    <label><input type="checkbox" name="q3" value="0"> canvas</label>
    <label><input type="checkbox" name="q3" value="1"> div</label>
    <label><input type="checkbox" name="q3" value="2"> video</label>
    <label><input type="checkbox" name="q3" value="3"> span</label>
  </fieldset>
  <button class="btn-submit">提交本题</button>
  <div class="result-feedback"></div>
  <div class="analysis-box" hidden></div>
</article>

2.4 答题状态的管理：用“状态机”思路避免逻辑混乱

页面应用最怕的就是状态乱了。用户明明已经答过第 3 题，结果浏览器刷新又回到第 1 题；或者多选题还没选完就点了下一题。这些问题根本原因就是状态没有被明确管理。

我的做法是定义几个全局状态变量，它们是整个应用的“唯一真相来源”：

javascript复制const state = {
  currentIndex: 0,          // 当前是第几题（索引）
  answers: [],              // 用户选择的答案索引数组，例如 [[0], [1,2], [1], ...]
  correctCount: 0,          // 累计答对数量
  startTime: null,          // 开始测验的时间戳
  endTime: null,            // 结束时间戳
  isFinished: false         // 是否已交卷
};

任何界面变化，都先改 state，再根据 state 调用渲染函数更新 DOM。而不是在事件回调里直接这里改一下样式、那里改一下文本。比如点击“下一题”按钮时，事件里只做两件事：

1. 收集当前答案并写入 state.answers；
2. 调用 goToNextQuestion() 来更新 state.currentIndex，然后重新渲染整道题。

这样即使以后要加“回到上一题修改答案”的功能，也只需要把 state.currentIndex 减回去再重新渲染一次，不会碰到“当前界面是第 3 题但 state 里记的是第 2 题”这种不同步的坑。

3. 实操过程与核心环节实现

3.1 页面骨架搭建与 CSS3 主题设计

代码结构上的目录划分我建议这样安排，清晰且易于维护：

code复制html5-quiz/
├── index.html
├── css/
│   └── style.css
├── js/
│   ├── questions.js   # 题库数据
│   ├── quiz.js        # 核心逻辑
│   └── storage.js     # 本地历史记录模块

CSS 这块我用了 CSS3 的一些能力来提升观感，而不是堆砌图片。首先用 CSS 变量（也叫自定义属性）统一管理主题色，换主题只改顶部几个值：

css复制:root {
  --primary-color: #2563eb;
  --success-color: #16a34a;
  --error-color: #dc2626;
  --text-color: #1f2937;
  --card-bg: #ffffff;
  --radius: 12px;
}

卡片式布局则是现代网页里最常见的视觉方案。我给答题区域包了一个白色圆角卡片，配合阴影制造悬浮感：

css复制.question-card {
  background: var(--card-bg);
  border-radius: var(--radius);
  box-shadow: 0 10px 25px rgba(0, 0, 0, 0.08);
  padding: 24px 28px;
  max-width: 720px;
  margin: 20px auto;
  transition: transform 0.3s ease;
}

如果想让页面更有“测验产品”的感觉，可以做一个顶部进度条：当前答到第几题，进度条就走了百分之几。实现思路是用一个填充色条放在容器里，宽度用百分比控制：

css复制.progress-track {
  height: 8px;
  background-color: #e5e7eb;
  border-radius: 999px;
  overflow: hidden;
}
.progress-bar {
  height: 100%;
  width: 0%;
  background: linear-gradient(90deg, var(--primary-color), #3b82f6);
  transition: width 0.4s ease;
}

进度条的宽度由 JS 动态设置：document.getElementById('progressBar').style.width = ((state.currentIndex + 1) / totalQuestions * 100) + '%'。这个动画很轻量，但不失为体验上的一个加分点。

3.2 答题主流程的 JavaScript 逻辑：渲染、收集、判定

这部分是整个项目的核心，我把它拆成三个函数对应三个环节。

渲染当前题目

renderQuestion() 的职责是根据 state.currentIndex 从题目数组里取出当前题，然后生成 HTML 插入到容器里。这里最关键的是生成选项的时候，要同时考虑输入框类型（radio 还是 checkbox）以及选项顺序。

javascript复制function renderQuestion() {
  const q = shuffledQuestions[state.currentIndex];
  const questionArea = document.getElementById('questionArea');
  const optionsHtml = q.options.map((opt, idx) => {
    // 判断题型决定是单选还是多选
    const type = q.type === 'multiple' ? 'checkbox' : 'radio';
    return `
      <label class="option-item">
        <input type="${type}" name="option" value="${idx}">
        <span>${escapeHtml(opt)}</span>
      </label>
    `;
  }).join('');
  
  questionArea.innerHTML = `
    <article class="question-card">
      <div class="question-meta">
        <span class="badge">${getTypeLabel(q.type)}</span>
        <span>第 ${state.currentIndex + 1} / ${totalQuestions} 题</span>
      </div>
      <h3>${escapeHtml(q.question)}</h3>
      <fieldset>${optionsHtml}</fieldset>
      <button id="submitAnswer">确认答案</button>
      <button id="nextQuestion" hidden>下一题</button>
      <div id="feedback"></div>
      <div id="analysis" hidden></div>
    </article>
  `;
}

注意几个细节：一是 escapeHtml() 转义函数一定要写，因为题干和选项里如果出现 <article> 这样的代码片段（我的题库里很多这种题），不转义就会被浏览器当成标签解析掉，页面直接错乱；二是“确认答案”按钮在渲染时可见，“下一题”按钮先隐藏，两者通过答题状态切换显隐。

收集用户答案

按钮点击事件里，第一步不是急着判对错，而是先把用户所有勾选的选项收集成一个索引数组。用 querySelectorAll 找到当前卡片里所有 input[name="option"]:checked，再取它们的 value：

javascript复制function collectUserAnswer() {
  const checkboxes = document.querySelectorAll('input[name="option"]:checked');
  return Array.from(checkboxes).map(cb => parseInt(cb.value, 10));
}

parseInt(cb.value, 10) 的第二个参数 10 一定别省——这是告诉 JS 按十进制解析，否则像“08”这种字符串可能在某些老环境下被按八进制处理（ES5 严格模式下字符串前缀 0 会直接报语法错误），是个隐形坑。

判定逻辑

收集到用户答案 userAnswer 后，和题目的 answer 数组比较。因为两者都是数组，比较方式不能直接 ===，需要逐个元素比对。我的做法是把两个数组排序后转成字符串再比较：

javascript复制function isAnswerCorrect(userAnswer, correctAnswer) {
  if (userAnswer.length !== correctAnswer.length) return false;
  const a = [...userAnswer].sort((x, y) => x - y).join(',');
  const b = [...correctAnswer].sort((x, y) => x - y).join(',');
  return a === b;
}

为什么要排序？因为用户选 [2,0] 和正确答案 [0,2] 是同一个意思，但如果不排序直接 join 比较就会判错。这个细节特别容易在多选题上翻车。

3.3 成绩展示与历史记录：localStorage 的正确用法

答完最后一题，应用进入结果页。这时需要把统计好的成绩展示出来，并且存到本地。我用 localStorage 来存历史成绩，key 设计成 'html5_quiz_history'，value 是 JSON 字符串化的数组：

javascript复制function saveHistory(result) {
  const historyKey = 'html5_quiz_history';
  let history = [];
  try {
    history = JSON.parse(localStorage.getItem(historyKey)) || [];
  } catch (e) {
    history = [];
  }
  history.unshift({
    time: Date.now(),
    score: result.score,
    total: result.total,
    accuracy: result.accuracy
  });
  // 只保留最近10条，避免 localStorage 膨胀
  if (history.length > 10) history.length = 10;
  localStorage.setItem(historyKey, JSON.stringify(history));
}

这里有几个容易被忽略的坑，我吃过亏，一并说说：

1. localStorage.getItem() 返回的是字符串 null（你没看错，不是 null 值，而是字符串 "null"？其实标准实现下返回 null 值），JSON.parse(null) 会返回 null，不会报错，但用 || [] 兜底更稳。
2. 读取历史记录时一定要包 try/catch。因为如果以前存过脏数据、或者用户在隐私模式下手动改过 localStorage，JSON.parse 可能直接抛错，导致整个脚本中断。
3. 存成绩最好带上时间戳 Date.now()，这样以后做“最近 7 天成绩走势”就有数据基础。

历史记录渲染成列表时，可以用 new Date(time).toLocaleString() 把时间戳转成可读时间，这个 API 在不同浏览器下输出格式有差异，但展示用途足够了。

3.4 增加一个亮点功能：canvas 绘制成绩环

纯数字展示成绩太干巴了，我加了一个 canvas 绘制的环形进度图，用于展示正确率。这也是在项目里体现 HTML5 Canvas 能力的机会。

实现思路是画两个同心圆弧：先画一个灰色的底环，再画一个从 12 点方向开始、按百分比绘制角度的彩色环。

javascript复制function drawRing(canvas, percent) {
  const ctx = canvas.getContext('2d');
  const w = canvas.width;
  const h = canvas.height;
  const cx = w / 2;
  const cy = h / 2;
  const radius = Math.min(cx, cy) - 8;

  ctx.clearRect(0, 0, w, h);

  // 底环
  ctx.beginPath();
  ctx.arc(cx, cy, radius, 0, Math.PI * 2);
  ctx.lineWidth = 12;
  ctx.strokeStyle = '#e5e7eb';
  ctx.stroke();

  // 成绩环，从12点钟方向开始，角度按正确率比例
  const startAngle = -Math.PI / 2;
  const endAngle = startAngle + Math.PI * 2 * percent;
  ctx.beginPath();
  ctx.arc(cx, cy, radius, startAngle, endAngle);
  ctx.lineWidth = 12;
  ctx.lineCap = 'round';
  ctx.strokeStyle = percent >= 0.6 ? '#16a34a' : '#dc2626';
  ctx.stroke();

  // 中心文字
  ctx.fillStyle = '#1f2937';
  ctx.font = 'bold 28px sans-serif';
  ctx.textAlign = 'center';
  ctx.textBaseline = 'middle';
  ctx.fillText(Math.round(percent * 100) + '%', cx, cy);
}

注意方向：canvas 的弧度坐标里，0 是三点钟方向，但环形图习惯从十二点开始，所以要 -Math.PI / 2 为起始角。这个不写注释的话，下个月你自己回来看很可能也看不懂，所以一定要记得加注释。

canvas 要根据计算结果自适应分辨率，不能只设 HTML 里的 width/height。如果你用 CSS 把 canvas 放大到两倍尺寸，图形会发虚。最稳妥的做法是实际渲染前重新设一下 canvas.width 和 canvas.height 等于它展示尺寸的两倍，再用 ctx.scale(2, 2) 绘制，这个属于高分屏适配的基础操作。

3.5 数据边界与安全提醒：题库写在浏览器里意味着什么

写到这里有必要泼一盆冷水。这个项目的所有数据，包括题目和正确答案，本质上都暴露在用户浏览器里——你按 F12 打开 DevTools 的 Sources 面板，就能看到 questions.js 里的完整答案。这决定了它只适合“自我测验”或“低风险教育场景”，不适合做任何有激励或竞赛性质的正式考试。

我见过有人拿着类似项目想去替代正式的答题活动，结果用户直接查看网页源码把正确答案全抄了。这不是 bug，是纯前端方案的天生边界。如果想做真实考试系统，至少要引入后端接口，把题目下发和答案判定放在服务器端，前端只负责展示。这一点在做项目决策时就要想清楚。

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

4.1 我踩过的典型 Bug 与排查过程

第一个印象深刻的 Bug 是“选项点击没反应”。现象是：第一题能正常选，点“下一题”后，第二题的选项怎么点都没反应。打开控制台一看，报错 Cannot read property 'addEventListener' of null。

问题出在我最初把点击事件直接绑定在“下一题”按钮上，但 renderQuestion() 用 innerHTML 重建了 DOM，新按钮在绑定事件之后才生成，所以自然绑不上。这就是典型的“动态元素事件失效”问题。解决方案有两种：

• 在 renderQuestion() 渲染完 HTML 后，重新获取按钮元素再绑定事件。
• 更好的方案：用事件委托，把点击事件绑定在不变的父容器上，通过 event.target.closest() 判断点击的是不是目标按钮。

我选的是第二种。事件委托的好处是以后不管页面里怎么增删按钮，不需要重新绑定：

javascript复制document.getElementById('quizCard').addEventListener('click', (e) => {
  if (e.target.closest('#submitAnswer')) {
    handleSubmit();
  } else if (e.target.closest('#nextQuestion')) {
    handleNext();
  }
});

第二个典型问题是多选题的“选中态视觉滞后”。用户点完选项后，我看到 label 背景没有立刻变化，只有等焦点离开才有样式更新。这是因为我用的是 :focus 伪类来做选中样式，而不是 input:checked 的兄弟选择器。排查时打开 Elements 面板，发现 input 的 checked 状态已经变了，只是样式没跟上。用下面这组 CSS 就能用 label 包裹实现“点击即变色”：

css复制.option-item {
  display: flex;
  align-items: center;
  padding: 10px 14px;
  border: 2px solid #e5e7eb;
  border-radius: 8px;
  cursor: pointer;
  transition: all 0.2s;
}
.option-item:hover {
  border-color: var(--primary-color);
}
.option-item input[type="radio"],
.option-item input[type="checkbox"] {
  margin-right: 10px;
}
.option-item:has(input:checked) {
  border-color: var(--primary-color);
  background-color: #eff6ff;
}

这里用了 :has() 选择器，现代浏览器（Chrome 105+、Firefox 121+、Safari 15.4+）都已经支持。如果担心老环境，可以退而求其次用 input:checked + span 给文字加个左侧小圆点标记，效果也不差。

第三个问题是“倒计时不准”。我给测验加了 5 分钟倒计时，用 setInterval(fn, 1000) 直接每秒减 1。跑了一会儿就发现实际结束时间比倒计时结束晚了几秒——原因很简单，setInterval 的计时精度受事件循环影响，浏览器标签页切到后台还会进一步降频。严格倒计时应该用时间戳来算剩余时间，每秒用 endTime - Date.now() 重算。代码很简单，但理念很重要：

javascript复制const endTime = Date.now() + 5 * 60 * 1000;
const timer = setInterval(() => {
  const remain = Math.max(0, Math.round((endTime - Date.now()) / 1000));
  renderTimer(remain);
  if (remain <= 0) {
    clearInterval(timer);
    submitQuiz();
  }
}, 200);

4.2 移动端适配的三点教训

第一个教训是题目标题字号别低于 16px。iOS 下如果网页输入框字号小于 16px，聚焦时 Safari 会自动放大页面，体验很差。所以 option-label 的 font-size 我设置在 16px 以上。

第二个教训是禁用按钮不一定都要 disabled 属性。题目没答完时如果禁用“确认答案”按钮，视觉上的“灰色按钮”容易让用户纳闷；更好的交互是点击提交时检查选项数量，为空就弹一个小抖动动画或提示文字。判断是否为空很便宜：

javascript复制const userAnswer = collectUserAnswer();
if (userAnswer.length === 0) {
  showToast('请先选择一个选项');
  return;
}

第三个教训是 viewport 一定要写对，不然手机上字号和布局都会被自动缩放干扰。标准写法是：

html复制<meta name="viewport" content="width=device-width, initial-scale=1.0, viewport-fit=cover">

viewport-fit=cover 主要针对 iPhone 的刘海屏，让网页内容能延伸到安全区之外，视觉上更满。

4.3 兼容性排查笔记：我遇到的三种“浏览器不听话”

不同浏览器对 HTML5 API 的支持程度有差异，虽然现代浏览器整体兼容已经很好，但面向课程演示和分享场景，经常会遇到别人用老环境打开的情况。我整理了三类典型问题：

第一类是 localStorage 在隐私模式下的表现。Safari 旧版隐私模式下 localStorage.setItem() 会直接抛 QuotaExceededError，如果不 catch，整个成绩保存功能就崩溃。后来我所有 localStorage 操作都包了 try/catch，并把存储抽象成一个单独的小模块 storage.js，后续统一替换成其他存储方案也方便。

第二类是 :has() 选择器的兼容。如果你的浏览器版本较旧，样式里的 :has 整行规则会被忽略，选项选中的高亮效果没了，但功能不受影响。排查起来费了我好一阵子，最后用 Can I Use 查了一下确认是兼容性问题，果断把核心选中样式改回 input:checked 相关方案，:has() 只留作“增强而不是必需”。

第三类是音频和视频相关 API。如果测验里加了倒计时结束提示音，HTMLAudioElement.play() 在移动端默认要求用户先有一次交互才能播放声音，否则会返回一个 rejected Promise。比如：

javascript复制function playEndSound() {
  const audio = new Audio('end.mp3');
  audio.play().catch(err => {
    // 移动端没经过用户手势时，play 会被拒绝，这里静默处理就好
  });
}

这类 reject 其实可以忽略，但如果没有 catch，控制台会报红色 Uncaught (in promise) 错误，看着很吓人，也会给人一种“代码有问题”的错觉。

5. 项目优化清单与功能扩展建议

5.1 这个项目的性能优化能做什么

项目规模不大，性能优化其实做不了太多，但有些习惯值得留一下。一个基础做法是：避免在循环里反复操作 DOM。我最初渲染选项时是每生成一个 label 就 appendChild 一次，10 道题、每道 4 个选项，就要做 40 次 DOM 操作。优化后的做法是先拼一个大的 HTML 字符串，最后一次 innerHTML 插入，渲染时间是肉眼可见地下降。

另外，如果题目数量很大（比如 100 题以上），逐题渲染和一次性把 100 道题全塞进 DOM 是两种策略。前者占内存小，但每次切换有轻微闪动；后者首屏渲染慢，但切换快。做测验应用推荐前者，因为状态简单、可扩展性强。这种小项目没必要上虚拟滚动这类重型优化，反而会让复杂度失控。

5.2 题库加载方式：JSON 文件还是 JS 文件

我在最初版本里把题库放在 JS 文件里，定义一个全局数组。后来发现一个更灵活的方案：把题库放到独立的 .json 文件里，页面启动后用 fetch 加载。不过要注意，在本地“双击 index.html”打开页面时，fetch 请求本地 json 文件会被浏览器拦截（file:// 协议下的跨域限制），所以这种方案需要起一个本地静态服务器，比如执行 python -m http.server 8000，或者用 VS Code 的 Live Server 插件。

考虑到“双击就能跑”这个初始目标，JS 文件反而成了更实用的选择。如果后续题目量大到要后台维护，再切换到 JSON + fetch 也不迟，上面的数据结构设计保证了这个切换成本很低。

5.3 面向可复用：抽象成“答题组件”的思路

如果想用这个项目做简历作品或继续封装，建议再往前一步：把整个测验逻辑从“当前页面”中解耦，改成接收配置项的可复用模块。比如定义一个 QuizApp 函数，接收 { container, questions, duration } 三个参数，内部自行渲染、计时、判分。这样同一个代码就能服务多个测试主题——HTML5 测验、CSS3 测验、JS 测验都能共用一套外壳，只需要换题库数据。

这个抽象思路本身比纯粹的代码技巧更重要。真正的项目里，业务需求会不停变，“能适应变化的设计”远胜过“能跑一次的实现”，这也是我从这个项目里得到的最实在的收获。

写在最后的个人体会

做“HTML5 测验”这个项目的过程中我最大的感受是：一个看起来简单的小应用，里面积累的边界处理远比想象中多。从答案数组的比较、动态 DOM 的事件绑定、本地存储的兼容性，到移动端的交互细节，每一处都能对应上一个具体场景下的坑。项目写完以后，我自己拿手机和电脑分别测了好几遍，发现桌面端明明很好的布局在窄屏上会挤压变形，于是又回头调整了卡片的内边距和字体大小。这种“自己用一遍才能发现问题”的体验，比任何理论都管用。

如果你也想拿这个项目练手，我的建议是不要急着找网上现成源码抄一遍就完事。自己把题库数据结构设计出来、把核心渲染逻辑手写一遍、再踩一踩上面提到的这些坑，收获会扎实得多。写完后，还可以试着顺手加一个“题目收藏”按钮，把用户收藏的题单独存到 localStorage 里，再做一个错题回顾视图——那又是另一个层面的折腾了。