去年帮朋友搭一个内部培训系统，库及他开口就要“题库功能”。答案我问具体点，库及他说：能刷题、答案能看答案、库及能记错题就行。答案结果真动手才发现，库及光“题库”两个字底下藏着一堆坑。答案

最直觉的库及做法是把题目和答案塞进一张表：id、question、答案answer。库及跑两天就崩了。答案单选题四个选项怎么存？库及多选题的答案顺序要不要固定？判断题的“对/错”和填空题的字符串完全是两种东西。更别说同一道题出现在不同科目、答案不同难度层级里，库及还得能复用。

我后来改成三张表。一张 questions 存题干和题型，一张 options 存选项（选择题才用），一张 answers 存标准答案和解析。题目和答案之间用 question_id 关联，一对多。这样一道多选题的多个正确选项就是 answers 表里的多行记录，判断题的答案就是一行“true”。简单，但够用。

真正让我头疼的是答案的展示逻辑。用户刷题时，点“查看答案”之前，前端不能拿到正确答案。早期版本我图省事，接口直接把 answer 字段返回了，前端用 CSS 藏起来。抓包一看全露馅。后来改成两个接口：/question/:id 只返回题干和选项，/answer/:id 才返回答案和解析。多一次请求，但安全。

错题本功能也有讲究。用户答错一次就记下来，下次重刷时优先出现——这个逻辑听起来简单，实现时得考虑“连续答对两次后移出错题本”。不然错题本越滚越大，用户直接放弃。我见过一个题库产品，错题本只增不减，三个月后用户打开就是两千道错题，当场卸载。

还有个小细节：题干里的代码块和数学公式。纯文本存储没问题，但前端渲染要区分。我一开始用 Markdown 存题干，结果用户输入“<”符号直接被解析成 HTML 标签。后来统一转义，渲染时再还原。数学公式用 KaTeX，代码块用 highlight.js，各管各的。

数据库索引也别偷懒。questions 表的 subject_id 和 difficulty 字段一定要加索引。我测试时塞了五万道题，没索引的情况下按科目筛选要等三秒多。加完索引降到几十毫秒。五万道题不算多，但用户体验的差距是数量级的。

最后说答案的“唯一性”问题。有些题库允许一道题有多个可接受答案，比如填空题“中国的首都”填“北京”或“北京市”都算对。实现时在 answers 表里加一个 is_primary 字段标记主答案，其余作为可接受变体。判分时遍历所有变体，命中任意一个就算对。这个设计后来被朋友夸了很久，其实就多了一个布尔字段。

搭题库不难，难的是把“答案”这件事想清楚。答案不是一串静态文本，它和题型、判分逻辑、展示时机、错题策略全绑在一起。想清楚这些再动手，能省掉后面一半的返工。