企业官网建设流程全解析

先说个场景：期末要出三套平行卷，老师手上有八百道题，但翻半天找不到合适的题，好不容易凑满一张卷子，难度又不均衡。这就是我当初做数学试题库组卷系统的直接动机——把题存起来，让机器按规则抽，老师只负责审和调。

这个系统说白了就是一套前后端分离的全栈项目：后端用 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 命令行里运行 npm，cmd 调用的不是 npm.ps1 而是 npm.cmd，所以 cmd 环境下不会触发这个限制。不过治标不治本，建议还是把执行策略改掉，毕竟后面很多工具都会用到 PowerShell 脚本。

2.3 Vue 项目初始化与目录约定

Nodejs 装好后，接下来初始化 Vue 前端项目。现在新项目我更推荐用 Vite 作为构建工具，启动速度快，热更新也快。可以直接运行 npm create vite 来创建项目，交互式选择 Vue3 模板。相比原来的 vue-cli，Vite 对现代浏览器支持更好，配置也更轻量。

也可以直接跑 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 即可。

常用接口我直接列成一张表：

关键代码骨架可以直接参考下面的写法：

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 环境类问题速查

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 这套组合做组卷系统，最大的价值是开发效率高，你能把精力集中在选题算法、数据设计和用户体验上，而不是纠结编译环境、依赖冲突这些次要事情。

后续如果还有时间，这个系统还可以接着扩展错题本、学生学情分析、难度曲线可视化这些模块。前期把题库和组卷的地基打稳，再往上加功能就顺理成章。希望这篇实操记录能帮正在做类似项目的你少走几步弯路。