1. 項(xiàng)目概覽這個(gè)問卷調(diào)查系統(tǒng)到底能做什么做技術(shù)這么多年我接觸過不少“看起來很基礎(chǔ)、做起來全是細(xì)節(jié)”的系統(tǒng)網(wǎng)上問卷調(diào)查系統(tǒng)就是其中典型的一個(gè)。很多朋友一開始覺得它就是“問卷CRUD 答題頁面”真上手之后才發(fā)現(xiàn)從題目類型設(shè)計(jì)、動(dòng)態(tài)表單渲染、答卷校驗(yàn)到統(tǒng)計(jì)報(bào)表每一環(huán)都能踩出不同的坑。這篇文章我想圍繞一個(gè)基于 SpringBoot 的網(wǎng)上問卷調(diào)查系統(tǒng)展開把我從項(xiàng)目設(shè)計(jì)、數(shù)據(jù)庫建模、核心代碼實(shí)現(xiàn)到部署排查的完整鏈路都拆開講講順便把源碼里值得關(guān)注的部分挑出來逐段說明。這套系統(tǒng)的定位非常明確面向中小規(guī)模調(diào)研場景比如企業(yè)內(nèi)部員工滿意度調(diào)查、學(xué)校課程評(píng)價(jià)、產(chǎn)品上線前的用戶反饋收集等。它需要支持管理員創(chuàng)建問卷、維護(hù)題庫、發(fā)布問卷、查看回收數(shù)據(jù)同時(shí)還要支持參與者打開鏈接答題、提交答卷、事后查看結(jié)果。從業(yè)務(wù)復(fù)雜度來看它不像電商系統(tǒng)那樣有復(fù)雜的交易鏈路也不像后臺(tái)管理系統(tǒng)那樣全是表格和權(quán)限配置它真正的難點(diǎn)在于“問卷是一種高度動(dòng)態(tài)的數(shù)據(jù)結(jié)構(gòu)”——每份問卷的題目數(shù)量不同、題型不同、選項(xiàng)不同答卷數(shù)據(jù)又是一對多關(guān)聯(lián)的這就要求在設(shè)計(jì)階段就把數(shù)據(jù)的靈活性和統(tǒng)計(jì)的可用性同時(shí)考慮進(jìn)去。這個(gè)項(xiàng)目適合誰來參考呢如果你正在學(xué)習(xí) SpringBoot 整合 MyBatis Plus想找一個(gè)能覆蓋“增刪改查 多表關(guān)聯(lián) 數(shù)據(jù)統(tǒng)計(jì) 前端渲染”的完整案例那它很合適。如果你要做畢業(yè)設(shè)計(jì)或者個(gè)人作品集那它同樣值得一看因?yàn)閱柧硐到y(tǒng)的業(yè)務(wù)閉環(huán)非常完整既能體現(xiàn)數(shù)據(jù)庫設(shè)計(jì)能力也能體現(xiàn)接口設(shè)計(jì)能力和業(yè)務(wù)建模能力。我這里會(huì)按實(shí)際的開發(fā)順序來講不是那種只貼代碼不解釋的教程每一步盡量說清楚“為什么這么做”。你哪怕之前沒見過問卷系統(tǒng)的代碼照著我這個(gè)思路也能把整個(gè)項(xiàng)目的脈絡(luò)捋明白。2. 整體設(shè)計(jì)思路與技術(shù)選型背后的考量2.1 為什么用 SpringBoot而不是傳統(tǒng) SSM很多老項(xiàng)目還在用 SpringMVC MyBatis XML 那一套能在里面游刃有余的開發(fā)者確實(shí)基本功扎實(shí)但是新項(xiàng)目再用 SSM 純屬自己給自己上強(qiáng)度。SpringBoot 的價(jià)值不在于“功能多”而在于它把那些固定套路全部收斂成了約定內(nèi)嵌 Tomcat、自動(dòng)裝配數(shù)據(jù)源、Starter 一鍵引入依賴再加上application.yml統(tǒng)一管理配置開發(fā)階段只需要關(guān)注業(yè)務(wù)本身。我見過不少朋友糾結(jié)“SpringBoot 是不是太傻瓜化了學(xué)不到底層原理”這個(gè)擔(dān)心其實(shí)沒必要——SpringBoot 只是把框架的裝配過程自動(dòng)化了你用到的 Spring IOC、AOP、事務(wù)傳播機(jī)制、MyBatis 映射原理一樣不少只是省掉了那堆web.xml和spring-mvc.xml而已。還有一個(gè)容易被忽略的點(diǎn)是測試和部署成本。問卷調(diào)查系統(tǒng)的迭代速度不慢經(jīng)常要加題型、加統(tǒng)計(jì)口徑SpringBoot 的spring-boot-devtools支持熱重啟配合spring-boot-maven-plugin打包出一個(gè)可執(zhí)行 Jar扔到服務(wù)器上java -jar就能跑。對于中小型團(tuán)隊(duì)來說這種“低摩擦”的交付方式比傳統(tǒng) SSM 要順滑得多。另外后續(xù)如果要引入 Spring Security 做登錄鑒權(quán)、引入 Redis 做答題防刷SpringBoot 生態(tài)的整合成本也低得多。2.2 數(shù)據(jù)庫建模問卷、題目、選項(xiàng)、答卷的關(guān)聯(lián)設(shè)計(jì)這一節(jié)是整個(gè)系統(tǒng)最核心的部分。我見過很多初學(xué)者把問卷設(shè)計(jì)成一張大表題目和選項(xiàng)全塞在 JSON 字段里這么做原型階段確實(shí)爽但到了“統(tǒng)計(jì)某道題有多少人選了某個(gè)選項(xiàng)”的時(shí)候就傻眼了Java 代碼里要解析 JSON、要手寫聚合邏輯性能差還容易出 bug。所以在這套系統(tǒng)里我采用了一套經(jīng)典的“四層模型”問卷表questionnaire記錄問卷基礎(chǔ)信息包括標(biāo)題、描述、狀態(tài)草稿/發(fā)布/結(jié)束、開始時(shí)間、結(jié)束時(shí)間、是否匿名、每日答題次數(shù)限制。題目表question通過questionnaire_id關(guān)聯(lián)問卷每個(gè)題目包含題型、題干、是否必填、排序號(hào)等字段。選項(xiàng)表option通過question_id關(guān)聯(lián)題目用于單選、多選、下拉等題型。填空和評(píng)分題沒有選項(xiàng)取決于題型標(biāo)記。答卷結(jié)果表answer主要記錄用戶對某道題目的作答內(nèi)容選項(xiàng)型題目存選項(xiàng)ID填空型題目存文本內(nèi)容。這里有一個(gè)關(guān)鍵點(diǎn)值得展開考試系統(tǒng)里的答題記錄通常用“一次提交一行主記錄 明細(xì)子表”的方式但問卷系統(tǒng)我不建議套用同一套模型。因?yàn)閱柧淼念}目是動(dòng)態(tài)的今天創(chuàng)建的問卷可能只有 5 道題明天創(chuàng)建的問卷可能就有 30 道題如果用固定字段去存每一題的答案表結(jié)構(gòu)就得頻繁變更。把這層邏輯放在明細(xì)表里讓每一行記錄都帶著question_id才能讓系統(tǒng)具備“任何問卷都能存”的擴(kuò)展能力。代價(jià)是查詢時(shí)需要多一次 JOIN但以問卷系統(tǒng)的數(shù)據(jù)量級(jí)來看這個(gè)代價(jià)可以忽略不計(jì)。2.3 業(yè)務(wù)模塊劃分不要把所有代碼堆在一個(gè) Controller 里我接手過一些所謂的“快速開發(fā)”項(xiàng)目三個(gè) Controller 搞定一切Service 層幾乎沒有業(yè)務(wù)SQL 全寫在 Mapper 注解里看起來代碼量很少但后續(xù)每加一個(gè)功能都要?jiǎng)永洗a。這套問卷系統(tǒng)我把模塊拆成五個(gè)部分問卷管理模塊負(fù)責(zé)問卷的 CRUD、發(fā)布、結(jié)束、復(fù)制。題目管理模塊在問卷下維護(hù)題目和選項(xiàng)支持拖拽排序源碼里用排序號(hào)實(shí)現(xiàn)前端可選。答題模塊面向參與者包括問卷可見性校驗(yàn)、題目渲染數(shù)據(jù)獲取、答卷提交和校驗(yàn)。統(tǒng)計(jì)模塊按問卷聚合回收數(shù)據(jù)計(jì)算選項(xiàng)占比、答題人數(shù)、平均分評(píng)分題型。用戶模塊這里做了精簡采用基于 Session 的簡單登錄管理員和普通參與者共用一張用戶表通過角色字段區(qū)分。這五個(gè)模塊拆完之后每個(gè) Mapper 都只對自己負(fù)責(zé)的數(shù)據(jù)表進(jìn)行操作Controller 層只做參數(shù)接收和結(jié)果封裝Service 層承載具體的業(yè)務(wù)流程。這樣的結(jié)構(gòu)不復(fù)雜又給后續(xù)擴(kuò)展留了余地。比如你要加一個(gè)“答卷導(dǎo)出 Excel”的功能只需要在統(tǒng)計(jì)模塊里加一個(gè)導(dǎo)出接口完全不用動(dòng)答題模塊的代碼。3. 核心功能詳解從題目類型設(shè)計(jì)到數(shù)據(jù)統(tǒng)計(jì)3.1 題目類型的抽象讓不同的題型共用一套渲染邏輯問卷調(diào)查系統(tǒng)的“靈魂”在于題目類型。你可以把題型抽象成三類基礎(chǔ)能力選項(xiàng)型單選、多選、下拉它們本質(zhì)上都是“從預(yù)置選項(xiàng)集合中選一個(gè)或多個(gè)”區(qū)別只在于選擇數(shù)量和 UI 控件的不同。文本型單項(xiàng)填空、多項(xiàng)填空它們需要用戶輸入文本校驗(yàn)規(guī)則可能是長度限制或正則匹配如郵箱格式。評(píng)分型評(píng)分題通常是 1~5 星和矩陣題前者的本質(zhì)是一組單選題后者的本質(zhì)是多行單選但在界面上要展示成表格。在設(shè)計(jì)數(shù)據(jù)庫的時(shí)候我建議用question_type字段存數(shù)字枚舉而不是直接存“radio”、“checkbox”這類前端名詞。原因是后端關(guān)心的是“這個(gè)是單選還是多選決定我如何校驗(yàn)答案”前端關(guān)心的才是“我該渲染成單選按鈕還是復(fù)選框”。如果數(shù)據(jù)庫直接存前端名詞一旦前端 UI 層改名數(shù)據(jù)結(jié)構(gòu)就要跟著改耦合度太高。合理的做法是后端用穩(wěn)定枚舉值返回給前端時(shí)再做一次映射給出前端認(rèn)識(shí)的類型標(biāo)識(shí)。在實(shí)際開發(fā)中我定義了一個(gè) Light 枚舉類包含單選、多選、下拉、填空、評(píng)分、矩陣這幾種類型。每種題型至少有兩個(gè)核心方法一個(gè)是“如何校驗(yàn)提交答案”另一個(gè)是“如何格式化答案用于存儲(chǔ)”。比如單選題提交值必須是題目下某個(gè)選項(xiàng)的 ID 且不能重復(fù)多選題則是一個(gè)數(shù)組需要校驗(yàn)數(shù)組中的每個(gè)元素都是合法選項(xiàng) ID且不能有重復(fù)項(xiàng)。這些校驗(yàn)邏輯放在 Service 層統(tǒng)一處理不要分散在 Controller 里。3.2 答卷提交策略校驗(yàn)、入庫與防重復(fù)答卷提交是整個(gè)系統(tǒng)里最容易出錯(cuò)的地方。我先說一個(gè)反例有人把答案數(shù)組直接序列化成 JSON 字符串存到一個(gè)叫answer_content的字段里然后在統(tǒng)計(jì)的時(shí)候解析這個(gè) JSON。這么做開發(fā)效率確實(shí)高但屬于“用代碼復(fù)雜度換取表結(jié)構(gòu)簡單度”等數(shù)據(jù)量上來之后統(tǒng)計(jì)分析的效率會(huì)非常糟糕而且一旦某個(gè)答案的格式變了老數(shù)據(jù)的解析就可能出錯(cuò)。這套系統(tǒng)的答題模塊采用的是“明文結(jié)構(gòu)化存儲(chǔ)”策略。參與者提交時(shí)后端收到的是[{questionId: 1, optionIds: [2,3]}, {questionId: 2, content: 不錯(cuò)}]這樣的結(jié)構(gòu)體Service 層會(huì)做以下幾步根據(jù)questionnaire_id加載問卷校驗(yàn)狀態(tài)是否為“發(fā)布中”校驗(yàn)當(dāng)前時(shí)間是否在開始時(shí)間和結(jié)束時(shí)間之間。加載問卷下的全部題目構(gòu)建一個(gè)MapLong, Question便于后續(xù)按題校驗(yàn)。逐題校驗(yàn)提交的答案。比如必填題沒有提交值要報(bào)錯(cuò)判斷題干和題目 ID 是否匹配防止使用者篡改參數(shù)提交不存在的題目。通過校驗(yàn)后以“一次提交生成一條總答卷記錄 每題答案一條明細(xì)記錄”的方式批量插入?？偞鹁碛涗浝锎鎲柧?ID、參與者 ID、提交時(shí)間、IP 地址可選明細(xì)記錄里存題目 ID、題目類型、選項(xiàng) ID 集合逗號(hào)拼接或文本內(nèi)容。關(guān)于“是否匿名”這里有個(gè)設(shè)計(jì)細(xì)節(jié)如果問卷開啟了匿名模式那么總答卷記錄里的user_id置空只保留一條由隨機(jī)字符串生成的標(biāo)識(shí)用于區(qū)分“同一份答卷中的多條明細(xì)記錄”。這樣既能做到匿名又能在統(tǒng)計(jì)時(shí)區(qū)分不同的答卷。防重復(fù)提交方面我在源碼里用了簡單的“Session 問卷 ID”標(biāo)記同一個(gè) Session 對同一份問卷只能提交一次。如果要更嚴(yán)格一些可以改成基于 IP 和問卷 ID 的 Redis 標(biāo)記但中小型項(xiàng)目用 Session 方案已經(jīng)足夠畢竟問卷系統(tǒng)的并發(fā)量不太高。3.3 統(tǒng)計(jì)報(bào)表用 SQL 聚合而不是在 Java 中循環(huán)統(tǒng)計(jì)功能最能體現(xiàn)一個(gè)開發(fā)的 SQL 功底。以“單選題各選項(xiàng)占比”為例最直觀的思路是查出所有答卷明細(xì)然后在 Java 里循環(huán)計(jì)數(shù)。這個(gè)方案在數(shù)據(jù)量幾百條的時(shí)候沒問題但如果問卷參與人數(shù)上萬就很容易引發(fā)性能問題——你會(huì)在內(nèi)存里維護(hù)一個(gè)巨大的 List然后循環(huán)、分組、計(jì)數(shù)既浪費(fèi)內(nèi)存又拖慢響應(yīng)速度。正確的思路是讓數(shù)據(jù)庫去做聚合。比如統(tǒng)計(jì)“題目ID為 123 的單選題各選項(xiàng)被選擇的次數(shù)”可以用一條類似這樣的 SQLSELECT answer_detail.option_value, COUNT(*) AS cnt FROM answer_detail WHERE answer_detail.question_id 123 AND answer_detail.questionnaire_id 456 GROUP BY answer_detail.option_value這里option_value字段存儲(chǔ)的是逗號(hào)拼接的選項(xiàng) ID 字符串比如“2,5”。GROUP BY 之后就能得到每個(gè)選項(xiàng)組合的計(jì)數(shù)。對于單選題一個(gè)選項(xiàng) ID 不會(huì)出現(xiàn)兩次所以直接按它分組是沒問題的但對于多選題一份答案里可能同時(shí)選了 2 和 5這時(shí)候想要“選項(xiàng) 2 被選了多少次”就需要額外的處理。我的做法是給選項(xiàng)表增加一個(gè)“編號(hào)”的概念在統(tǒng)計(jì)時(shí)將多選答案的字符串拆開后與選項(xiàng)表關(guān)聯(lián)再按選項(xiàng) ID 分組。具體可以放在一個(gè)自定義 Mapper 方法里寫一小段 SQL 來完成。如果要統(tǒng)計(jì)評(píng)分題的平均分就直接取對應(yīng)題目明細(xì)里的數(shù)值字段做 AVG 聚合。統(tǒng)計(jì)結(jié)果最終封裝成一個(gè)MapInteger, Long或ListOptionStat對象返回給前端前端用圖表庫渲染成餅圖或條形圖。我在本地調(diào)試的時(shí)候用 5000 份模擬答卷跑過一遍整條統(tǒng)計(jì)鏈路耗時(shí)在 200 毫秒以內(nèi)完全夠用。4. 配置、啟動(dòng)與部署從零跑通整個(gè)項(xiàng)目4.1 需要準(zhǔn)備的環(huán)境清單在動(dòng)手跑這個(gè)項(xiàng)目之前先檢查一下本機(jī)環(huán)境。我建議的版本組合如下軟件推薦版本說明JDK1.8 或 11SpringBoot 2.7.x 對這兩個(gè)版本兼容性最好Maven3.6用于依賴下載和項(xiàng)目打包MySQL5.7 或 8.0注意驅(qū)動(dòng)和時(shí)區(qū)配置差異Navicat / DataGrip任意用于導(dǎo)入 SQL 腳本和查看數(shù)據(jù)前端開發(fā)者工具任意便于調(diào)試接口返回結(jié)構(gòu)這里要重點(diǎn)提醒一個(gè)容易踩的坑如果你用 MySQL 8.0pom.xml里的mysql-connector-java版本別太老否則會(huì)報(bào)Public Key Retrieval is not allowed的錯(cuò)誤。解決方式是升級(jí)驅(qū)動(dòng)版本或者在數(shù)據(jù)庫連接 URL 上加上allowPublicKeyRetrievaltrueuseSSLfalse。4.2 核心配置文件解讀application.yml是 SpringBoot 項(xiàng)目的樞紐。我拿這個(gè)項(xiàng)目里最關(guān)鍵的幾個(gè)配置來說server: port: 8080 servlet: context-path: / spring: datasource: url: jdbc:mysql://localhost:3306/survey_system?useUnicodetruecharacterEncodingutf-8useSSLfalseserverTimezoneAsia/Shanghai username: root password: your_password driver-class-name: com.mysql.cj.jdbc.Driver jackson: date-format: yyyy-MM-dd HH:mm:ss time-zone: GMT8 mybatis-plus: configuration: map-underscore-to-camel-case: true log-impl: org.apache.ibatis.logging.stdout.StdOutImpl global-config: db-config: id-type: autoserverTimezoneAsia/Shanghai和time-zone: GMT8這兩個(gè)配置是一對的少一個(gè)都可能導(dǎo)致日期時(shí)間字段差 8 小時(shí)。這個(gè)問題我在本地出現(xiàn)過看起來是數(shù)據(jù)寫入時(shí)間不對實(shí)際上是連接時(shí)區(qū)沒對齊。map-underscore-to-camel-case: true讓數(shù)據(jù)庫字段questionnaire_id自動(dòng)映射為 Java 屬性questionnaireId寫 Mapper XML 時(shí)就不用反復(fù)起別名。log-impl: StdOutImpl會(huì)在控制臺(tái)打印 SQL 日志開發(fā)階段建議開著方便排查問題上線前記得改成org.apache.ibatis.logging.nologging.NoLoggingImpl或者刪掉避免日志刷屏。4.3 數(shù)據(jù)初始化一份 SQL 腳本能省多少事源碼里附帶的sql文件夾下有建庫建表腳本包括用戶表、問卷表、題目表、選項(xiàng)表、答卷表、答卷明細(xì)表以及少量初始數(shù)據(jù)。我第一次拿到這個(gè)項(xiàng)目的時(shí)候是直接在 MySQL 里手動(dòng)建表的結(jié)果因?yàn)樽侄晤愋秃?MyBatis Plus 的映射對不上花了不少時(shí)間排查。后來我建議的做法是直接導(dǎo)入 SQL 腳本把表結(jié)構(gòu)和初始管理員賬號(hào)一次性建好。導(dǎo)入之后先確認(rèn)幾件事表前綴是否和 MyBatis Plus 的全局配置一致。如果表名有前綴如t_questionnaire需要在配置里指定table-prefix: t_或者讓實(shí)體類加TableName(t_questionnaire)注解。檢查初始密碼的加密方式。如果源碼里用的 MD5 加鹽確保你的登錄邏輯和數(shù)據(jù)庫里存的密文格式一致否則會(huì)出現(xiàn)“賬號(hào)密碼都對但登錄失敗”的詭異問題。確認(rèn)問卷狀態(tài)字段的默認(rèn)值。數(shù)據(jù)庫里建議給status字段加默認(rèn)值 0并加上注釋說明 0 草稿、1 發(fā)布、2 結(jié)束。這樣開發(fā)期不容易誤操作。4.4 本地啟動(dòng)的完整步驟整個(gè)啟動(dòng)流程其實(shí)非常標(biāo)準(zhǔn)步驟如下用 Maven 執(zhí)行clean package或者直接在 IDEA 里Reload All Maven Projects確保所有依賴都下載完畢。本地 MySQL 中創(chuàng)建數(shù)據(jù)庫survey_system設(shè)置字符集為utf8mb4導(dǎo)入 SQL 腳本。修改application.yml中的數(shù)據(jù)庫賬號(hào)密碼為你本機(jī)的實(shí)際配置。啟動(dòng)SurveyApplication.java的主方法。瀏覽器訪問http://localhost:8080用腳本里初始化的管理員賬號(hào)登錄后臺(tái)。在問卷管理頁面創(chuàng)建一份問卷添加幾道題單選、多選、填空然后點(diǎn)擊“發(fā)布”復(fù)制答題鏈接用無痕窗口打開答卷頁面完成一次完整答題。第 6 步非常重要我建議每位拿這套源碼去改的朋友都完整走一遍“創(chuàng)建問卷→發(fā)布→答題→查看統(tǒng)計(jì)”的閉環(huán)而不是直接改代碼。只有先跑通主線流程你才知道哪塊是正常的、哪塊是你改壞的。我之前帶過一位實(shí)習(xí)生一上來就改數(shù)據(jù)庫字段結(jié)果問卷發(fā)布后答題頁面怎么都渲染不出來最后發(fā)現(xiàn)是題目表的question_type字段值枚舉對不上。先跑通一遍就是給自己建立一個(gè)“正?；€”。5. 前端交互與渲染動(dòng)態(tài)問卷表單是怎么做到的5.1 接口設(shè)計(jì)和數(shù)據(jù)協(xié)議約定很多朋友在學(xué)后端的時(shí)候會(huì)忽略接口設(shè)計(jì)但問卷系統(tǒng)的接口設(shè)計(jì)直接決定了前端渲染的復(fù)雜度。在這套系統(tǒng)里問卷答題頁面的核心接口就一個(gè)根據(jù)問卷 ID 獲取完整的問卷內(nèi)容。返回的 JSON 結(jié)構(gòu)大致如下{ code: 200, data: { questionnaireId: 19, title: 2024年度員工滿意度調(diào)查, description: 本問卷共10題預(yù)計(jì)耗時(shí)2分鐘, status: 1, deadline: 2024-12-31 23:59:59, questions: [ { questionId: 101, questionType: 1, required: true, stem: 你所在部門是, options: [ {optionId: 1001, text: 技術(shù)部}, {optionId: 1002, text: 市場部} ] } ] } }這個(gè)結(jié)構(gòu)的特點(diǎn)是問卷、題目、選項(xiàng)一次性全量返回前端拿到后直接遍歷渲染即可。對于題庫量最大的問卷這種方式的響應(yīng)體積也就在幾十 KB 左右完全沒必要做成分頁加載。如果后續(xù)問卷題目數(shù)量特別多比如超過 100 題再考慮分步加載或者按頁加載初期不必過度設(shè)計(jì)。5.2 動(dòng)態(tài)渲染的關(guān)鍵代碼思路前端在拿到數(shù)據(jù)結(jié)構(gòu)后需要根據(jù)questionType字段渲染不同的控件。核心是一個(gè)條件判斷映射單選題渲染成 radio 組多選題渲染成 checkbox 組下拉題渲染成 select填空題渲染成 input/textarea評(píng)分題渲染成一排星形按鈕矩陣題渲染成表格。以 Vue 為例大致的渲染邏輯是這樣的div v-forquestion in questions :keyquestion.questionId div classquestion-title {{ question.required ? * : }}{{ question.stem }} /div !-- 單選題 -- el-radio-group v-ifquestion.questionType 1 v-modelanswerMap[question.questionId] el-radio v-foropt in question.options :keyopt.optionId :labelopt.optionId{{ opt.text }}/el-radio /el-radio-group !-- 多選題 -- el-checkbox-group v-else-ifquestion.questionType 2 v-modelanswerMap[question.questionId] el-checkbox v-foropt in question.options :keyopt.optionId :labelopt.optionId{{ opt.text }}/el-checkbox /el-checkbox-group !-- 下拉題 -- el-select v-else-ifquestion.questionType 3 v-modelanswerMap[question.questionId] el-option v-foropt in question.options :keyopt.optionId :labelopt.text :valueopt.optionId/el-option /el-select !-- 填空題 -- el-input v-else-ifquestion.questionType 4 v-modelanswerMap[question.questionId] typetextarea placeholder請輸入你的答案/el-input /div提交時(shí)前端的answerMap已經(jīng)是一個(gè)“題目 ID → 答案”的映射比如{101: 1001, 102: [1003, 1005], 103: 挺好的}。把它轉(zhuǎn)成后端需要的列表格式后 POST 給提交接口即可。這個(gè)環(huán)節(jié)有一個(gè)容易被忽略的點(diǎn)填空題如果用戶什么都沒填但題目標(biāo)了必填后端一定要再次校驗(yàn)不能只依賴前端。因?yàn)榍岸诵ｒ?yàn)被繞過實(shí)在太容易了這是安全性的基本功。5.3 后端 XSS 防護(hù)和參數(shù)合法性校驗(yàn)問卷系統(tǒng)允許用戶輸入文本那就必然要考慮 XSS跨站腳本攻擊。如果有人在填空題里輸入一段scriptalert(xss)/script不處理的話這段內(nèi)容很可能在管理員查看答卷時(shí)被瀏覽器執(zhí)行。雖然答題入口是內(nèi)部的但這種教育成本很低的問題沒必要賭。我的建議是分兩層處理后端入庫前對文本類字段做 HTML 標(biāo)簽過濾把和轉(zhuǎn)義為lt;和gt;。前端顯示時(shí)使用 Vue/React 默認(rèn)的文本插值而不是v-html來渲染用戶提交的內(nèi)容。這一步是最重要的只要不用v-html渲染用戶輸入XSS 的風(fēng)險(xiǎn)就會(huì)大幅降低。參數(shù)合法性校驗(yàn)方面除了前面提到的題目 ID 和選項(xiàng) ID 匹配之外還要注意文本型答案的長度限制比如單題答案不能超過 500 字。評(píng)分題的范圍限制必須是 1 到 5 之間的整數(shù)。郵箱題如果有要校驗(yàn)郵箱格式。這些校驗(yàn)寫起來不復(fù)雜但要養(yǎng)成習(xí)慣。別覺得“內(nèi)部系統(tǒng)不用管安全”等到有人拿著你系統(tǒng)的鏈接刷問卷、灌垃圾數(shù)據(jù)的時(shí)候再回頭補(bǔ)這些校驗(yàn)就晚了。6. 統(tǒng)計(jì)模塊實(shí)戰(zhàn)數(shù)據(jù)可視化與導(dǎo)出6.1 統(tǒng)計(jì)頁面的數(shù)據(jù)和圖表對接問卷管理的后臺(tái)通常會(huì)有一個(gè)“查看統(tǒng)計(jì)”的入口。點(diǎn)擊之后頁面會(huì)展示這個(gè)問卷的回收概況總答卷數(shù)、有效答卷數(shù)、各題作答率即有多少人答了這道題以及每個(gè)選項(xiàng)的選擇人數(shù)和占比。統(tǒng)計(jì)接口的設(shè)計(jì)思路是按問卷聚合{ questionnaireId: 19, totalCount: 1280, questionStats: [ { questionId: 101, stem: 你所在部門是, type: 1, answerCount: 1275, optionStats: [ {optionId: 1001, text: 技術(shù)部, count: 520, rate: 40.8}, {optionId: 1002, text: 市場部, count: 755, rate: 59.2} ] } ] }前端拿到這個(gè)結(jié)構(gòu)后用 ECharts 畫餅圖或者條形圖非常直接。一個(gè)值得推薦的小技巧是不要在前端計(jì)算占比讓后端直接返回 rate 字段。這樣前端做展示更簡單同時(shí)后端可以在取數(shù)時(shí)統(tǒng)一處理精度和格式化邏輯避免不同頁面算出來的比例對不上。6.2 統(tǒng)計(jì)性能優(yōu)化索引、緩存、異步導(dǎo)出問卷系統(tǒng)在統(tǒng)計(jì)層面的數(shù)據(jù)量通常不會(huì)大到需要引入 Elasticsearch但有幾條優(yōu)化策略是很實(shí)用的第一給外鍵字段建索引。answer_detail表的questionnaire_id和question_id字段在多表 JOIN 時(shí)是高頻過濾條件建立普通索引就能大幅度加快 GROUP BY 和 WHERE 的查詢效率。我建議在初始化 SQL 腳本里就加上這層索引而不是等數(shù)據(jù)量大了再補(bǔ)。第二統(tǒng)計(jì)接口開啟 Spring Cache 緩存。同一份問卷在短時(shí)間內(nèi)被多次查看統(tǒng)計(jì)結(jié)果其實(shí)是一樣的。用Cacheable注解把統(tǒng)計(jì)結(jié)果緩存 5 分鐘能顯著降低數(shù)據(jù)庫壓力。注意問卷一旦有新答卷提交需要主動(dòng)調(diào)用CacheEvict清掉對應(yīng)問卷的緩存否則統(tǒng)計(jì)結(jié)果會(huì)一直不變。第三Excel 導(dǎo)出采用異步生成。當(dāng)后臺(tái)需要導(dǎo)出全部答卷明細(xì)時(shí)同步導(dǎo)出可能會(huì)導(dǎo)致請求超時(shí)。更好的做法是提交導(dǎo)出任務(wù)后返回一個(gè)任務(wù) ID后臺(tái)線程生成 Excel 文件再通過前端輪詢或 WebSocket 通知下載完成。這一步在初期可以不做但如果你的系統(tǒng)面向的問卷經(jīng)常有幾千人參與導(dǎo)出功能幾乎是必須的。6.3 一道題教會(huì)你多選題統(tǒng)計(jì)的拆分邏輯多選題的統(tǒng)計(jì)是新手最容易懵的地方。假設(shè)一道題有 5 個(gè)選項(xiàng)用戶選了“A、C”我們在answer_detail.option_value字段里存儲(chǔ)的是1,3?，F(xiàn)在想統(tǒng)計(jì)“選項(xiàng) AID1被選了多少次”如果用GROUP BY option_value只能統(tǒng)計(jì)出“同時(shí)選 A 和 C 的人有多少”得不出“選 A 的人有多少”。拆分的方式有幾種。一種是在 Java 中循環(huán)讀取后再統(tǒng)計(jì)適合數(shù)據(jù)量小的場景另一種是直接在 SQL 層面用FIND_IN_SET或LIKE處理比如SELECT COUNT(*) FROM answer_detail WHERE question_id 102 AND FIND_IN_SET(1, option_value) 0如果統(tǒng)計(jì)所有選項(xiàng)的分布可以用一條 JOIN 把選項(xiàng)表和答題明細(xì)表按 FIND_IN_SET 關(guān)聯(lián)起來再分組計(jì)數(shù)。不過需要留意的是FIND_IN_SET寫法簡單但當(dāng)數(shù)據(jù)量很大時(shí)無法走索引。所以在實(shí)際項(xiàng)目中我更推薦“冗余統(tǒng)計(jì)表”的策略每次答卷提交后異步更新一張question_option_stat統(tǒng)計(jì)表每個(gè)問卷、每個(gè)題目、每個(gè)選項(xiàng)一行直接累加計(jì)數(shù)。這樣統(tǒng)計(jì)接口永遠(yuǎn)只查這張小表性能又快又穩(wěn)定代價(jià)僅僅是提交時(shí)多一點(diǎn)更新開銷。對于中小型問卷系統(tǒng)這是性價(jià)比最高的方案。7. 常見問題排查與避坑實(shí)錄7.1 問題速查表這套系統(tǒng)在開發(fā)和部署過程中有幾類問題出現(xiàn)的頻率特別高我整理了一個(gè)速查表方便你直接定位現(xiàn)象可能原因解決方案啟動(dòng)時(shí)報(bào)Unknown database還沒有創(chuàng)建數(shù)據(jù)庫或庫名拼寫錯(cuò)誤在 MySQL 中執(zhí)行CREATE DATABASE survey_system DEFAULT CHARACTER SET utf8mb4;登錄失敗賬號(hào)密碼正確但進(jìn)不去密碼加密方式和數(shù)據(jù)庫密文不一致檢查登錄 Service 中使用的加密算法MD5/SHA與初始數(shù)據(jù)的密文格式對齊問卷發(fā)布后答題頁 404問卷狀態(tài)字段未設(shè)置為“發(fā)布”或接口路徑錯(cuò)誤確認(rèn)status1并檢查后端 Controller 的RequestMapping路徑時(shí)間字段差 8 小時(shí)數(shù)據(jù)庫連接 URL 缺少時(shí)區(qū)配置在url中加入serverTimezoneAsia/Shanghai統(tǒng)計(jì)接口響應(yīng)很慢沒有對questionnaire_id建索引給answer_detail表的questionnaire_id字段添加普通索引提交答卷后提示參數(shù)錯(cuò)誤題型枚舉值和實(shí)際不符檢查前端渲染用的題型映射和后端枚舉定義保持一致多選答案統(tǒng)計(jì)不準(zhǔn)沒有處理多選拆分改用“統(tǒng)計(jì)表冗余”或FIND_IN_SET拆分邏輯7.2 踩過的坑從一個(gè)拼接 SQL 導(dǎo)致的 Bug 說起有一次我在統(tǒng)計(jì)模塊里為了省事直接拼接了選項(xiàng) ID 的字符串去查詢數(shù)據(jù)庫結(jié)果某個(gè)選項(xiàng) ID 是兩位數(shù)時(shí)LIKE %1%把 ID 為 11、21 的選項(xiàng)也匹配進(jìn)去了統(tǒng)計(jì)結(jié)果直接翻倍。從那以后我給自己定了一條規(guī)矩能用參數(shù)化的寫法和FIND_IN_SET就不要用字符串 LIKE 匹配數(shù)字 ID。這條原則不只適用于問卷系統(tǒng)任何涉及 ID 過濾的場景都一樣數(shù)據(jù)格式規(guī)范化永遠(yuǎn)比“寫起來快”更重要。還有個(gè)常見的坑是在“復(fù)制問卷”功能上。很多系統(tǒng)支持一鍵復(fù)制已有問卷實(shí)現(xiàn)時(shí)如果只是把問卷表記錄復(fù)制一份而忘記同時(shí)復(fù)制題目和選項(xiàng)就會(huì)出現(xiàn)“問卷存在但打開編輯時(shí)一片空白”的詭異問題。正確做法是在事務(wù)里完成三步復(fù)制問卷主記錄遍歷原問卷下的所有題目為新問卷創(chuàng)建新題目和新選項(xiàng)同時(shí)維護(hù)好新舊 ID 的映射關(guān)系。這個(gè)邏輯不難但容易漏。7.3 關(guān)于并發(fā)提交的思考問卷系統(tǒng)有一個(gè)特殊場景同一個(gè)用戶、同一份問卷在多個(gè)標(biāo)簽頁同時(shí)提交。如果系統(tǒng)不做任何限制就可能產(chǎn)生重復(fù)答卷。處理方案我在前面提過 Session Redis 的標(biāo)記方式但更徹底的做法是在數(shù)據(jù)庫層面加一層唯一約束。比如在總答卷表里增加一個(gè)unique_key字段存儲(chǔ)user_id questionnaire_id 某次會(huì)話的隨機(jī)標(biāo)識(shí)在數(shù)據(jù)庫層面設(shè)置唯一索引。這樣即使前端重復(fù)提交、后端并發(fā)處理數(shù)據(jù)庫最終也只會(huì)保留一條有效記錄。這個(gè)方案比單純依賴后端邏輯要可靠得多因?yàn)樗亲詈笠坏牢锢矸谰€。8. 個(gè)人體會(huì)與幾點(diǎn)額外建議回到這個(gè) SpringBoot 網(wǎng)上問卷調(diào)查系統(tǒng)本身我個(gè)人的體會(huì)是它的代碼量不算大但覆蓋的知識(shí)點(diǎn)非常全面。從 SpringBoot 自動(dòng)配置到 MyBatis Plus 的 ActiveRecord 模式從 REST 接口設(shè)計(jì)到前端動(dòng)態(tài)渲染從 SQL 聚合統(tǒng)計(jì)到部署排查每一個(gè)環(huán)節(jié)都能在真實(shí)項(xiàng)目中找到對應(yīng)場景。對正處于學(xué)習(xí)階段的朋友來說把它“吃透”比急著上手微服務(wù)更有價(jià)值。最后分享一個(gè)小技巧做完這套問卷系統(tǒng)后你可以自己給自己提需求比如“支持刪除問卷前二次確認(rèn)”“支持統(tǒng)計(jì)結(jié)果導(dǎo)出 PNG”“支持答題進(jìn)度條”然后逐個(gè)實(shí)現(xiàn)。這些需求單獨(dú)看都不難但把它們一個(gè)個(gè)加進(jìn)去的過程就是對這套代碼最有效的鞏固方式。你在動(dòng)手的過程中會(huì)遇到“如何改表結(jié)構(gòu)而不影響老數(shù)據(jù)”“如何加接口而不破壞原有協(xié)議”這些真實(shí)問題而這些經(jīng)驗(yàn)恰恰是只讀一遍代碼學(xué)不到的。希望這篇文章能幫你少走一些彎路。