SurveyKing也就是中文社区里常说的“卷王”是一款开源的问卷与考试系统核心能力集中在问卷收集、在线考试、题库刷题和 AI 智能试卷生成这几个方向。它的定位非常明确不追求什么都做而是把“问卷、考试、刷题”这一条链路打通方便学校、培训机构、企业内部培训部门、人力资源团队以及个人学习者快速搭建自己的考试和调研平台。这篇文章会按实际部署顺序把安装准备、两种常见部署方式、问卷创建、考试配置、题库刷题和 AI 生成试卷的边界全部拆开讲同时把容易踩坑的地方标出来。我一般不建议一上来就研究所有功能先把系统跑起来创建一份问卷再搭建一场考试等流程完全走通后再考虑 AI 试卷和批量导入。毕竟这类系统的核心不是功能列表多不多而是能不能在普通服务器或本地电脑上稳定跑起来数据能不能正常回收导出是否方便。1. 先看 SurveyKing 到底适合谁用1.1 核心能力拆开看SurveyKing 不是一个纯问卷工具它把四个使用场景整合在了一起。问卷收集是最基础的能力适合做满意度调查、报名登记、意见反馈、活动收集等。和普通表单工具相比它更强调题型丰富、问卷结构清晰、数据可以导出统计。在线考试是它比较突出的能力。你可以创建一场限时考试设置考试开始和结束时间控制参加人数甚至可以配置及格分数。考试结束后后台能看到考生名单、答题情况、得分和成绩分布。题库刷题解决的是日常练习问题。你可以按科目、知识点、题型建立题库然后设置每天练习多少道题考生可以反复刷题系统会记录练习记录。这个场景特别适合培训机构、备考组织内部使用。AI 智能试卷是最近比较受关注的功能。它的思路是利用大模型能力根据你的主题、难度和题量要求生成试卷初稿。但这里必须先说清楚边界AI 生成的是初稿不是可以直接拿去考试的最终试卷题目是否符合教学大纲、答案是否正确、难度是否合理一定要人工复核。1.2 不同使用场景怎么选如果用一句话概括需要快速发布问卷并回收数据的先学问卷模块要组织正规考试的重点看考试模块需要日常练习积累的把题库模块用好AI 智能试卷建议放在最后尝试作为出题辅助。从部署形态看SurveyKing 是自建系统数据保存在自己的数据库里。这个特点对两类人特别有价值一类是学校或培训机构学生考试数据不好直接放在第三方平台另一类是对数据敏感的企业内部培训部门想把问卷和考试数据留在自己的服务器上。如果你只是临时做一次小规模调查不一定需要自建直接用在线表单工具可能更快。如果有长期规划想沉淀题库和考试记录那自建更合适。2. 部署前先理清环境再动手安装2.1 Docker 方式还是源码方式SurveyKing 的部署方式可以分为两大类Docker 部署和源码编译部署。Docker 方式是入门最友好的只要你机器上有 Docker 环境拉镜像、启动容器、配置端口和数据库连接基本上十分钟内可以见到登录页。适合本地学习、快速体验、小型团队使用。源码编译方式需要准备 JDK、Maven、Node.js手动拉取代码编译后端打包前端再配置数据库。过程更繁琐但胜在可控性强方便修改代码、定制功能、对接企业内部系统。如果你只是要一个能用的系统优先选 Docker。如果你有二次开发计划或者需要把部分功能嵌到自己系统里那源码方式更适合。这里有一个很常见的误区有人觉得源码编译一定比 Docker 更稳定。其实稳定性和部署方式没有直接关系反而错误配置更容易让源码方式挂掉。我第一次跑源码版时数据库时区配置没写对启动一直报时间字段错误排查了半天。用 Docker 方式时如果镜像里已经预设了配置这个坑会少很多。2.2 硬件和依赖准备先看硬件条件。SurveyKing 整体属于中轻量 Web 应用后端是 Java 技术栈前端是浏览器访问的管理台。这里给一个通用参考场景CPU内存磁盘适用情况最低配置1核2GB20GB个人学习、小范围问卷并发很低推荐配置2核4GB50GB小型学校、培训机构几十到一百人同时在线批量考试场景4核8GB100GB几百人同时在线考试需要保持数据库稳定如果你的机器只有 2GB 内存部署后系统能启动但数据库和 Java 服务会挤在一起并发一上来页面很容易卡。这种情况不要急着加并发先想办法把内存占用降下来比如降低 JVM 初始堆内存或者把 MySQL 的缓存调小一点。依赖软件方面不同部署方式要求不同Docker 方式只需要 Docker 和 Docker Compose数据库可以用容器启动。源码方式需要 JDK 1.8 或更高版本、Maven 3.6准备 MySQL 5.7 或 8.0、Redis 5.x 或更高版本还需要 Node.js 用于前端构建。原始资料没有给出特定版本要求落地时先确认你下载的源码或镜像对应文档避免版本不匹配。最常见的报错就是 JDK 版本不对Java 项目启动直接抛 UnsupportedClassVersionError一眼看是 Java 环境问题实际是版本号低了。2.3 端口、数据库和访问域名提前规划SurveyKing 后端默认会占用一个 HTTP 端口常见的是 8080 这类端口。如果你本机已经有其他服务占用了 8080启动会直接失败提示端口被占用。这时候不要硬停别人的服务改成自定义端口即可例如 8081、9090。数据库方面如果你用 Docker 方式通常会在编排文件里预设一个数据库名和账号密码。如果你用源码方式需要先手动创建数据库然后在配置文件中填写数据库地址、账号、密码、连接时区。常见坑点有三个数据库连接串里的时区没有配置系统启动后时间错乱或直接抛异常。数据库排序规则选错中文乱码。Redis 密码或端口配置错误登录会一直超时。域名方面如果只在内网访问IP 加端口就行。如果要通过公网使用建议在服务器安全组放通对应端口。如果想把系统挂在子域名下用 Nginx 做反向代理并设置上传大小限制否则导入 Excel 题库时可能报文件过大。3. Docker 方式快速安装3.1 安装 Docker 和 Docker Compose在开始之前先确认服务器已经装了 Docker。执行docker -v能看到版本号说明 Docker 已安装。没有的话不同操作系统的安装命令不一样CentOS、Ubuntu、Debian 都有差异直接查官方文档安装即可。Docker Compose 是另一个重要工具。SurveyKing 这类系统往往依赖 MySQL、Redis 等多个容器用 Compose 一次性启动会比手动逐个启动容器方便得多。检查方式是在终端执行docker compose version如果提示命令不存在安装一下 Docker Compose 插件即可。这里有个建议不要图省事把所有容器都放在默认网络里。先创建一个独立网络让 SurveyKing 应用容器和数据库容器在同一个自定义网络里这样容器名就能直接当主机名使用数据库连接配置会简单很多。3.2 拉取镜像并启动容器Docker 方式的核心步骤是拉取镜像、编写 Compose 文件、启动并检查日志。由于不同版本的镜像名和容器编排参数可能不同这里不写死具体镜像地址而是给一个通用思路。先启动 MySQL 和 Redis 容器。MySQL 要注意初始化字符集Redis 注意设置密码。确认两个依赖服务启动成功以后再启动 SurveyKing 应用容器。在 Compose 配置中你至少需要关注这几个配置项服务端口映射例如把容器的 8080 端口映射到宿主机某个端口。环境变量包括数据库地址、用户名、密码、Redis 地址。数据卷把数据库数据、应用日志挂载到宿主机目录避免容器删除后数据丢失。启动命令通常是docker compose up -d。启动后执行docker ps查看容器状态如果状态是 Up说明容器起来了。但容器起来不代表程序一定没问题还要看应用日志。执行docker logs -f 容器名查看后端启动输出看到类似“Started XXX Application”或者“Tomcat started on port”的输出说明启动成功。3.3 验证启动结果应用容器启动成功后在浏览器访问http://服务器IP:映射端口通常会出现两个入口一个是管理后台用来创建问卷、考试、题库另一个是考生端或答题端用来填问卷、参加考试、刷题。首次进入管理后台如果系统没有初始化管理员账号通常需要按照引导设置管理员用户名和密码。如果你不知道默认账号去查看启动日志有些系统会把初始账号打在日志里。到这里快速部署已经完成了。我建议你先停留在这一步用默认管理员账号登录后台随便创建一份只有两个问题的问卷测试一下创建、发布、填写、回收数据的全流程。这一步跑通再继续考虑端口优化、域名绑定和 HTTPS 配置。注意不要把 Docker 容器直接暴露到公网端口而不做任何访问控制。如果要在公网使用至少先改掉默认账号密码并且把数据库端口限制在容器内部网络不要直接映射到宿主机。4. 源码编译部署适合要二次开发的人4.1 下载源码和准备 JDK源码部署的第一步是拿到代码。SurveyKing 项目在 GitHub 等开源平台上有公开仓库搜索 “SurveyKing” 基本都能找到。下载源码建议使用 git clone 而不是直接下载压缩包好处是以后可以拉取更新查看版本变更。准备构建环境时先确认 JDK 版本。执行java -version查看当前版本如果版本偏低需要下载对应 JDK。这里以 JDK 1.8 为例但不同分支可能要求更高版本一定要先看源码根目录下的 README 或 pom.xml 里声明的 Java 版本。Maven 同样要提前安装并配置国内镜像源不然依赖下载会很慢。如果你所在网络访问 Maven 中央仓库不稳定编辑 Maven 的 settings.xml 文件换成国内镜像源。这一步几乎是必做的很多新手卡在源码编译阶段不是因为代码有问题而是依赖一直下载失败。4.2 初始化 MySQL 和 Redis源码方式部署数据库必须自己准备好。先创建数据库例如surveyking字符集选择 utf8mb4排序规则选择 utf8mb4_general_ci 或 utf8mb4_unicode_ci。这会直接影响中文标题、选项、解析内容的存储。Redis 的初始化相对简单启动 Redis 服务后确认端口和密码。如果源码默认 Redis 没有密码但你本机 Redis 设置了密码需要在配置文件里补上。初始化数据库表结构这一步不同项目做法不同。有些项目自带了 SQL 脚本执行脚本即可有些项目启动时会自动建表。启动前先看源码里的数据库脚本目录不要一启动就等着它自动建表避免初始化过程报错。4.3 修改配置并编译启动配置文件的名称通常是application.yml或application-prod.yml位置在 backend 模块的 resources 目录下。需要修改的配置项一般包括数据库连接地址、用户名、密码。Redis 连接地址、端口、密码。服务端口。文件上传目录后续题目的图片、Excel 导入模板都会存在这里。修改完配置文件进入后端目录执行 Maven 打包命令。常见的命令是mvn clean package -DskipTests打包产物会在 target 目录下生成一个 jar 文件。前端部分需要进入前端目录执行依赖安装和构建命令构建完成后把静态文件放到 Nginx 或者放到后端 jar 的静态资源目录下。首次启动源码版本时不要急着用生产配置。先把配置文件改成本地开发环境可用的最小配置启动成功后再逐步调整。源码方式还有一个优势是排错方便。后端日志会直接打印在终端看到报错后能快速定位是数据库连接问题还是 Redis 问题。比起 Docker 黑盒排错源码方式更适合做二次开发的人。5. 创建第一份问卷从题型到发布5.1 登录后台和初始化配置无论通过 Docker 还是源码方式部署第一次登录管理后台后建议先花几分钟把基础配置整理好。先看系统设置里有没有平台名称、Logo、注册开关、答题页底部信息等配置。这些会展示在问卷页面上直接影响考生或受访者看到的品牌形象。尤其是学生考试场景每次考试都显示默认配置会让你看起来很业余。再看用户体系。如果系统支持注册你要决定是否开放注册是允许任何人注册还是由管理员手动创建账号。大多数内部考试场景建议关闭开放注册由管理员导入考生名单。5.2 创建问卷与题型选择进入问卷管理页面新建一份问卷。你先要弄清楚这份问卷用于什么场景是匿名满意度调研还是实名报名登记或者是考试前的模拟练习。不同场景会影响题型选择。常见的考试和问卷题型包括单选题、多选题、判断题、填空题、简答题、评分题。如果你只计划做满意度调查单选题、评分题、简答题足够。如果你要做报名登记还需要姓名、手机号、部门这类信息字段。创建问卷时我一般会坚持一个原则一份问卷只解决一个核心问题。例如“员工食堂满意度调查”就只问食堂相关事项不要在问卷里又加一个“下季度团建地点投票”两个目的混在一起数据回收后统计维度会很难看。题型并不是越多越好关键是你能否在后台正确配置每个题目的参考答案和分值。如果题目需要自动计分单选题、多选题、判断题都必须设置正确答案评分题和简答题通常需要人工复核或只做匿名收集不能靠系统自动判分。5.3 发布问卷和回收数据问卷编辑完成后点击发布或开始收集系统会生成一个答题链接和二维码。你可以把这个链接放到钉钉、企业微信、公众号文章里也可以把二维码打印出来贴在现场。发布前一定要自己先点开链接以答题者身份完整提交一次。这一步能发现很多问题必填项没有设置导致数据缺失。选项过多手机端显示错位。逻辑跳转条件没配好答题者被跳到了错误页面。提交后页面没有返回成功提示。我第一次上线问卷的时候没做这个验证结果发布后才发现某个单选题目在手机端必填校验失效收集了一半数据才发现最后只能把所有数据删掉重新发布。这个教训很深刻千万不要嫌麻烦。5.4 问卷数据统计和导出问卷收集一段时间后进入后台查看结果统计。这里建议关注三个层面回收量有多少人提交是否达到预期样本量。完成率多少人打开了问卷但没有提交完成率低说明问卷太长或题目太难理解。选项分布每个题目的选项占比是否正常有没有明显的无效作答。数据导出通常支持 Excel 或 CSV 格式。导出后检查一下每一列是否和题目对得上。如果使用逻辑跳转跳过的题目会显示为空这是正常现象不要当成数据丢失。问卷数据回收后建议定期备份。尤其在大规模活动期间数据备份要提前配置好不要等活动结束后才发现数据被误删。6. 在线考试和题库刷题怎么落地6.1 题库分类和批量导入在线考试和题库刷题都依赖题库模块所以第一步是建题库。一个规范的题库应该先按学科或科目分类再按题型分类。例如在“计算机基础”分类下再区分单选题、多选题、判断题、简答题。这样做的好处是创建考试时可以直接按分类抽取题目刷题时也能指定知识点范围。新建题库后需要把题目添加进去。逐条添加适合题量少的场景但如果题量几百上千建议用系统的 Excel 批量导入功能。导入前先下载系统提供的标准导入模板按模板填写题干、选项、答案、解析、题型、难度等字段。不要把模板里的列删掉也不要擅自加列否则导入时容易报错。这里要特别提醒一下不要直接拿网上随意整理的题目填充题库。先看看每道题的答案和解析是否可靠尤其是技术类问题网上题目错误率不低。如果题库本身错题太多后续刷题和考试都会失去意义。6.2 创建考试并配置规则题库准备好以后进入考试模块创建一场考试。需要重点配置的规则包括考试名称、考试说明、考试封面。考试开始时间和结束时间。考试时长。是否限制参与人数。是否限制参加次数。及格分数线。是否随机打乱题目顺序和选项顺序。考试规则要提前和业务方确认不要在考试当天临时改。特别是“是否限制参加次数”这个配置有的场景允许考生反复练习有的场景必须一次考试机会。如果把练习考试和正式考试的规则搞混成绩数据会很难看。题目抽取时可以手动选题也可以按分类随机抽题。手动选题适合正式考试每道题都要人工确认随机抽题适合模拟练习让每次考试题目不完全一样。如果系统支持选项随机、题目随机能减少相邻考生互相抄袭造成的影响但这只是辅助手段不要把它当成绝对防作弊方案。6.3 学员端参加考试和查看成绩考试发布后考生通过公开考试链接进入答题页。正式考试前建议安排一次小范围模拟测试让考生熟悉答题界面查看倒计时显示是否正常提交按钮是否明显网络不佳时是否有断点续答提示。如果系统支持成绩即时发布考生交卷后就能看到得分和答题情况。注意确认是否也有“考试结束后统一公布成绩”的模式。有的考试需要在所有考生交卷后统一开放成绩查询这需要后台进行成绩发布操作。作为管理员考试期间要关注系统运行状态。如果同时在线人数较多页面变得很慢优先看服务器 CPU 和内存占用。如果不是内存不足而是数据库连接数不够需要调整数据库最大连接数。6.4 考试数据导出和复盘考试结束后后台会生成考试统计报表包括参考人数、缺考人数、平均分、最高分、最低分、及格率、每道题的正确率。导出成绩单时确认导出的文件是否包含考生姓名、学号或工号、得分、用时、交卷时间。复盘时重点看两道数据每道题的正确率和分数段分布。正确率过低的题目可能是题目本身错误也可能是讲解不到位正确率过高的题目要思考是不是题目太简单区分度不够。分数段分布如果出现明显的两极分化说明试卷难度设计可能需要调整。7. AI 智能试卷功能的实际使用边界7.1 这个功能到底能生成什么AI 智能试卷是 SurveyKing 里最容易被高估的功能。它本质上是一个“出题辅助工具”常见工作方式是你输入考试主题、章节范围、题目数量、难度层级系统调用大模型或内置生成引擎输出一份试卷草稿。它适合的场景包括快速生成模拟练习卷让考生进行日常训练。为正式考试生成初稿再由老师人工替换、修改。根据某个知识点批量生成变式题目降低组卷的人力成本。它不适合直接做正式考试卷。正式考试试卷要求题意准确、答案唯一、难度稳定AI 生成内容很难在第一次就达到这个要求。生成结果必须经过人工审核确认没有歧义题、超纲题和错误答案。7.2 使用前需要确认的前提不同版本的 SurveyKing 对接 AI 能力的方式不同。有些版本需要你配置大模型接口的调用参数有些版本使用内置模型模板生成。使用前先确认以下内容当前版本是否已经启用 AI 试卷入口。是否需要配置外部模型服务例如 API Key、接口地址。调用 AI 生成是否需要额外费用或者是否有调用次数限制。生成过程是否需要网络访问如果系统部署在无外网的内部网络AI 功能可能直接不可用。如果这些信息在界面上不明确尽量去看官方文档或替换版本说明不要假设所有版本都有这个功能。AI 生成相关配置里如果涉及外部服务的密钥不要硬编码在代码里也不要提交到 Git 仓库。可以把密钥放在环境变量或单独的配置文件中避免泄露。7.3 生成试卷后必须做的检查生成一份 AI 试卷后我建议按下面几个维度逐项验收题目是否属于你指定的章节范围。是否真的覆盖了你要求的题型还是只生成了大量选择题。单选题选项是否都设置了唯一正确答案。多选题答案是否有多选漏选、多选如何计分是否明确。题干中有没有逻辑错误数字是否一致。判断题答案是否唯一。检查过程中发现不合适的题目直接替换。除非生成质量很好否则不要偷懒直接用生成试卷发布考试。如果 AI 功能无法使用也不要慌SurveyKing 原本的题库抽卷功能已经足够支撑日常考试。只需要把题库建好按分类和随机策略组卷也能解决大多数需求。AI 功能是锦上添花不是核心依赖。8. 常见问题排查和稳定运行建议8.1 启动阶段常见问题后端启动失败是遇到最多的一个问题而且报错原因往往不是同一个。按下面的顺序排查通常能快速定位。先看日志。这听起来像废话但很多新手会盯着代码看却忽略了日志里已经写明了原因。无论是 Docker 还是源码方式日志都是第一信息来源。再看环境。数据库连不上要检查数据库容器是否启动、密码是否正确、数据库是否创建。Redis 连不上要检查 Redis 地址、端口、密码。如果出现中文乱码优先检查 MySQL 字符集是否 utf8mb4。然后看端口。如果提示端口被占用执行命令查看是哪个进程占用了端口把系统端口改成其他值再启动。最常见的一个误判是Docker 容器状态是 Up但应用日志里已经反复报数据库连接失败。因为容器进程没有退出所以docker ps看起来一切正常实际功能完全不可用。这种情况不要只看容器状态要看日志确认应用是否真正启动完成。8.2 使用阶段常见问题登录后台时如果页面能打开但登录一直失败先检查账号密码是否输入正确再检查验证码是否有效。如果确认没输错去数据库里查看管理员账号是否被锁定或状态异常。问卷提交失败可能是必填项校验没有通过也可能是浏览器提交的数据格式不符合系统预期。先换一个浏览器测试排除浏览器兼容问题。再查看浏览器开发者工具里的网络请求确认提交接口返回了什么错误信息。成绩导出异常时先确认导出的是不是 Excel 文件文件是否能在 Excel 或 WPS 中正常打开。如果导出的数据行数明显不对检查是否因为逻辑跳转导致部分字段为空或者导出时筛选条件设置得太严。考试当天突然访问变慢不要急着重启服务。先看服务器 CPU、内存、磁盘占用再看数据库连接数。如果历史日志一直不清理磁盘满了系统就越来越卡。8.3 数据备份与长期维护数据备份是自建系统最重要的一件事但往往被忽略。针对 SurveyKing至少需要备份两部分数据库数据包含问卷内容、题库、考试记录、成绩数据。文件数据包含上传的题目图片、视频、导入的附件。数据库备份最常用的是 MySQL 的 mysqldump 命令可以设置每日凌晨自动备份保留近 7 天备份。文件数据备份则是把挂载的数据目录定期拷贝到其他磁盘或对象存储。如果你是 Docker 方式部署数据库和文件都通过数据卷挂载在宿主机目录备份时可以直接复制目录也可以进入容器导出 SQL。长期维护上建议关注版本更新。开源项目会不断修复漏洞和新增功能不要一直停留在最初的版本。但升级前一定要先备份数据和当前版本配置避免因升级导致数据不兼容。升级完成后用选择题库抽卷能力进行回归测试确认基础流程可用后再开放给用户。最后留一个我自己的经验这种系统真正长期用下去最需要维护的不是代码而是题库质量和数据规范。问卷、考试、刷题三个模块用熟以后你会发现在线考试和练习的管理成本主要来自题目内容的定期更新以及考试规则的持续校准。先把第一批问卷和考试跑通再逐步丰富题库比一开始追求所有高级功能要靠谱得多。