答题卡应使用文档模型存储为嵌套对象（如{"answers": {"q1": "B", "q42": "D"}}），而非稀疏矩阵或数组；题号加前缀避免解析异常，按需用$objectToArray+排序聚合导出，原子更新单题、索引建在具体题号字段（如answers.q8）或通配符索引，导出时再转稠密结构。
用 document 原生结构存答题卡，别硬转稀疏矩阵
MongoDB 不是 Redis，也不该当二维数组用。答题卡本质是「学生 ID + 题号 → 选项/得分」的映射关系，天然适合文档模型。强行把 { "q1": "A", "q50": "C" } 拆成稀疏矩阵再塞进数组（比如 [null, "A", null, ..., "C"]），只会让查询变慢、索引失效、更新易错。
常见错误现象：find({ "answers.49": "C" }) 查第 50 题答 C 的人，结果查不到——因为字段名是字符串 "q50"，不是数字索引；或者用了数组却漏掉空位，导致下标偏移。
- 直接用嵌套对象：每个题号作键，值为作答内容，如
{"answers": {"q1": "B", "q7": null, "q42": "D"}} - 题号统一加前缀（如
q），避免数字开头字段名在某些驱动里触发解析异常 - 需要按题号范围查询时，用
$regex或预存question_ids数组辅助，别依赖数组下标
稀疏键值对转成数组？只在导出/统计时做，不在库里存
真有场景要按顺序遍历所有题（比如生成 PDF 答题卡图），那转换逻辑应该放在应用层或聚合管道里，而不是存在库中。MongoDB 的 $objectToArray 能把 answers 对象转成键值对数组，再用 $sort 按题号排序，最后 $map 提取值——整个过程不改原始数据，也无需预设题数。
性能影响明显：如果提前存成数组，每次只改一题就得全量写入整个数组；而存对象，MongoDB 支持原子更新单个字段（$set: {"answers.q23": "A"}），IO 和锁开销小得多。
- 聚合示例：
{$project: {answerArray: {$map: {input: {$objectToArray: "$answers"}, as: "kv", in: "$$kv.v"}}}} - 注意
$objectToArray输出的 key 是字符串，排序前得用$toInt转题号，否则"q10"会排在"q2"前面 - 别在应用代码里手动拼数组——容易漏题、错位，尤其当题目动态增减时
要不要建索引？看查什么，不是所有字段都值得索
如果常查「哪些人第 8 题选了 C」，就在 answers.q8 上建单独索引；如果常查「某人所有作答」，就对 answers 整体建索引（但 MongoDB 对子文档字段索引更高效）。稀疏矩阵式数组索引基本没用——answers.7 这种路径无法覆盖动态题号。
容易踩的坑：createIndex({"answers": 1}) 看似通用，实际对 find({"answers.q12": "D"}) 效果很差，因为没命中具体路径；而 createIndex({"answers.q12": 1}) 又太死板，新增题型就得补索引。
- 高频查询的固定题号（如必答题）单独建字段索引
- 用通配符索引（
{"answers.$**": 1}）支持任意题号查询，但仅限 MongoDB 4.2+，且写入略慢 - 避免对整个
answers数组建多键索引，除非你真按数组位置查（你不会）
导出 CSV 或对接分析系统时，稀疏转稠密由程序控制
外部系统要的是固定列宽的表格（比如 100 列对应 100 道题），这个转换必须在导出环节做，不能反向污染数据库设计。Python 用 pandas.json_normalize、Node.js 用 Object.entries() + Array.from() 都能安全补空，还能处理题干变更、跳题等业务逻辑。
兼容性风险：不同版本 MongoDB 对大文档（>16MB）和超深嵌套有限制，而稀疏矩阵转稠密后可能瞬间膨胀——比如 1000 道题的答题卡，即使只答 5 题，转成长度 1000 的数组后体积翻 200 倍。
- 导出脚本里定义题号白名单，缺失题号填
null或默认值（如"unanswered"） - 用流式聚合 +
$limit分批导出，别一次性 load 全部文档到内存 - 如果题库本身存在版本号（如
v2.1），把版本字段存进文档，导出时按版本映射题号，比硬编码数组下标靠谱得多
