企业官网建设流程全解析

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 技术栈，前端是浏览器访问的管理台。

这里给一个通用参考：

如果你的机器只有 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。

长期维护上，建议关注版本更新。开源项目会不断修复漏洞和新增功能，不要一直停留在最初的版本。但升级前一定要先备份数据和当前版本配置，避免因升级导致数据不兼容。升级完成后，用选择题库抽卷能力进行回归测试，确认基础流程可用后再开放给用户。

最后留一个我自己的经验：这种系统真正长期用下去，最需要维护的不是代码，而是题库质量和数据规范。问卷、考试、刷题三个模块用熟以后，你会发现在线考试和练习的管理成本主要来自题目内容的定期更新，以及考试规则的持续校准。先把第一批问卷和考试跑通，再逐步丰富题库，比一开始追求所有高级功能要靠谱得多。