开源问卷考试系统SurveyKing部署指南：问卷、考试、刷题与AI组卷全攻略

开源问卷考试系统 SurveyKing 安装部署与使用全指南：问卷收集、在线考试、题库刷题、AI 智能试卷一站搞定

这次我们来看一个开源问卷与在线考试系统：SurveyKing，中文社区更喜欢叫它"卷王"。从项目定位来看，它同时覆盖了问卷收集、在线考试、题库刷题、AI 智能组卷四个方向。也就是说，一个系统装下去，企业内部调研、学校考试、机构培训刷题、招聘笔试这些场景都可以接住。

先快速判断值不值得用。SurveyKing 是前后端完整开源的项目，技术栈属于 Spring Boot + Vue 这一派，部署完成后就是一个独立可用的平台，不依赖任何第三方问卷服务。问卷收集、在线考试、题库刷题三种模式是集成在一起的，不需要你在多个工具之间来回切换。比较特别的是它还具备 AI 智能组卷能力，可以从题库里自动抽取题目组合成一张新试卷，这对长期维护题库、频繁出卷的团队来说很实用。

部署门槛方面，这个项目不需要 GPU，不需要特别高的配置，常规 2 核 4G 的云服务器就能跑。启动方式支持源码编译、Docker 部署等多种形式，后续接入接口服务、做批量导入题目、对接第三方系统也比较方便。

这篇文章会带读者完成以下这些事情的梳理：

• SurveyKing 的核心能力、适用场景和边界；
• 本地部署前的环境准备，包括 JDK、MySQL、Node.js 等；
• 从源码编译到前后端部署的完整流程，以及 Docker 方式；
• 问卷创建、考试发布、题库刷题、AI 组卷等功能验证方法；
• 接口 API 与批量任务的接入思路；
• 资源占用观察方式和常见问题排查清单。

如果你正在调研开源的问卷调查和在线考试系统，或者准备在公司内网搭一套自己的考试平台，这篇可以直接收藏。

1. 核心能力速览

这套系统的核心卖点很直接：问卷、考试、刷题、AI 组卷四种能力在同一个项目里闭环。对比单独部署问卷系统加考试系统两套平台，SurveyKing 这种合并方案在运维和管理成本上更省。

2. 适用场景与使用边界

SurveyKing 的适用场景可以从"谁在用、用来干什么"两个维度来拆。

2.1 典型适用场景

• 企业内部调查：员工满意度、培训效果反馈、活动报名、会议日程登记、食堂满意度调查这类轻量问卷；
• 学校教学考试：随堂测验、单元检测、期中期末模拟考试、在线阅卷、成绩统计分析；
• 培训机构刷题：按科目建立题库，支持章节刷题、练习记录、错题收集、模拟考试；
• 企业招聘笔试：候选人信息收集加在线笔试，笔试结果归档，方便后续面试官查看；
• 行业研究问卷：公开问卷收集加数据统计导出，适合做市场调研和用户反馈收集。

这个系统最适合的团队画像是有一定技术能力、愿意自己维护一套基础设施、不想把业务数据放在第三方问卷平台上的团队。

2.2 使用边界与限制

需要说清楚边界。SurveyKing 不是专业考试监考平台，防作弊能力有限。如果考试场景要求视频监控、人脸识别、屏幕锁定、切屏告警这类强管控能力，开源基础版往往不支持，需要二次开发或者另选商业方案。

AI 智能试卷方面，从项目功能描述来看，AI 组卷的本质是从已有题库中按照规则自动抽取题目组成试卷，并不是凭空生成题目。题库的分类、难度标注、题量大小直接决定 AI 组卷的结果质量。机器自动组出的试卷，建议发布前人工复核一遍，确认没有题目重复、难度异常或答案错位。

数据合规方面也不能忽略。问卷和考试系统天然涉及个人数据，包括姓名、工号、联系方式、答题内容等。如果你要把系统部署到公网并面向外部用户收集数据，需要确认是否符合个人信息保护相关要求，问卷说明里要写清楚数据用途和范围。涉及企业内部敏感信息的问卷，建议只在内网使用。

2.3 不适合的场景

• 需要严格在线监考的高风险考试；
• 需要大量定制字段、复杂逻辑跳题的超复杂表单；
• 完全没有运维能力，希望零维护开箱即用的团队；
• 单次临时收集一次数据，没必要自建系统的场景。

如果你只是临时做一次投票，用现成问卷平台更省事。但如果是长期运营的考试、题库和反馈收集平台，自己部署开源系统是更经济的路径。

3. 环境准备与前置条件

从技术栈推断，SurveyKing 属于典型的 Java Web 前后端分离项目。安装之前，先把环境检查清楚，避免后面反复折腾。

3.1 硬件要求

如果只是个人学习测试，2 核 2G 的机器也能勉强跑，但并发一上来就容易卡。生产环境建议直接上 4G 内存。

3.2 软件要求

以源码编译部署为例，通常需要以下软件：

具体版本要求以项目仓库里的pom.xml、package.json和官方 README 为准。有些版本可能用到了更高版本的 JDK 特性，先看文档再安装，避免装了又卸。

3.3 安装 JDK 与 Maven

以 Linux 环境为例：

# 安装 OpenJDK 11（具体版本以项目要求为准） sudo apt update sudo apt install -y openjdk-11-jdk # 验证 Java 版本 java -version # 下载 Maven 并配置环境变量 wget https://archive.apache.org/dist/maven/maven-3/3.8.8/binaries/apache-maven-3.8.8-bin.tar.gz tar -zxvf apache-maven-3.8.8-bin.tar.gz sudo mv apache-maven-3.8.8 /opt/maven

在/etc/profile中追加：

export MAVEN_HOME=/opt/maven export PATH=$MAVEN_HOME/bin:$PATH

执行source /etc/profile后，运行mvn -version验证。

3.4 安装 MySQL

以 Ubuntu 为例：

sudo apt install -y mysql-server sudo systemctl start mysql sudo systemctl enable mysql

然后初始化数据库。大多数问卷系统需要先建一个业务库，通常指定utf8mb4字符集：

CREATE DATABASE IF NOT EXISTS surveyking DEFAULT CHARACTER SET utf8mb4 DEFAULT COLLATE utf8mb4_general_ci;

建议创建一个专用账号，不要直接用 root：

CREATE USER 'survey'@'%' IDENTIFIED BY 'YourStrongPassword'; GRANT ALL PRIVILEGES ON surveyking.* TO 'survey'@'%'; FLUSH PRIVILEGES;

注意：项目是否自动建表、是否需要手动导入初始化 SQL，要看项目文档。部分版本会在首次启动时自动执行数据库初始化脚本，部分版本需要手动执行init.sql。

4. 安装部署与启动方式

这一部分给出通用部署思路。先走源码编译路线，再补充 Docker 部署和常见启动问题。

4.1 拉取源码

# 以 Gitee 为例，仓库地址请搜索 SurveyKing 获取最新地址 git clone https://gitee.com/surveyking/surveyking.git cd surveyking

也可以直接下载 zip 包解压，省去 Git 操作。

4.2 后端配置与编译

找到后端的配置文件，一般在src/main/resources/application.yml或application.properties。需要重点修改数据库连接信息：

server: port: 8080 spring: datasource: url: jdbc:mysql://127.0.0.1:3306/surveyking?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai username: survey password: YourStrongPassword servlet: multipart: max-file-size: 50MB max-request-size: 100MB

然后执行后端打包：

mvn clean package -DskipTests

打包完成后，在target目录下会生成 jar 文件：

java -jar target/surveyking-*.jar --server.port=8080

如果项目提供了bin/start.sh或bin/start.bat脚本，优先使用脚本启动。Windows 环境直接执行 bat 文件即可，Linux 下给脚本加执行权限：

chmod +x bin/start.sh ./bin/start.sh

启动成功后，控制台会输出 Spring Boot 的启动日志，包括端口信息、数据库连接状态等。看到类似Started Application in xx seconds的日志，说明后端已经跑起来了。

4.3 前端构建与部署

如果是前后端分离结构，还需要构建前端工程：

cd surveyking-web npm install npm run build

构建完成后，dist目录下就是静态产物。有两种部署方式：

方式一：由 Nginx 托管静态文件并代理后端接口：

server { listen 80; server_name survey.example.com; location / { root /opt/surveyking/dist; index index.html; try_files $uri $uri/ /index.html; } location /api/ { proxy_pass http://127.0.0.1:8080; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } }

方式二：如果后端已配置静态资源映射，直接把dist内容放到后端静态目录下，访问后端端口即可。

浏览器访问：

http://127.0.0.1:8080

看到登录页面说明前后端通了。

4.4 Docker 部署方式

如果项目仓库提供docker-compose.yml，建议直接使用：

docker-compose up -d

Docker 部署的好处是环境隔离，避免本机 JDK、Node 版本冲突。如果仓库没有现成 compose 文件，可以自己准备两个容器：MySQL 容器和 SurveyKing 容器，通过 Docker 网络互联。后端容器的数据库地址要写 MySQL 容器的服务名或 IP，不能写127.0.0.1。

如果是本地学习测试，推荐这种组合：IDEA 直接运行后端、VS Code 运行前端、Docker 跑 MySQL。这样调试最方便，改代码不用反复打包。

5. 功能测试与效果验证

部署完成后，不要急着导入正式数据。先用最小数据集把主链路跑通。下面是一套通用验证流程。

5.1 登录与初始化验证

打开浏览器，进入系统首页，检查以下项目：

• 登录页是否正常渲染，图片、表单、验证码是否正常；
• 首次访问是否引导注册管理员账号；
• 进入管理后台后，用户管理、角色权限、系统设置菜单是否可用；
• 退出登录再重新登录，确认会话保持正常。

如果页面打不开，先看后端日志和后端进程状态：

netstat -tlnp | grep 8080 ps -ef | grep java

5.2 创建一份问卷并回收

问卷是最基础的功能。在后台找到"问卷"或"调查"模块，新建一份问卷：

• 问卷标题：员工满意度调查；
• 加入单选题：你对当前办公环境是否满意；
• 加入多选题：你希望公司增加哪些福利；
• 加入评分题：给本周培训活动打分；
• 设置问卷有效期；
• 发布问卷，复制问卷链接。

用一个无痕浏览器窗口打开问卷链接，模拟普通用户填写并提交。然后回到后台，查看问卷回收数量是否加一。如果回收数据没有变化，说明写入或统计环节有问题。

再测试一次重复提交限制。很多问卷系统内置了同一 IP 或同一设备限制，避免刷问卷。确认这个限制符合业务预期。

5.3 创建一场在线考试

打开"考试"模块，新建考试：

• 添加试卷；
• 从题库选题，或者手动添加几道测试题；
• 设置考试时长，比如 30 分钟；
• 设置及格分数，比如 60 分；
• 设置是否允许考生查看成绩和错题；
• 发布考试。

用考生账号进入考试，完成答题并交卷。验证：

• 是否自动计时，倒计时结束是否自动交卷；
• 提交后是否正常计算分数；
• 主观题是否需要人工阅卷，还是只判客观题；
• 考生能否查看成绩、答题记录和正确答案。

这一步建议用两个不同账号测试，一个作为出题管理员，一个作为考生，避免权限混淆。

5.4 题库刷题功能验证

在"题库"或"刷题"模块：

• 按科目或分类导入题目；
• 设置题目标签和难度；
• 开启刷题模式，模拟考生连续答题；
• 检查练习记录、正确率、错题本是否正常。

如果支持 Excel 批量导入，先导入 3 到 5 条测试数据，确认字段映射正确，再导入完整题库。批量导入最容易出问题的是模板格式，常见错误包括多选答案分隔符不一致、Excel 列名与模板不匹配、题目内容中包含英文逗号导致分列错误。

5.5 AI 智能组卷测试

AI 智能试卷是 SurveyKing 这类系统的亮点，但测试时要格外仔细。操作过程大概是：

1. 准备一个分类清晰、题量充足的题库；
2. 新建试卷时选择"AI 智能组卷"或"自动组卷"；
3. 输入试卷标题、目标题量、难度分布等条件；
4. 让系统自动从题库抽取题目；
5. 生成试卷后人工检查。

检查维度包括：

• 是否出现重复题目；
• 难度分布是否符合设定；
• 抽取的题目是否跟试卷标题相关；
• 多选题答案是否完整；
• 总分数是否达到预设值。

从材料看，AI 组卷依赖的是题库素材本身。题库分类越细、难度标注越准确，AI 组卷的效果越可信。如果题库数据很乱，AI 组卷出来的试卷也会很乱。第一次生成后建议逐题过一遍，不要直接发布。

5.6 数据导出与统计验证

完整验证还应覆盖数据导出：

• 问卷结果统计图表是否显示正确；
• 单项数据是否可导出 Excel/CSV；
• 考试成绩是否可导出；
• 汇总统计是否包含全部提交数据。

导出功能容易踩坑的地方包括：中文字段名乱码、Excel 格式打开报错、导出接口超时、数据量大的时候后端内存溢出。测试时用一个有几十条数据的问卷试一次，确认导出文件能正常打开。

5.7 权限与并发测试

如果时间允许，再验证一下：

• 普通用户是否只能看到自己有权访问的问卷和考试；
• 管理员是否只有管理后台权限，不能代替考生答题；
• 两个考生同时进入同一场考试是否互相影响；
• 同一账号多端登录是否被允许。

这些测试不用做得很重，至少把权限边界测一遍，避免上线后出现用户串数据的问题。

6. 接口 API 与批量任务

SurveyKing 作为前后端分离项目，后端接口天然具备集成价值。常见的集成场景包括：把问卷嵌入公司官网、通过 API 自动创建考试、把考试成绩同步到 HR 或教务系统、用脚本批量导入题库。

6.1 接口通用调用方式

先确认登录接口路径和鉴权方式。绝大多数 Spring Boot 项目使用 Token 或会话 Cookie 鉴权。通用流程如下：

# 登录获取 token，URL 需要按实际项目接口文档调整 curl -X POST http://127.0.0.1:8080/api/login \ -H "Content-Type: application/json" \ -d '{"username":"admin","password":"your_password"}'

返回结果通常类似：

{ "code": 200, "data": { "token": "eyJhbGciOiJIUzI1NiJ9..." } }

后续请求在 Header 里带上 Token：

curl -X GET http://127.0.0.1:8080/api/surveys \ -H "Authorization: Bearer eyJhbGciOiJIUzI1NiJ9..."

6.2 Python 调用模板

下面是一个通用的 Python 调用脚本，实际路径和参数需要对照项目的接口说明调整：

import requests BASE_URL = "http://127.0.0.1:8080" # 1. 登录获取 token login_resp = requests.post( f"{BASE_URL}/api/login", json={"username": "admin", "password": "your_password"}, timeout=10 ) token = login_resp.json()["data"]["token"] headers = {"Authorization": f"Bearer {token}"} # 2. 获取问卷列表 resp = requests.get( f"{BASE_URL}/api/surveys", headers=headers, timeout=10 ) print(resp.status_code) print(resp.json())

调用接口前，建议先用 Swagger 或项目自带接口文档确认参数结构，避免猜字段名。

6.3 批量导入题库设计

批量导入是高频需求。下面是一个通用的 Python 批量导入脚本框架：

import time import requests BASE_URL = "http://127.0.0.1:8080" AUTH_TOKEN = "your_token_here" headers = {"Authorization": f"Bearer {AUTH_TOKEN}"} questions = [ {"type": "single", "content": "1 + 1 = ?", "options": ["1", "2", "3", "4"], "answer": "2"}, {"type": "single", "content": "2 + 2 = ?", "options": ["2", "4", "6", "8"], "answer": "4"}, {"type": "multiple", "content": "以下哪些是编程语言？", "options": ["Python", "Java", "Word", "Excel"], "answer": "Python,Java"}, ] for i, question in enumerate(questions): try: resp = requests.post( f"{BASE_URL}/api/questions", json=question, headers=headers, timeout=15 ) if resp.status_code == 200: print(f"第 {i+1} 条导入成功") else: print(f"第 {i+1} 条导入失败: {resp.status_code} {resp.text}") except requests.RequestException as e: print(f"第 {i+1} 条请求异常: {e}") time.sleep(0.5)

批量任务设计注意三点：

1. 单次请求不要过大，按条或分批提交，避免接口超时；
2. 每一条都要有成功失败记录，失败任务单独收集，方便重试；
3. 导入前先做数据校验，过滤空题目、重复题、选项缺失的脏数据。

6.4 试题导出与接口联调

如果项目提供了导出接口，还需要测试文件流返回是否正常。Python 调用示例：

import requests url = "http://127.0.0.1:8080/api/exam/1/export" headers = {"Authorization": "Bearer your_token"} resp = requests.get(url, headers=headers, timeout=30) with open("exam_result.xlsx", "wb") as f: f.write(resp.content)

文件下载接口很容易踩的坑是 Content-Type 不对，浏览器打开乱码或提示文件损坏。下载后务必用 Excel 实际打开一次，确认文件可用。

7. 资源占用与性能观察

SurveyKing 这类系统不涉及 GPU 推理，性能瓶颈主要在 Java 进程、数据库连接和前端静态资源加载。性能观察的重点也和 AI 模型项目不一样，主要看内存、CPU、数据库连接数。

7.1 进程与端口观测

启动后端后，用以下命令观察：

# 查看 Java 进程 ps -ef | grep java # 查看内存占用 top -p $(pgrep -f surveyking | head -1) # 查看端口监听 netstat -tlnp | grep 8080 # 查看 MySQL 连接数 mysql -u survey -p -e "SHOW PROCESSLIST;"

从常见部署实践来看，Java 进程内存占用一般在 512MB 到 1GB 左右，具体取决于 JVM 参数和业务并发量。如果服务器本身只有 2G 内存，再跑一个 MySQL 会很紧张，建议限制堆内存。

7.2 降低资源占用的方法

内存紧张时可以做这几件事：

# 限制 JVM 堆内存为 256MB 到 512MB java -Xms256m -Xmx512m -jar surveyking-*.jar

• MySQL 配置里降低max_connections，避免空闲连接占满；
• 关闭不需要的功能模块，比如系统信息里的耗时统计；
• 定时清理过期问卷、无用的上传文件和日志；
• Nginx 开启 gzip 压缩和静态资源缓存，减少前端重复加载。

7.3 影响性能的关键因素

问卷提交量越大，数据库写入压力越大。考试同时在线人数越高，接口响应时间越长。题库查询频率越高，索引设计越重要。

建议这样观察：

• 开启 MySQL 慢查询日志；

SET GLOBAL slow_query_log = ON; SET GLOBAL long_query_time = 2;

• 查看哪些 SQL 执行超过 2 秒；
• 针对高频查询字段建索引；
• 定期分析表结构，清理冗余字段。

大多数情况下，这类系统在几千人级别的问卷调查场景下是够用的。真正需要担心的不是单机性能，而是部署规范和数据备份。

8. 常见问题与排查方法

下面是 SurveyKing 这类 Spring Boot + Vue + MySQL 项目部署时的高频问题清单。

排查时最忌讳盲改配置。先看日志，日志会告诉你问题出在哪一层。如果日志信息不够，再逐步缩小范围：后端、前端、数据库、网络，一个环节一个环节排除。

8.1 后端日志怎么看

以 Spring Boot 为例，启动日志会输出非常多的信息。重点看：

• ERROR级别日志，这里基本是异常位置；
• Caused by字段，这里会直接指出根因；
• 数据库相关的SQLException、CommunicationsException，说明是数据库连接问题；
• FileNotFoundException、Permission denied，说明是文件或权限问题。

8.2 浏览器控制台怎么用

打开浏览器开发者工具，切到 Network 面板，刷新页面。重点看：

• 哪些请求返回 4xx 或 5xx；
• 登录接口是否正常返回 Token；
• 静态资源是否加载成功，404 说明路径配错；
• 请求耗时是否异常高。

前端页面的很多白屏问题，本质是接口报错或静态资源路径错误。

9. 最佳实践与使用建议

9.1 部署侧建议

• 生产环境用独立业务账号连接数据库，不要用 root；
• 管理后台的登录路径不要用默认路径，通过 Nginx 做路径改写或限制 IP 访问；
• 给服务器开启防火墙，只放行必要端口；
• 如果系统面向公网，务必配置 HTTPS，避免登录密码明文传输；
• 定期备份数据库，问卷和考试数据丢一次代价很大。可以把备份任务写成脚本：

#!/bin/bash TIMESTAMP=$(date +%Y%m%d_%H%M%S) mysqldump -u survey -pYourStrongPassword surveyking > /backup/surveyking_$TIMESTAMP.sql find /backup -name "*.sql" -mtime +30 -exec rm {} \;

9.2 使用侧建议

• 题库录入前先定义好分类、难度、题型字段，后面 AI 组卷才能稳定出效果；
• 问卷有效期、考试次数限制提前设置，避免用户反复提交污染数据；
• 涉及人脸、姓名、联系方式、身份证等敏感信息时，问卷说明里必须写明用途，并控制导出权限；
• 成绩导出前先在小范围做对比测试，防止导出格式异常；
• 多套问卷之间保持统一命名规范，方便后续检索和归档。

9.3 二次开发侧建议

• 保留一份最小可运行配置，放到独立分支或打标签，方便回滚；
• 前后端分别管理版本，前端构建产物不要提交到代码仓库；
• 接口调用统一封装鉴权逻辑，不要把登录请求散落在业务代码里；
• 批量任务要加日志和失败重试，不能只发请求不看结果；
• 新增题型或问卷模板时，先写一个测试用例，确认数据结构和前端渲染都兼容再合并。

10. 总结与下一步

SurveyKing 这类开源问卷考试系统，最值得尝试的点是它把问卷、考试、刷题、AI 组卷四种能力整合在一个项目里。对一个需要长期运营调查和考试场景的团队来说，这比分别选型四套工具要高效得多。

最先要验证的功能建议按这个顺序进行：登录注册、创建问卷、发布回收、创建考试、题库刷题、AI 组卷、数据导出。完整跑通后，系统的基础链路就没有大问题了。

最容易踩的坑有三个。一是 MySQL 配置错误，数据库连不上导致后端反复启动失败；二是前后端分离部署时接口地址和跨域配置出错，前端页面能看到但调不到数据；三是批量导入和 AI 组卷依赖题库质量，题库数据不规整，后面所有基于题库的功能都会受影响。

后续可以继续扩展的方向包括：接入企业微信、钉钉或飞书登录，把考试成绩同步到 HR 或教务系统，基于导出的问卷数据做团队内部的统计分析看板，把 AI 组卷能力封装成独立接口服务给其他系统调用。

如果只是临时收集一次数据，直接使用在线问卷平台更方便。但如果要长期运营一套自己的调查与考试基础设施，SurveyKing 值得你花一个下午部署起来试试。部署前先看项目仓库的最新 README 和安装文档，以实际版本为准。