Nodejs+Vue数学题库组卷系统全栈开发实战

先说个场景期末要出三套平行卷老师手上有八百道题但翻半天找不到合适的题好不容易凑满一张卷子难度又不均衡。这就是我当初做数学试题库组卷系统的直接动机——把题存起来让机器按规则抽老师只负责审和调。这个系统说白了就是一套前后端分离的全栈项目后端用 Nodejs 提供接口前端用 Vue 框架搭交互界面核心功能是管理数学题库、自动生成试卷、支持预览和打印。它很适合拿来练手全栈基本功也能真正落地给教务使用尤其适合课程设计、毕业设计或者学校内部工具这类场景。这篇文章我不打算只堆设计图和功能清单而是直接按实际开发这条线的顺序来写先讲需求拆解和技术选型再讲环境搭建和经典报错然后拆解题库与组卷算法最后是部署上线和踩坑实录。如果你正准备自己从零做一个类似的系统这篇文章可以直接当操作手册用。1. 项目全貌数学组卷系统到底要解决什么问题1.1 数学题的特殊性公式和图形是第一道坎很多人一听到“题库系统”第一反应就是增删改查做完才发现真正的难点全在数学题本身。数学题目跟普通文本题不一样题干里全是根号、分数、求和符号、上下标还有几何图形和函数图像。如果用纯文本往数据库里塞录进去的时候还好展示的时候基本就是一团乱麻。我最早在草稿版本里试过直接把 Word 里的内容复制到题目标题字段里结果前端表格里出现一堆乱码。后来才意识到数学题的存储和渲染必须走专门的方案。目前最成熟的套路是题目内容用 LaTeX 语法存前端渲染交给 KaTeX 或 MathJax。具体来说像 \frac{a}{b} 这样的源码在编辑器里录入存储时原样保存展示时由 JS 库渲染成真正的分式。图形题就更麻烦选择题里的几何图没法用文字表达我当时采用的做法是上传图片把文件放到服务器本地目录或对象存储里数据库里记录图片 URL前端用 img 标签加载。这个方案简单可靠但要注意上传尺寸限制和图片命名最好用时间戳加随机数生成文件名不然很容易覆盖。另外要注意题目解析和答案同样需要公式支持别只给题干加渲染。一套合格的数学试卷答案解析里往往也有大量推导过程这些内容同样应该按 LaTeX 存储。很多组卷系统做得糙题目能显示公式答案解析却全是纯文本最后老师还得自己补写解析体验差很多。1.2 技术选型为什么是 Nodejs 和 Vue 的组合选 Nodejs 和 Vue 框架是我在对比了几套方案之后做出的选择。这个组合最大的优势是“前后端同一门语言”。前端写 JavaScript后端 Nodejs 也是 JavaScript知识体系不用来回切换。对于需要快速出活的全栈项目来说这个节省的时间非常可观。后端这个位置也考虑过 Spring Boot 和 Flask。Spring Boot 功能确实全但对个人项目来说太重了光 Java 环境、Maven 依赖、配置类就能劝退一批人。Flask 轻量但生态偏科学计算做文件导出、PDF 生成这类功能时不如 Nodejs 生态顺滑。Nodejs 的 npm 仓库里有大量现成库从打包到跨域处理到文件上传基本上都是装依赖直接用的状态。前端用 Vue 框架的理由更简单组件化开发、响应式数据绑定、配套 UI 库齐全。Element Plus 那一套表格、表单、弹窗组件直接拉高开发效率后台管理类界面的典型需求都能快速覆盖。如果你用的是 Vue3配合 Vite 脚手架开发体验还会再上一个台阶。数据库我选了 MySQL。数学题目这类关系型数据有天然的结构化特征题型、难度、知识点这些字段可以建索引、做关联查询组卷时需要按多条件筛选MySQL 非常合适。如果换成 MongoDB存文档确实灵活但像“按知识点和难度随机抽题并保证不重复”这种逻辑关系型 SQL 表达起来更直接。1.3 系统整体架构与核心模块整个系统是标准的 B/S 架构浏览器访问 Vue 前端页面前端通过 HTTP 请求调用 Nodejs 后端接口后端操作 MySQL 数据库。模块上主要拆成四块第一块是用户与权限。教师登录后管理自己的题目和试卷管理员可以管理所有用户和知识点。这块可以做得简单登录接口 角色判断就行但密码必须加密存储别用明文。第二块是题库管理。包含题目增删改查、批量导入导出、知识点分类维护。这是整个系统的地基组卷之前必须先有足够的题目题目质量和数量直接决定组卷效果。第三块是组卷引擎。老师设置试卷标题、总分、题型数量、难度分布系统自动从题库里抽题生成试卷。这块是核心也是最后一个模块的核心难点后面单独展开聊。第四块是试卷管理。生成后的试卷可以保存、预览、打印甚至导出为 Word 或 PDF。数学试卷的排版要求比较高试卷预览页需要针对打印场景单独调样式。这四个模块按依赖关系有先后顺序题库在最底层试卷在最高层。我一开始想四线并行开发后来发现不行题库没做好后面的组卷根本没有数据可测最后老老实实按顺序推进。2. 开发环境搭建从 Nodejs 安装到项目跑起来2.1 Nodejs 安装与环境配置做这个项目第一步就是装 Nodejs。很多人栽在这一步不是装不上而是装完发现命令行里找不到 node 命令或者出现各种权限报错。这里我把自己在 Windows 和 Ubuntu 两套环境下的安装经验都记一下。Windows 下直接去官网下载 LTS 版本安装包。注意两点第一选 LTS长期维护版不要选 Current当前最新版。数学组卷这类项目对稳定性的要求高于对新特性的需求LTS 版本生命周期长周边库兼容性好。第二安装时务必勾选“Add to PATH”这样安装程序会自动把 Nodejs 的安装目录写进系统环境变量。安装路径尽量保持默认如果手动改路径别改成带中文或空格的目录否则后续一些工具可能出现奇怪的编码问题。安装完成后打开新的命令行窗口输入 node -v 和 npm -v 验证。如果提示“node 不是内部或外部命令”说明 PATH 没有配好需要手动去编辑系统环境变量把 Nodejs 的安装路径加进 Path。这个路径一般是 C:\Program Files\nodejs\ 这种格式。Ubuntu 下的安装方式不同直接用 apt 安装很方便但有个坑apt 源里的 Nodejs 版本往往偏旧可能导致 Vue3 脚手架跑不起来。更推荐的方式是先安装 nvm再用 nvm 安装指定版本的 Nodejs。大致流程是先装 nvm然后执行 nvm install 18再 nvm use 18。这样 Node 版本随时可以切换对后续维护很有好处。装完基础环境后我当时顺手把 npm 镜像切换到了国内源后续安装依赖的速度提升非常明显。如果你在网络下载依赖时频繁超时也可以在项目根目录建一个 .npmrc 文件配置镜像源地址。2.2 npm.ps1 无法加载文件的经典报错这个错误几乎每个 Windows 用户都会遇到报错原文大致是“npm : 无法加载文件 D:\Program Files\nodejs\npm.ps1因为在此系统上禁止运行脚本”。第一次见这个报错的人很容易慌以为是 Nodejs 装坏了其实问题出在 PowerShell 的执行策略上。原理是PowerShell 出于安全考虑默认禁止执行 .ps1 脚本文件。npm 在 Windows 上恰好是通过 npm.ps1 这个 PowerShell 脚本执行的于是被拦住了。解决办法很简单以管理员身份打开 PowerShell执行 Set-ExecutionPolicy RemoteSigned然后按提示输入 Y 确认。RemoteSigned 策略的意思是本地脚本可以运行从网上下载的脚本必须经过数字签名才能执行安全性和便利性平衡得比较好。设置完成后可以执行 Get-ExecutionPolicy 查看当前策略值确认已经变成 RemoteSigned。重新打开一个普通 PowerShell 窗口再运行 npm -v 就不会报错了。如果当时不想动系统的执行策略也可以用临时绕过的方式在 cmd 命令行里运行 npmcmd 调用的不是 npm.ps1 而是 npm.cmd所以 cmd 环境下不会触发这个限制。不过治标不治本建议还是把执行策略改掉毕竟后面很多工具都会用到 PowerShell 脚本。2.3 Vue 项目初始化与目录约定Nodejs 装好后接下来初始化 Vue 前端项目。现在新项目我更推荐用 Vite 作为构建工具启动速度快热更新也快。可以直接运行 npm create vite 来创建项目交互式选择 Vue3 模板。相比原来的 vue-cliVite 对现代浏览器支持更好配置也更轻量。也可以直接跑 npm create vue这是 Vue 官方推荐的命令行工具会询问是否需要 Router、Pinia、TypeScript 等。我的建议是Router 选上前后端页面跳转需要Pinia 选上状态管理在登录信息和用户角色上会用到TypeScript 看个人熟悉程度如果不太熟就用 JavaScript别为了技术而技术。项目生成后的目录结构通常包括 src 下的 router、views、components、api、stores 这几个核心目录。我的约定是router 放路由配置views 放页面级组件components 放复用的业务组件api 统一封装所有后端接口请求stores 放全局状态。尤其是 api 目录把请求集中管理后面后端接口一改只需要在 api 目录里改对应函数不用满项目去找调用点。开发组卷系统时views 下面我习惯拆成 LoginView、QuestionListView、QuestionEditView、PaperGenerateView、PaperPreviewView 这几个页面级目录。每个页面只负责容器逻辑具体列表、表单、预览都下沉到 components这样团队成员或者自己半年后再回来维护代码结构一眼能看懂。2.4 前后端联调与跨域处理前端开发服务器默认跑在 5173 端口后端 Nodejs 服务跑在 3000 端口浏览器直接访问就会产生跨域问题。解决方式有两种后端开 CORS 或者前端代理。更推荐前端的代理方式。Vite 项目在 vite.config.js 里配置 server.proxy把以 /api 开头的请求全部转发到 http://localhost:3000。这样前端代码里所有请求都写相对路径代码更干净后端也不用暴露 CORS 头。代理配置好以后前端和后端都启动前后端联调从这一步就正式开始了。后端的 Nodejs 接口也可以顺便加上 CORS 中间件但要注意如果前端已经有代理后端就不要再开全局 CORS不然有些场景会出现“预检请求”被拦截的奇怪现象。这是我踩过的坑当时两道防线一块加结果前端请求报错排查了半天才发现是重复配置导致的问题。3. 核心功能拆解题库、组卷算法与试卷输出3.1 数据库设计与题目模型数据库设计是整个系统最需要提前想清楚的部分。数学题库的字段跟普通内容管理不一样公式、答案、解析都需要留足空间并且要为后续的多条件筛选建好索引。我最终设计的核心表结构大致是users 表存用户信息knowledge_points 表存知识点字段包括名称、父级ID、排序这样可以形成树状结构questions 表是题目主表字段包含题干、题型、难度、答案、解析、知识点ID、创建人、创建时间papers 表存试卷元信息paper_questions 表存试卷题目关联关系。这里重点解释一下 paper_questions 表。为什么不能直接在 papers 表里存一个题目ID数组因为组卷成功后试卷和题目是多对多关系同一道题可以出现在多套试卷里一张试卷也需要记录每道题的分值和在卷面上的顺序。单独建一张关联表才能把“第几题”、“多少分”、“题型序号”这些信息完整存下来。difficulty 字段我用的是 1 到 5 的整数1 最简单5 最难。也有人用 0.1 到 1.0 的浮点数各有各的好处整数在组卷算法里好计算浮点数更精细。我的建议是先用整数跑通整个流程再说别一开始就把维度搞太复杂。3.2 题目导入与公式处理手动录入是基础方式在题目表单里设置题干、选项、答案、解析、难度的输入框。数学公式的录入需要专门的公式编辑器可以在前端集成一个开源的 LaTeX 编辑器组件老师输入公式源码下方实时预览渲染效果。对不熟悉 LaTeX 的老师可以提供一个简单的按钮插入常用语法模板降低使用门槛。批量导入则是题库数据积累的重要途径。最实用的做法是提供 Excel 模板老师按模板填好题目后导入。当时我做的模板包含题号、题干、选项A到D、答案、解析、题型、难度、知识点名称这几列。导入后端时逐行解析校验题型编码是否合法、难度值是否在范围内、必填字段是否为空然后把知识点名称转换成知识点ID。这里有个实操经验模板里“知识点”这一列最好让用户填文字名称不要填 ID。因为老师根本不知道数据库里每个知识点的 ID 是多少填写自然名称程序导入时按名称去查找对应的 ID查不到就提示哪一行错误。虽然程序处理麻烦了一点但对使用者友好很多。公式的批量导入要特别谨慎。Excel 里如果题干用的是 Office 自带的公式编辑器复制出来的内容往往带大量 OLE 对象或者私有 XML 标签直接入库后会污染展示。我的建议是批量导入的场景只支持纯文本加 LaTeX 的题干输入方式复杂的图形题和带特殊公式的题目可以单独通过表单录入。这样可以在系统易用性和数据规范性之间找到平衡。3.3 自动组卷的核心思路自动组卷是这个系统的灵魂。老师进入组卷页面后选择要覆盖的知识点、设定选择题和填空题数量、设定每题分数和难度分布系统根据这些条件自动生成一套试卷。组卷的核心流程我拆成了四步。第一步按条件查询候选题目。根据老师选择的知识点、题型和难度区间从题库中查出所有符合条件的题目。这一步用 SQL 完成关键是条件组合要灵活知识点可以是多个难度可以是一个区间。第二步从候选题中随机抽取。这里用最简单的随机抽取即可但必须保证不重复。我当时的做法是把候选题的ID全部存进一个数组每次从数组中随机取一个下标取出后从数组里移除该元素这样天然避免重复。第三步检查分数总和。每道题都有一个分值抽完题目后统计总分是否等于目标总分。如果不足继续抽如果超了放弃这组重新开始。对于 100 分满分、固定题型数量的场景这个循环通常执行不了几轮就能找到解。第四步检查难度分布。把已选题目的难度乘分值加权求和得出整卷的平均难度。如果最终难度落在目标区间内就收工否则重新抽。这里要注意重试次数上限我建议设为 50 次超过上限就提示老师“题目数量不足或条件过于严格”把具体缺少哪个知识点或哪种难度的题目数量统计出来方便老师补充题库。这个算法在题目数量充足的情况下效率很稳定。如果题目数量紧张可能会出现重试多次仍然失败的情况此时可以把“知识点覆盖”从硬性条件降为软性偏好优先选择未覆盖的知识点但不必强制每一轮都满足。3.4 难度系数与知识点覆盖的量化为什么难度分布是组卷系统里最容易出问题的点因为难度是一个主观指标。同样是“中等难度”不同老师理解和标注的题目可能完全不同。我后来采用的办法是双维度约束录入题目时标注静态难度组卷时基于静态难度计算整卷平均难度同时允许老师手动调整个别题目的实际分值权重。难度系数的量化要尽量跟学生的实际得分对得上。我参考了一些常见题库的做法把难度系数定义为“本题得分率”也就是难度系数越高题目越简单。但在组卷面板上老师习惯说“容易题、中档题、难题”所以界面展示时我用百分比配置容易 30%、中等 50%、难题 20%后端再根据题目难度静态值计算需要抽取的数量。知识点覆盖度的逻辑相对直接。抽题时维护一个已覆盖知识点集合每次抽取时优先从尚未覆盖的知识点里取题直到所有选中的知识点都至少覆盖一道题再放开条件随机抽取。这样能够避免组出的试卷在知识点上严重失衡。量化核心是计算温度系数。我自己定义了一个简单的覆盖策略先用每个知识点的题目数量占总考点题目数量的比例估算抽取配额再在抽题过程中动态修正。举例来说如果选择“函数”和“几何”两个知识点题库里函数题有 80 道、几何题有 20 道组卷时并不是按 8:2 抽而是尽量按老师在界面上设定的每类知识点数量来抽不够再跨知识点补充。4. 实操记录接口、前端页面和组卷实现要点4.1 后端接口设计示例后端接口按 RESTful 风格设计统一的响应格式为 { code, data, message }。code 为 0 表示成功非 0 表示业务错误。这样前端在封装 axios 拦截器时只需要统一处理 code 即可。常用接口我直接列成一张表功能方法路径说明用户登录POST/api/auth/login传入账号密码返回JWT令牌获取题目分页GET/api/questions支持知识点、题型、难度、关键词筛选新增题目POST/api/questions组织数据写入题目表更新题目PUT/api/questions/:id修改题目信息删除题目DELETE/api/questions/:id可同时清理关联表数据知识点列表GET/api/knowledge-points树形结构返回自动组卷POST/api/papers/generate接收组卷参数返回生成的试卷试卷列表GET/api/papers分页返回已保存试卷试卷详情GET/api/papers/:id返回题目明细关键代码骨架可以直接参考下面的写法router.post(/papers/generate, authMiddleware, async (req, res) { const { title, totalScore, sections } req.body; // sections 示例: [{ type: choice, count: 10, scorePerQuestion: 3, difficulty: [1,2,3] }] const paperId await generatePaperService(title, totalScore, sections); res.json({ code: 0, data: { paperId } }); });组卷服务层是核心我单独建了一个 service 文件不跟路由层混在一起。这样接口逻辑清晰后面加缓存或事务也方便。4.2 前端核心页面前端部分最耗精力的是题库管理页和组卷页。题库管理页的整体结构是顶部筛选区中间表格区右侧操作列。筛选区包含知识点下拉树、题型选择器、难度区间和关键词搜索框。表格展示题号、题干预览、题型、难度、知识点、操作。题干预览这里要注意表格单元格里直接渲染整个公式会导致单元格高度参差不齐我的做法是截取题干前 60 个字符作为纯文本摘要完整的 LaTeX 渲染放到弹窗或详情页里。组卷页分为左右两栏。左侧是参数配置表单包括试卷标题、总分、各题型数量、分值、难度分布、知识点的多选树。右侧实时显示当前已配置题目的总数和总分统计。这个统计是交互式的老师加上一道选择题后右侧立刻更新总题数和当前总分避免配置完才发现总分凑不够。试卷预览页使用 MathJax 渲染公式。在 Vue 生命周期里等题目数据加载完成后调用 MathJax 的重新渲染方法才能保证公式正确显示。页面设计上要模拟真实的试卷版面标题居中、密封线、题号和题目内容紧凑排列。打印时通过一个单独的 print.css 调整纸张大小和页边距保证浏览器打印效果接近纸质试卷。4.3 性能优化与数据一致性题库列表页最容易出现性能问题。不重视分页的话一旦题库有几千道题页面加载会变得非常慢。我当时的做法是后端接口强制分页前端表格用页码切换不允许一次加载全量数据。MySQL 里给 questions 表的 difficulty 字段和 knowledge_point_id 字段建索引大幅提升筛选效率。组卷接口本身也需要控制性能。自动组卷涉及多次数据库查询如果每一步都重新查库接口响应时间可能超过三秒。优化方向是尽量在抽题前用一条 SQL 把符合条件的题目 ID 和分值全部查出来后续抽题逻辑全部在内存数组里完成。这样即使题库上万道题组卷接口也能在几百毫秒内完成。数据一致性主要靠数据库事务保证。新增试卷的同时还要写入多道题目的关联记录这一组操作必须放在同一个事务里否则可能出现试卷主记录保存成功但题目明细缺失的情况。Nodejs 里我使用 sequelize 或 mysql2 的 transaction 方法把 writespaper 和 writespaper_questions 的数据库操作包在一起任一步出错则整体回滚。4.4 部署上线与运行维护本地开发完成后部署上线是整个流程的收尾。前端项目执行 npm run build 生成 dist 静态目录将这个目录部署到 Nginx 的 html 目录。Nginx 配置反向代理把所有 /api 请求转发到 Nodejs 服务。server { listen 80; server_name your-domain.com; location / { root /var/www/dist; try_files $uri $uri/ /index.html; } location /api { proxy_pass http://127.0.0.1:3000; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } }Nodejs 服务需要长期运行我使用 PM2 做进程管理。PM2 可以设置开机自启、查看日志、监控 CPU 和内存。后端代码里数据库连接配置不要写死在源码中改用环境变量读取。启动命令类似 pm2 start src/app.js --name math-quiz-bank。5. 常见问题与踩坑记录5.1 环境类问题速查问题原因解决方案npm.ps1 无法加载PowerShell 执行策略限制管理员执行 Set-ExecutionPolicy RemoteSigned命令行找不到 nodePATH 未配置手动将 Nodejs 安装路径加入系统环境变量npm install 超时下载网络问题配置国内镜像源或设置代理端口被占用前后端端口冲突查看占用进程更换端口或释放占用npm run dev 后页面报错Node 版本与构建工具不匹配使用 nvm 切换至 LTS 版本5.2 组卷算法常见问题组卷算法调试起来比前端页面更隐蔽因为问题往往不是报错而是生成结果不符合预期。我遇到最多的几类问题放在这里供参考。明明题库里有符合条件的题目但组卷一直提示题目不足。多数原因不是真的没题而是筛选条件太严格。比如把难度范围限制得太窄、知识点约束过多导致候选集合在抽题过程中提前耗尽。排查方法很简单把组卷参数和实际查出的候选题目数打印到日志里一眼就能看出哪个条件是瓶颈。生成的试卷总分不等于设定值。常见原因是题目的分值计算用了浮点数多个浮点数相加产生精度误差。尤其是在每题 4.5 分、总数 22 题这类场景下累计值可能变成 99.999999 或 100.000001。解决办法是分数全部用整数分按“分”为单位存储和计算如果必须有小数分就把精度处理放在判定比较时统一用四舍五入。同一张试卷出现两道完全相同的题目。这个问题的根源多半是抽题时没有把重复数据从候选集合中彻底移除。我当时的做法是抽完题后立即将题目的唯一标识加入已抽集合下一次随机抽取前先检查是否命中已抽集合命中就跳过。这里尤其要注意数据库里如果存在完全相同的两行记录即使逻辑没 bug也会抽出“看起来重复”的题所以题库录入接口也要做重复校验。难度分布始终偏简单或者偏难。数学题的难度是主观标注的同一道题两个老师可能给出完全不同的难度值。这个问题靠算法无法根治只能从录入源头规范。我的做法是在题目录入表单里给难度字段设置默认值并把每个难度档位的描述附在表单下方让录入者参考描述而不是凭感觉打分。5.3 安全与权限提醒组卷系统里保存的是学校教学数据涉及老师和学生的信息哪怕只是一个内部工具也不要做成完全裸奔的状态。用户密码不能明文存储。我使用 bcrypt 库对密码做哈希加盐处理登录时用 bcrypt.compare 校验即使数据库泄露密码也不直接暴露。前端登录接口成功后后端签发 JWT 令牌前端把令牌存到 localStorage 或内存中请求时放在 Authorization 请求头。后端使用中间件统一校验令牌未携带或失效一律返回 401。接口的权限也要区分。普通教师只能管理自己创建的题目管理员才能管理全库数据和知识点。这个逻辑在后端接口里以中间件形式控制不能指望前端隐藏按钮来实现因为接口可以被绕过。还有个很常见的坑是 SQL 注入。如果接口里直接拼接请求参数到 SQL 查询一旦有人传入特殊字符可能造成严重问题。正确的做法是使用数据库驱动提供的参数化查询或者使用 ORM 的查询构造器我全程使用参数化。5.4 我的实操心得清单整个系统做下来有几个体会比较深。第一个是题目数据要先行。组卷算法再精巧没有足够的题库出来的效果都是废纸。当初我第一批只录了 100 多道题组卷勉强能跑但重复率高得吓人。后来扩充到 800 多道效果才基本正常。第二个是组卷算法要从简单到复杂。不要一开始就上遗传算法、模拟退火先用随机抽取加条件判断跑通主流程等性能和数据量上来了再去考虑更智能的优化策略。大部分学校场景题库几千道题随机算法配合次数上限已经足够。第三个是公式渲染体验要放在第一位。数学试卷系统好不好用公式显示是否流畅、是否准确几乎决定了老师会不会用这个系统。我最终选用了 MathJax 3虽然加载体积比 KaTeX 大但对复杂公式支持更好整体学习资料也更多。如果对性能特别敏感可以换成 KaTeX但要提前测试你的公式库是否存在兼容问题。第四个是给老师留“手动干预”的入口。自动组卷完成后一定要允许老师手动调整试卷内的题目可以换题、改分值、调整顺序。再好的算法也比不上老师对教学进度的直觉。我后来加了“一键重新生成”和“单独换掉某道题”这两个按钮用户满意度提升非常明显这比把长算法优化得更花里胡哨有用得多。最后补一句这个系统做完后我最大的感触是全栈项目的难点从来不在于某个技术用得多深而在于把零散的技术拼成一个能用的整体。Nodejs 和 Vue 这套组合做组卷系统最大的价值是开发效率高你能把精力集中在选题算法、数据设计和用户体验上而不是纠结编译环境、依赖冲突这些次要事情。后续如果还有时间这个系统还可以接着扩展错题本、学生学情分析、难度曲线可视化这些模块。前期把题库和组卷的地基打稳再往上加功能就顺理成章。希望这篇实操记录能帮正在做类似项目的你少走几步弯路。