Spring Boot与微信小程序问卷系统设计与实现全攻略

每年到了毕业设计季节，总有人拿着《基于Spring Boot的问卷调查系统小程序》这个题目来找源码和项目讲解。这个题被选中的频率高，有一个很现实的原因：它不像电商系统那样容易陷入支付和秒杀的并发泥潭，也不像考试系统那样自带严肃的出题规则，而是天然覆盖了“创建问卷、发布、填写、回收、统计”的完整业务链条，非常适合用Spring Boot加微信小程序来展示。

但很多同学第一次启动项目时，通常会卡在同一个地方。他们找到的源码能跑，可一旦导师问“这张表为什么这么设计”“多个选项是怎么存储的”“用户答案如何统计出来”，整个人就愣住了。代码是别人写的，逻辑不是自己的，答辩自然没有底气。这篇文章不准备把整套源码逐行贴出来，而是把我做完这个题目后觉得最关键的选型思路、数据设计、接口规划、小程序联调以及答辩讲解顺序都梳理一遍，希望你看完之后不只是会跑Demo，还能在代码里讲出自己的设计理由。

1. 问卷类毕设要展示的核心能力：把一次填表变成一套完整的业务闭环

一个好的问卷调查系统，导师其实不太关心你有没有做花哨的动画效果，也不关心问卷模板是否精美到跟商业平台一样。他更关心的是你会不会用前后端分离的思路，把一套表单从生成到回收的完整流程讲清楚。哪怕做出来的界面很简单，只要闭环是通的，工作量就能站得住脚。

1.1 这个小程序系统并不只是“做一个问卷”

你仔细看这个题目名称：问卷调查系统的设计与实现。重点是“系统”两个字。既然是系统，就必须有管理员、有普通用户，有数据流转的逻辑。我在设计时会把整条业务线拆成几条主线来思考。

第一条线是调查问卷的创建与发布。管理员可以登录后台，创建一份新问卷、往里面添加不同类型的题目，比如单选题、多选题、填空题，然后设置问卷的标题、描述和状态。问卷只有处于“已发布”状态时，用户端小程序里的列表才能看到它。这样做的目的是让系统里存在“正常数据”和“下架数据”两种状态，答辩时有东西可讲。

第二条线是用户端登录与填写。用户打开微信小程序，通过微信授权拿到登录标识。登录之后可以在首页看到所有已发布的问卷列表；点击某一份问卷进去之后，系统会把这份问卷的题目动态渲染成表单；用户完成答题并提交后，后端会校验数据并保存答卷记录。

第三条线是数据统计与管理回收。用户提交的每一份答卷都需要被持久化，常见的管理端功能包括：查看某份问卷共收到多少份答卷、每个单选题各选项被选了多少次、多选题的选项分布、填空题的文本内容等。把这三条线走通，系统才算真正做了“设计与实现”，而不是只做了一个静态表单页面。

1.2 为什么技术栈推荐Spring Boot加原生微信小程序

毕业设计选技术栈，首先要考虑的不是“最流行”，而是“最稳”。Spring Boot在校园里的普及率非常高，绝大多数导师都熟悉这套技术，即使答辩时老师没有做过Spring Boot，也能很快理解分层结构。而Spring Boot的好处在于它把项目启动、配置、内嵌Tomcat、数据源管理等事情都帮你处理好了，不需要像传统SSM那样花大量时间去配置XML文件。

微信小程序端的优势就更明显了。小程序不需要用户在浏览器里输入网址，也不用担心安卓和iOS适配的问题。问卷类业务的用户使用场景本身就是“快速打开、简单填写”，小程序的下拉即用体验比H5页面更自然。而且小程序开发工具的调试功能很方便，开发者可以看到前端的请求数据、Storage缓存和网络状态，这部分内容正好可以作为论文里的测试截图像素材。

这里要提醒一点：如果你本机主要用的是JDK 8，不要盲目选择Spring Boot 3.x版本。Spring Boot 3.0从底层依赖Java 17，如果电脑上两套JDK环境切换不熟练，启动时经常会出现莫名其妙的版本报错。我个人比较推荐Spring Boot 2.7.x系列加上JDK 8这个搭配，稳定、资料多、遇到问题搜索时也能快速找到解决方案。后端持久层可以用Spring Data JPA也可以使用MyBatis-Plus，如果你平时更熟悉SQL和Mapper，选择MyBatis-Plus能降低手写XML的工作量，联表查询时也可以直接写SQL。

2. 先把功能模块和页面画清楚，再谈写代码

我在带项目的时候发现一个规律：很多同学上来就急着写实体类，连“问卷和小程序用户是什么关系”都没想明白，结果写到一半又开始重构。问卷调查系统虽然逻辑不算复杂，但如果前后端接口没有统一规划，后期拼接时同样会非常痛苦。

2.1 两个角色、三块功能区的需求拆分

我建议你把需求划分为两类角色来理解。

管理员角色是需要一套独立后台页面的。有同学觉得“我都用Spring Boot写后端了，直接在数据库里插数据不就行了？”这个想法在答辩时很容易吃亏。因为问卷调查系统的“问卷管理”本身就是核心功能，你至少要做出问卷的新增和编辑页面。哪怕后台页面做得很简单，也一定要能体现出管理入口。后台至少需要包含以下页面：

• 管理员登录页：账号密码登录，返回Token
• 问卷列表页：展示所有问卷，支持按名称查询
• 问卷编辑页：创建问卷、录入问卷标题、描述
• 题目配置区：在问卷中加入单选、多选、填空等题目并保存
• 答卷统计页：查看某份问卷的回收数量和统计结果

用户角色主要通过微信小程序完成操作。小程序端的页面不需要很多，但闭链必须完整：

• 首页：展示已发布的问卷列表
• 问卷详情页：加载问卷中的所有题目，并支持动态填写
• 提交成功页或结果提示：提交后给用户一个成功反馈
• “我的”页面：显示当前的登录用户信息，以及该用户以往提交过的问卷记录

另外你还需要把系统中的问卷状态做明确区分。我常用的状态值只有两个：0代表草稿或未发布，1代表已发布。后端在返回问卷列表的时候，只把状态为1的数据返回给小程序端。管理员端却能看到全部状态的数据。简单的一个字段，就能在答辩时解释清楚“为什么列表接口和管理接口返回的数据不一样”。

2.2 业务接口的规划与统一返回格式

接口设计决定前后端联调的效率。一开始你就要约定一个统一的数据返回结构，否则写小程序时会经常去翻后端返回值，效率很低。

我一般会定义一个统一的Result对象，里面包含三个核心字段：

java复制public class Result<T> {
    private Integer code;   // 200表示成功，其它数字表示业务异常
    private String message; // 提示信息
    private T data;         // 实际返回的数据
}

问卷相关的核心接口可以这样划分：

小程序端在发起请求时，如果发现返回的code不是200，就可以直接弹出message里的提示信息。这样即便后端校验失败，前端也不需要针对个案单独处理。

2.3 页面跳转之前先画草图，避免后期改目录

小程序的页面跳转主要分成两种：tabBar页面和普通页面。首页和“我的”页面可以设置为tabBar页面，用户能直观切换；问卷详情页和填写记录页则作为普通页面使用。普通页面在跳转时需要把问卷的id带过去。

很多初学者会在跳转之后重新发起登录请求或使用全局变量缓存问卷数据。这种做法第一个坑就是用户如果在小程序里切到后台太久，再次进入时页面数据可能没有刷新。我建议的做法是，在问卷详情页的onLoad参数中接收surveyId，然后通过该id向后端重新加载一份全新的问卷数据。这样保证了每个页面只依赖接口数据，呈现更稳健。

3. 数据库模型设计了四张主表，关键在“题型与答案”的存储方式

问卷调查系统数据库设计的第一步，是把主表关系捋顺。这里不推荐把选项直接散落到一个字段里，也不建议把整份问卷和答题结果放写成无差别的大JSON字段。毕设的系统讲究一定的“规范感”，让结构能被答辩老师一眼看明白。

3.1 四张主表的结构划分

我最后采用的是四张主表加一张可选模型表的方案。

第一张表是survey问卷表。核心字段包括：id、title、description、publish_status、question_count、create_time、update_time。publish_status字段控制前端是否显示这份问卷，question_count可以让列表直接展示“共X题”，避免每次都去题目表做一次count查询。

第二张表是survey_question题目表。核心字段包括：id、survey_id、question_type、question_text、sort、option_json。question_type我用数字标识：1表示单选题，2表示多选题，3表示文本填空题。关键在于选项的存储。很多人喜欢用单独一张option表，这个思路没问题，但会让代码量增加不少。出于毕设规模和可解释性，我建议将选项直接存入option_json。

“选项直接存成JSON数组字符串”的做法，听起来不那么“范式”，但配合单表查询确实非常清晰。比如某道单选题的选项存储值就是["非常不满意","不满意","一般","满意","非常满意"]。这样在管理端录入题目时，前端把选项数组序列化成字符串存进去；小程序端读取详情时，后端把字符串反序列化成数组交给页面渲染。代码既少又容易懂。

第三张表是survey_record答卷主表。每提交一次问卷，就插入一条记录。

对应用户属于同一份问卷的第二次提交，需要在此处做前置校验。如果一份问卷在业务上允许多人提交，但每个用户限一次，可以根据openid和survey_id两个字段去统计存在记录，从而阻止二次提交。这张表的核心字段包括：id、survey_id、openid、submit_time、used_time或cost_time。

第四张表是survey_answer答卷明细表。

它不能只记录一个用户的ID就结束，因为问卷有多个题目，所以每道题都值得单独存储一行。核心字段包含：id、record_id、survey_id、question_id、question_type、answer_text。answer_text统一用法存储用户的选择结果。单选题存“A”或存具体选项文本？这一点最好在设计时统一。考虑到后续要画出统计图，建议单选题和多选题都保存选项文本或选项数组，比如多选保存成["A","B"]或["前端开发","后端开发"]。

3.2 单选多选和填空在存储上的区别

我把三种题型的答案处理方式做成这样：

单选题的answer_text存储的是被选中选项的数组下标，比如0表示选择了第一个选项。多选题存储选项下标组成的JSON数组，例如[0,2]表示选了第一个和第三个选项。填空题存储文本内容。统计时，如果answer_text是填空内容，就直接做字符串汇总；若答案内容是数字下标，先题目表里的option_json取出来解析成list，然后通过下标取对应文本进行展示。这套规则从后端的答案入库逻辑、小程序的提交逻辑到统计逻辑都保持一致。

3.3 统计功能的核心实现思路

例如一份问卷里有一道单选的满意度题，选项为满意度A/B/C/D。假如已经有120个人作答，每个人都提交了一行answer数据；若字段内容直接存数字索引，统计时可以直接用数组累加。在Java里可以使用循环遍历明细表回答集合，将逐个回答拆成“索引”，再往一个计数的Map中累加；循环结束后，把Map的key排序并转化为跟前端约定好的数据结构。

如果后端不想做太复杂的聚合操作，还有一个折中方案，在每次提交答卷时，通过一个异步统计方法，直接把本轮答案加到整份问卷的统计表survey_statistics里。把复杂的计算下放到提交时刻去维护，后端读取时只要查这一行统计结果即可。毕业设计阶段不必为了性能去优化查询，但把统计过程讲清楚会让方案更有看点。

4. Spring Boot后端的核心代码结构，代码讲解也要按层次来说

拿到一份源码，如果不知道讲解顺序，到了答辩现场就会东一句西一句。我的建议是，讲代码时要像剥洋葱一样，从项目启动入口展开到配置、实体、接口、业务实现。

4.1 项目包结构的设计

为了让别人读代码不迷路，我建议用这样的分包方式：

• config包：放跨域配置、拦截器配置。
• controller包：放接口入口，只负责接收参数和返回结果。
• service包：定义业务接口及实现类。
• mapper包或dao包：与数据库交互。
• entity包：实体类，与数据库表字段一一对应。
• common包：R结果类、自定义异常类、工具类。

答辩代码时，开门见山先讲config包。小程序和后台是两个不同的服务端点，跨域请求是常见的，如果你在CorsConfig里通过实现WebMvcConfigurer，重写addCorsMappings方法，把允许所有路径的跨来源请求添加进去，它就能畅通无阻。虽然微信开发者工具中跨域的体验弱一些，但如果你额外开了网页后台预览接口，CORS的配置就很有必要了。

java复制@Configuration
public class CorsConfig implements WebMvcConfigurer {
    @Override
    public void addCorsMappings(CorsRegistry registry) {
        registry.addMapping("/**")
                .allowedOriginPatterns("*")
                .allowedMethods("GET", "POST", "PUT", "DELETE", "OPTIONS")
                .allowedHeaders("*")
                .allowCredentials(true)
                .maxAge(3600);
    }
}

4.2 JWT登录拦截与用户身份识别方案

在小程序授权登录中有一个固定的写法。wx.login()方法会拿到临时code，后端拿着这个code去请求微信的jscode2session接口，微信会返回openid。这个openid是用户在微信生态下的唯一标识。之后后端就可以根据openid去自己系统的用户表里查用户，如果不存在则插入一条新用户记录；存在则直接把用户数据返回。同时，后端生成一个自有的token字符串，小程序每次请求时在header里带上。

这里容易被误解的地方是“怎么拿到用户头像和昵称”。很多旧网上教程还在用getUserInfo接口，可是微信已经在很多位置上调整过该能力了。稳妥的做法是保持“让用户手动授权、主动上传头像昵称”的思路，或者在“我的”页面提供编辑入口，让用户自己填写昵称后再保存。设计这个流程时如果你更新了文档里的说明，会从测试截图中体现出来。

处理拦截器时，我会写一个LoginInterceptor，让它只拦截需要用户身份的接口，比如提交答卷、查看历史记录。管理员端可能另建一个AdminInterceptor拦截/admin开头路径。如果该类请求在Header里拿不到有效token，便直接返回401状态码。这一点在答辩时能展示你对权限隔离的判断力。

4.3 提交答卷的接口需要注意的两个校验点

问卷的后端提交，其实不是简单地插入一行。请你务必把关做好这两步：

第一，判断这份卷子状态是否允许提交。如果不加以约束，前端已下架的问卷很可能被用户直接调用API强制输入参数进行提交，导致数据进入表内。后端在新增方法里先查询出survey信息，检查publish_status字段等于1，再进行后续录入。

第二，判断该用户是否已经提交过。这就要根据surveyId与openid去survey_record表里查重。如果已存在，返回“您已经提交过该问卷”的业务提示。如果毕设的业务要求是允许一人多次填写，那这一判断可换为使用由管理员生成的邀请码限制，每个账号对每份问卷仅能提交一次。

4.4 管理员创建问卷时的批量保存设计

管理端添加一道题或修改一道题，往往需要进行批量操作。为了避免前端每保存一道题就请求后端一次，可以使用一个事务方法来处理整份问卷的保存逻辑：在后端先对survey表做保存或更新操作，再将题目JSON数组循环插入survey_question表。由于在同一事务里执行，中途一旦出现异常就不会造成“问卷主表更新成功，但题目写入一半”的脏数据状态。

面试或答辩中经常会问“为什么使用事务”，可以结合这里的批量保存去说明，而不是只背“保证原子性”口诀。

5. 微信小程序端的开发要点：动态表单、答案汇总、登录状态

小程序端相比后端代码，更需要关注页面渲染和用户交互。问卷填写页面本质上一个动态表单渲染器，你需要根据题目类型来渲染单选框、复选框，或者输入框控件。

5.1 动态渲染题目如何避免踩到小程序组件选择的坑

小程序中页面组件是不能在wxml循环里通过“if type等于1用radio，else if type等于2用checkbox”随意控制前后来随意切换的，这不是不行，只是会在开发工具的调试区里看到很多警告。比较可靠的做法是给每种题型进行一次统一渲染。

在单个题目的循环中，我给每个单选按钮和复选框一个明确的wx:if判断：当questionType === 1时，里面的每组radio-group绑定一个handleSingleChange事件；当questionType === 2时，在checkbox-group内绑定handleMultiChange；当questionType === 3时，渲染textarea输入框。

在小程序数据层，每道题需要建立答案容器。例如在答题页的data里定义answerMap对象，每次handleSingleChange事件触发时，把当前题目的id作为key，选中后的选中值作为value写入这个对象。多选则相对复杂，因为一个复选组切换后会触发连续的change事件，例如用户先选A再选B，change事件传入的数组可能就是变化后的数组，因此每次拿到后直接整体覆盖该题的value是最稳妥的，而不是通过旧的answer数组手工增删。

5.2 试卷详情如何组装提交数据

等到用户点击“提交”按钮时，小程序需要把answerMap里的数据转成后端能识别的JSON数组。如果你在页面上已经把answerMap维护好了，提交前需要再遍历一下细节中的question列表，确保每个必答题目都填了内容。官方要求“至少写一个理由”的部分要考虑点，免得后端接住脏数据。

后端约定收到的答案对象包含questionId、type、answer字段，其中answer字段对于不同题型需要序列化成一个数组或文本值。前端可以通过数组套对象的形式，把提交体data组织为：

javascript复制{
  surveyId: this.data.surveyId,
  answers: [
    { questionId: 1, type: 1, answer: [0] },
    { questionId: 2, type: 2, answer: [0, 2] },
    { questionId: 3, type: 3, answer: "这是一段反馈文本" }
  ]
}

request方法封装的时候要注意超时时间和content-type。微信默认的header是application/json，如果你后端接收参数用的是@RequestBody，那就不存在问题；如果后端用@RequestParam接收参数，就需要序列化成query字符串。这个细节时最容易让前后端花一晚上排查的。所以我推荐统一用@RequestBody + JSON对象去提交。

5.3 登录状态在tabBar页面之间的共享

当用户从首页进入填写页时，后端其实不太需要知道“当前用户到底叫什么名字”，只需要知道它对应的openid。第二次打开时不能丢失用户身份，这就需要把token存储到wx.setStorageSync里。每次发起请求前，在封装好的request方法中统一从storage中读取token，把它放进header里的Authorization字段。

如果是比较早看到的代码示例，在小程序的点击按钮上写getUserProfile，这类代码目前不能直接被当作现代学生的项目交付。新的做法是，把原本“强制一步获取完整头像昵称”的流程改为“页面显示一个登录按钮，点击后先使用wx.login获取code换取token，再由用户选择头像昵称，提交到后端保存”。这部分如果毕业设计需要交付演示资料，最好按官网最新的调整来实现，才不会被老师追问时显得跟不上更新。

6. 联调和试运行阶段最容易翻车的问题，这也正是“一条龙”服务最值钱的部分

很多拿别人源码的同学，最发愁的不是代码本身不能运行，而是代码能在作者电脑上运行，换到自己电脑上又到处报错。联调过程中反复出现的几类问题，几乎决定了你能不能顺利跑通Demo。

6.1 后端启动报错，多半是环境和版本不匹配

后端启动时报错需要看“Caused by”后面的一行原因，而不是看最顶上一大段红色的异常标题。我遇到过几次同学截图，明明异常信息是端口被占用，却以为是数据库连不上。使用Spring Boot项目时，检查顺序应当从下往上：先看application.yml里的数据库地址、账号密码、端口是否匹配；再检查MySQL服务有没有启动；接着检查依赖是否下载完整；最后看看8080等端口是否被占用。如果你把server.port改成8090之后仍然出现端口占用，就在命令行执行netstat -ano | findstr 8090来查找占用进程。

有时候启动过程中遇到的报错是因为数据库方言或字符集原因，比如MySQL 8.0跟旧版驱动类名不一致。推荐在application.yml里使用spring.datasource.url带上useSSL=false&characterEncoding=utf8&serverTimezone=Asia/Shanghai。serverTimezone不指定的话，日期时间字段容易出现偏移8小时的问题。

6.2 小程序请求不到本地后端，排查顺序是什么

开发阶段如果是在微信开发者工具中预览，小程序可以不校验合法域名。工具中的详情tab有“本地设置”，需要勾选“不校验合法域名、web-view（业务域名）、TLS版本以及HTTPS证书”。这样本地开发时直接用http://localhost:8080接口就能通。

如果使用手机真机预览，问题来了。手机上的“localhost”指向的是电脑的接口，除非你在真机调试时使用局域网IP，例如http://192.168.1.100:8080，同时把后端服务绑定到0.0.0.0。操作里最容易写的错误是在浏览器能打开接口，但手机打不开。原因大多是Windows防火墙阻挡了外部设备访问，或者后端虽然被正确启动，但它只监听了127.0.0.1这一个网卡。排查时，确认后端项目里没有特殊设置server.address=127.0.0.1，然后关闭系统防火墙后重试，这是能快速定位方向的地方。

小程序正式运行要请求合法域名，既然是毕业设计就不太有必要真的去申请一个HTTPS域名然后把后端部署到服务器。通常你只要在开发工具中让逻辑跑通，再录制演示视频就可以了。如果想在论文测试章节表明曾做过个人安装而不是个人域名申请，在描述时要表达得恰如其分，以“项目目前处于本地联调阶段”作为定性。

6.3 接口通但页面白屏，大概率是数据结构没对上

当用户在开发者工具的Network面板里看到请求成功返回，却发现页面数据还是空的，这时先打印一下res.data.data，观察它是数组、对象还是嵌套结构。

比如后端返回的数据整体是一个Result结构，前端如果没有在request里的resolve(res.data.data)处多包一层，就容易把数据源设成了包含code、message的整个外层对象。问卷列表页的wxml里循环渲染的是questions，而不是questionList时，也会出现取字段不显示的情况。先打开调试器的Console，在success回调里console一下具体变量，能省下很多改页面时间。

6.4 Java时间字段传到前端变成长串数字的修复

如果实体里用了LocalDateTime，而项目没有做全局Jackson配置，前端拿到的时间字段可能是一串数组或时间戳。页面展示提交时间时就会显示得很难看。这里提供两种备选方式。

最简方式是在实体字段上方加@JsonFormat注解：

java复制@JsonFormat(pattern = "yyyy-MM-dd HH:mm:ss", timezone = "GMT+8")
private LocalDateTime createTime;

另一种方式是配置一个全局的ObjectMapper，在JavaTimeModule中设置LocalDateTime序列化器。这样项目里所有时间字段都会统一输出成字符串格式。对毕设系统而言，使用@JsonFormat简单直接，也能在答辩时解释清楚索引作用。

7. 论文文档和代码讲解的顺序不能乱，直接决定答辩能不能顺利通过

源码能跑只是第一步。这个题目的完整交付通常包含程序、文档、代码讲解三个部分，在毕业设计的评价体系里，文档和讲解比重有时甚至比代码本身更高。

7.1 论文如何组织才能避免“流水账”

多数学校本科毕业设计论文的结构会建议按软件工程脉络来写。不要乱调顺序，否则老师会认为你的设计过程组织不清。常规的建议是第一章绪论，写背景与意义；第二章相关技术介绍，写Spring Boot、微信小程序；第三章需求分析，写用例、功能性需求及非功能性需求；第四章系统设计，写总体架构、功能模块图、数据库设计；第五章系统实现；第六章系统测试；第七章总结与展望。

容易出彩的地方在第三章和第四章。第三章先把用例图划出来，分别展示管理员用例和微信用户用例；第四章把数据库表之间关系以及表结构字段列表放到附录里，正文中用ER图来说明，不但占了篇幅，还非常清楚。

在使用结构图时，注意别画大而空的“系统架构图”。很多同学会画一个矩形框写上“前端”、一个矩形框写上“后端”，中间画一条线，就算架构图。这种图缺乏实际内容。建议至少细化成这样的层次：小程序端可以分成页面层、交互层与接口请求层；后端可以分成Controller接口层、Service业务层、Mapper数据访问层；底层数据存储MySQL。图里标注清楚“题目的动态渲染逻辑”与“答卷保存事务边界”放在哪一层，老师一看就知道你是真做过。

数据库设计章节里，表的说明不必直接扔一堆DDL，而是先描述各表用途，字段内容可以用表格概括。把survey表、survey_question表、survey_record表、survey_answer表的重点字段做成几个表格，会显得详实细致。由于题目和选项的关系采用了JSON数组存储的设计，这里务必要有个子标题介绍“非关系与半结构化数据的处理方法”，简要说明选择题选项存JSON是出于渲染和扩展方面的考虑。你不主动解释清楚的话，老师会误以为你故意不设计第三张范式表。

7.2 代码讲解怎么讲，才能像“一条龙”而不是在念脚本

代码讲解通常是录制视频或配合PPT展示。很多同学的讲解方式是拿代码编辑器一行行朗读，这是最让人犯困的处理。

比较好的思路是给自己定五步流程：

第一步介绍项目的整体目录结构。先运行起来系统，让观看者看到小程序首页、问卷列表和管理员后台的长相，建立直观感知。

第二步从登录链路开始讲。演示小程序的登录按钮触发wx.login拿到code的过程，说明后端如何换取openid并生成token。登录是所有业务的前提，把这里讲清楚，后面接口讲解就不需要回头补背景。

第三步重点讲提交问卷数据是如何被存储的。后端接到的answers数组会逐条循环写入明细表，这里可以打断点演示database中操作前后的变化。

第四步是讲分发的页面渲染和数据绑定，演示一道多选和一道填空题目如何在小程序上被动态渲染，以及提交到后端后answer_text字段在表中长什么样。

第五步最后演示管理后台的数据统计，并让某一用户从答题端提交一份新答卷，统计页面里人数如何增加。这五步做完，整个业务闭环就全部讲完，也避免了流水账。

至于“一份一条龙定制”时常见的场景，比如学生在拿到程序后还是不清楚如何修改页面标题和前端接口地址，你应该先找到小程序项目中utils/request.js，查看config里的baseUrl是否跟后端端口一致。所有的联调信息其实都集中在这类配置里。

7.3 答辩提问环节的高频问题，心里提前打好草稿

导师经常会顺着你的技术方案继续问，例如“为什么小程序的token要存在Storage里而不是全局变量？”这个问题比较显浅，因为小程序重启后全局变量会消失、Storage持久化不会被清除。被要求改进时可以说“持久化到Storage后，可再封装一个自动续期逻辑降低token过期后的重复登录次数”。

还有可能被问到“问卷发布状态是1、草稿状态为0，设计表结构时加这种status为什么不用布尔类型？”用Boolean也可以表达状态，但状态可能扩展为“已关闭”“已停止”或“定时发布”，用int维护更好扩展。你不必把话说得绝对，但要有自己选型的理由。

在我实际带项目的时候，最怕的不是同学问出基础问题，而是对方拿来的代码库和“一条龙”的配置串不齐，例如DB的用户名密码被人改成了个人环境，却不知道还需要全部重新匹配。所以你在搭建项目之后，第一步先把后端能正常启动、接口在浏览器能返回JSON、小程序首页在开发者工具能打开列表，之后才一个个功能向后排查。顺序一旦搞反，调试效率会非常低。跑起来之后，你再回到数据库表结构设计这一层，把survey、question、record、answer这四张表装进脑子，你会发现答辩时讲题目的设计思路会顺畅很多，代码表在纸上推演起来也比盲目改代码轻松省力得多。