每年三到五月總能在各種技術(shù)群里看到同一類問題“畢設(shè)選什么題好”“SpringBootVue有沒有成熟項目可以抄”“問卷系統(tǒng)源碼哪里有”。如果目標(biāo)是穩(wěn)定通過、拿一個體面的分?jǐn)?shù)我通常直接推薦在線問卷調(diào)查系統(tǒng)。它不是最炫的選題但卻是SpringBootVueMySQL這套組合里性價比極高的選擇業(yè)務(wù)閉環(huán)完整、需求邊界清晰、前后端工作量都體現(xiàn)得出來論文也好寫。這篇博客就基于一個完整跑通的畢業(yè)設(shè)計項目從選型、數(shù)據(jù)庫設(shè)計、后端接口、前端交互到論文和部署文檔把整個產(chǎn)出過程講透順便把那些只有動手做一遍才會踩到的坑一并列出來。1. 為什么畢設(shè)選“在線問卷調(diào)查系統(tǒng)”最不容易翻車1.1 一套系統(tǒng)串起三個技術(shù)棧的硬核考點很多人看到“問卷調(diào)查”四個字潛意識里覺得這就是個平平無奇的增刪改查項目。但實際上它比普通的管理系統(tǒng)多了好幾個值得深挖的技術(shù)點。第一問卷數(shù)據(jù)結(jié)構(gòu)天然是一對多、多對多的嵌套關(guān)系。一張問卷包含多道題目一道選擇題包含多個選項一份答卷對應(yīng)多條答案明細(xì)。這意味著你的表結(jié)構(gòu)必須拆開設(shè)計后端必須處理事務(wù)前端必須做動態(tài)渲染。第二題目類型是可擴(kuò)展的。單選、多選、填空、評分甚至矩陣題、下拉題每種題型在數(shù)據(jù)模型和前端渲染上都不同。這就逼著你把“題目類型”抽象成一種可枚舉、可擴(kuò)展的機(jī)制而不是在頁面上寫死。第三統(tǒng)計報表是項目的加分項。發(fā)布出去的問卷回收之后要能按題目維度做聚合分析畫餅圖、柱狀圖、評分分布圖。這部分同時考到MySQL的聚合查詢能力和前端可視化組件的使用。第四系統(tǒng)存在真實角色劃分。管理員創(chuàng)建問卷、發(fā)布問卷、查看答卷普通用戶登錄后填寫問卷、查看自己參與的記錄。有權(quán)限控制、有JWT認(rèn)證這正好補齊了Web應(yīng)用最基礎(chǔ)的安全設(shè)計。把這些點做完一套系統(tǒng)的技術(shù)棧覆蓋密度已經(jīng)很高了SpringBoot負(fù)責(zé)接口、事務(wù)、認(rèn)證鑒權(quán)Vue負(fù)責(zé)組件化、動態(tài)渲染、狀態(tài)管理MySQL負(fù)責(zé)表設(shè)計、索引、聚合統(tǒng)計。簡歷上寫“獨立完成問卷系統(tǒng)全棧開發(fā)”面試官不會覺得水。1.2 和其他熱門畢設(shè)題比優(yōu)劣勢在哪里每年畢設(shè)熱門題無非是學(xué)生管理系統(tǒng)、圖書管理系統(tǒng)、二手交易平臺、商城系統(tǒng)、博客系統(tǒng)。問卷系統(tǒng)跟它們比優(yōu)勢在于“動態(tài)性”。學(xué)生管理、圖書管理這類題目的數(shù)據(jù)模型非常固定學(xué)生表、圖書表、借閱表翻來覆去就是字段CRUD做完之后技術(shù)亮點不大論文里“系統(tǒng)設(shè)計”一章很難寫出花。商城系統(tǒng)和博客系統(tǒng)雖然功能多但需求邊界容易被自己擴(kuò)得很大做不完是常態(tài)。問卷系統(tǒng)的需求規(guī)模恰好處于中間位置說簡單它確實沒有支付、沒有秒殺說復(fù)雜它有動態(tài)表單、有嵌套數(shù)據(jù)結(jié)構(gòu)、有統(tǒng)計聚合、有重復(fù)提交防護(hù)。這個復(fù)雜度對于本科畢設(shè)來說剛剛好——不會因為功能太少被質(zhì)疑工作量也不會因為功能太多導(dǎo)致爛尾。1.3 想讓項目不“撞臉”這幾個差異化方向很好用基本版的問卷系統(tǒng)確實爛大街但只要加一兩個亮點就能讓項目在答辯時明顯拉開差距。我見過并且親測好用的方向有這幾種邏輯跳題根據(jù)用戶對上一題的答案決定下一題是否展示。這在前端是一個computed屬性條件渲染在后端是給題目增加“跳轉(zhuǎn)條件”字段實現(xiàn)成本不高但答辯時一說“支持智能問卷邏輯”老師印象分會上來。問卷模板復(fù)用把常用問卷保存為模板創(chuàng)建新問卷時一鍵導(dǎo)入。本質(zhì)是對問卷表做一個深拷貝代碼量不大但能體現(xiàn)設(shè)計深度。回收數(shù)據(jù)交叉分析比如“不同年齡段的用戶對某項功能的滿意度差異”本質(zhì)是兩個維度組合的GROUP BY查詢統(tǒng)計頁面用交叉表或堆疊柱狀圖展示。作答時長與回收率統(tǒng)計答卷表記錄作答耗時問卷列表展示發(fā)布后的回收率這些數(shù)據(jù)口徑可以讓論文的需求分析章節(jié)更豐滿。挑其中一個做進(jìn)去就夠不用貪多。重點是讓老師能指著某個頁面問“這個功能是怎么實現(xiàn)的”你能從頭到尾講明白。2. 架構(gòu)與數(shù)據(jù)庫設(shè)計ER圖之外的幾個關(guān)鍵決策2.1 技術(shù)選型版本定不對后面全是坑這套系統(tǒng)選用的技術(shù)棧是SpringBoot 2.7.x MyBatis-Plus MySQL 8.0 Vue 3 Vite Element Plus ECharts認(rèn)證用JWT。為什么SpringBoot選2.7而不是3.x核心原因是3.x要求JDK17并且包名從javax改成jakarta網(wǎng)上大量教程、博客、博客參考代碼都是基于2.x的。畢設(shè)本來時間就緊沒有必要在這種地方給自己增加排錯成本。JDK用8或者11都行我實測用JDK8配合SpringBoot 2.7.x最穩(wěn)啟動快、報錯少。MyBatis-Plus值得專門推薦一下。用原生MyBatis寫單表CRUD太啰嗦MyBatis-Plus提供了BaseMapper大部分增刪改查一行都不用寫XML只有統(tǒng)計報表這種復(fù)雜查詢才需要手寫SQL。對畢設(shè)來說這意味著你能把更多時間花在業(yè)務(wù)邏輯上而不是死在Mapper文件里。前端這邊如果你對Vue 2更熟用Vue 2 Element UI完全沒問題如果本來就打算學(xué)Vue 3那就直接上Vue 3 Vite Element Plus。我的建議是哪個熟用哪個別在畢設(shè)階段臨時切換大版本。Vite相比Webpack的優(yōu)勢是開發(fā)環(huán)境下秒級熱更新對調(diào)試問卷編輯器這種復(fù)雜交互幫助很大。MySQL推薦8.0。5.7雖然也夠用但8.0的窗口函數(shù)和更好的默認(rèn)字符集支持會讓統(tǒng)計SQL的寫法更舒服。安裝時字符集一定要選utf8mb4排序規(guī)則可以選utf8mb4_general_ci否則后面插入中文極容易變成問號。2.2 六張核心表每個字段都對應(yīng)一個明確的理由整個系統(tǒng)我拆成六張表用戶表、問卷表、題目表、選項表、答卷主表、答卷明細(xì)表。用戶表保存登錄賬號和角色信息。密碼字段必須存BCrypt加密后的密文絕對不能明文入庫。角色字段用tinyint0是管理員、1是普通用戶程序里用常量類或枚舉對應(yīng)。問卷表存問卷本身的基本信息。這里最值得關(guān)注的是status字段我建議用0草稿、1已發(fā)布、2已關(guān)閉三個狀態(tài)。為什么不用字符串因為tinyint在索引和比較上更高效程序里用一個枚舉類定義可讀性不會比字符串差。匿名標(biāo)記字段決定用戶填寫時是否需要登錄這個在需求分析階段就要確認(rèn)清楚。題目表和選項表是典型的父子表關(guān)系。題目表通過questionnaire_id關(guān)聯(lián)問卷sort_order控制題目在問卷中的排序type字段標(biāo)記題型。選項表通過question_id關(guān)聯(lián)題目同樣有sort_order。這里有一個我踩過坑的細(xì)節(jié)前端編輯器里需要一種本地臨時ID來標(biāo)識每道題不要直接拿數(shù)據(jù)庫主鍵當(dāng)唯一標(biāo)識否則新增題目還沒入庫時主鍵是空的排序和刪除時會出各種奇怪問題。答卷主表和答卷明細(xì)表負(fù)責(zé)回收數(shù)據(jù)。answer_record記錄“誰在什么時間填了哪份問卷”answer_detail記錄“這道題選了哪個選項或填了什么文本”。主從分離的原因很簡單如果每道題答案直接掛在records表的一行里統(tǒng)計“第5題選A的人有多少”時就只能用字符串匹配效率低且不優(yōu)雅。給一個精簡版的建表SQL片段CREATE TABLE questionnaire ( id BIGINT PRIMARY KEY AUTO_INCREMENT, title VARCHAR(100) NOT NULL COMMENT 問卷標(biāo)題, description VARCHAR(500) DEFAULT COMMENT 問卷說明, status TINYINT NOT NULL DEFAULT 0 COMMENT 0草稿 1已發(fā)布 2已關(guān)閉, anonymous TINYINT NOT NULL DEFAULT 0 COMMENT 0實名 1匿名, start_time DATETIME DEFAULT NULL, end_time DATETIME DEFAULT NULL, create_user_id BIGINT NOT NULL, create_time DATETIME DEFAULT CURRENT_TIMESTAMP, KEY idx_create_user_id (create_user_id), KEY idx_create_time (create_time) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT問卷表; CREATE TABLE question ( id BIGINT PRIMARY KEY AUTO_INCREMENT, questionnaire_id BIGINT NOT NULL, sort_order INT NOT NULL DEFAULT 0, type TINYINT NOT NULL COMMENT 1單選 2多選 3填空 4評分, title VARCHAR(255) NOT NULL COMMENT 題干, required TINYINT NOT NULL DEFAULT 1 COMMENT 是否必填, KEY idx_questionnaire_id (questionnaire_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT題目表;2.3 索引和唯一約束防重復(fù)提交的“免費保險”數(shù)據(jù)庫設(shè)計階段就要把索引和唯一約束想好不要等數(shù)據(jù)量大了再回頭加。answer_record表上有一個聯(lián)合唯一索引這是防止同一用戶重復(fù)提交問卷的關(guān)鍵手段CREATE TABLE answer_record ( id BIGINT PRIMARY KEY AUTO_INCREMENT, questionnaire_id BIGINT NOT NULL, user_id BIGINT NOT NULL, answer_time DATETIME NOT NULL, duration INT DEFAULT 0 COMMENT 作答耗時秒數(shù), ip VARCHAR(64) DEFAULT , UNIQUE KEY uk_questionnaire_user (questionnaire_id, user_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT答卷主表;這個唯一索引的妙處在于哪怕后端代碼里忘了做重復(fù)校驗數(shù)據(jù)庫層也會直接拒絕第二次插入。這屬于“防御性設(shè)計”答辯時老師問“怎么防止同一用戶反復(fù)提交”你就可以從應(yīng)用層校驗和數(shù)據(jù)庫約束兩個層面回答顯得考慮周全。統(tǒng)計查詢通常集中在answer_detail表上所以創(chuàng)建聯(lián)合索引(questionnaire_id, question_id)。配合唯一索引的record_id可以快速從明細(xì)表反查答卷主表。單選題的統(tǒng)計SQL長這樣SELECT qo.option_text, COUNT(ad.id) AS answer_count FROM answer_detail ad JOIN question_option qo ON ad.option_id qo.id WHERE ad.question_id #{questionId} GROUP BY ad.option_id, qo.option_text ORDER BY answer_count DESC;這里為什么一定要JOIN選項表因為answer_detail只存option_id沒有冗余option_text。如果直接按option_id分組統(tǒng)計結(jié)果里只有數(shù)字ID前端還得再做一次映射。JOIN選項表拿文本一次查詢直接得到“選項文本數(shù)量”前端組裝圖表數(shù)據(jù)就非常省事。多選統(tǒng)計稍微不同需要先對option_id做子查詢拆分因為一個答案記錄里可能存了多個選項ID我的做法是明細(xì)表每行只存一個選項ID多選題拆成多行插入統(tǒng)計邏輯就和單選完全一致了。3. SpringBoot后端接口設(shè)計、動態(tài)題型存儲和防重復(fù)提交3.1 接口清單圍繞業(yè)務(wù)的完整閉環(huán)后端接口設(shè)計遵循RESTful風(fēng)格按模塊劃分。整體可以分為認(rèn)證模塊、問卷管理模塊、答卷模塊、統(tǒng)計模塊。接口方法說明權(quán)限/api/auth/loginPOST登錄返回JWT公開/api/auth/registerPOST注冊公開/api/questionnairePOST創(chuàng)建問卷管理員/api/questionnaire/{id}PUT更新問卷管理員/api/questionnaire/{id}/publishPOST發(fā)布問卷管理員/api/questionnaireGET分頁查詢問卷列表登錄/api/questionnaire/{id}GET問卷詳情登錄/api/questionnaire/{id}/fill-infoGET獲取填寫頁數(shù)據(jù)登錄/api/answer/submitPOST提交答卷登錄/api/answer/recordsGET答卷列表管理員/api/questionnaire/{id}/statisticsGET統(tǒng)計結(jié)果管理員字段級別還要注意所有接口返回統(tǒng)一使用Result 結(jié)構(gòu)包含code、message、data三個字段。為什么要統(tǒng)一因為前端axios攔截器可以統(tǒng)一處理錯誤碼不用每個接口單獨寫try-catch。項目里再配一個全局異常處理器用RestControllerAdvice捕獲業(yè)務(wù)異常和系統(tǒng)異常返回給前端的就是規(guī)整的JSON錯誤信息。3.2 動態(tài)題型如何入庫先刪后插的事務(wù)策略問卷編輯器最終提交上來的是一個嵌套JSON結(jié)構(gòu)問卷包含題目列表題目包含選項列表。這也是前后端聯(lián)調(diào)時最容易出問題的地方。我的處理思路是后端定義QuestionnaireCreateDTO內(nèi)部包含List QuestionDTO內(nèi)部包含List 。Controller收到之后直接在Service層完成拆解入庫。這里有一個很重要的策略更新問卷時不要去做復(fù)雜的Diff對比直接用“先刪后插”。也就是在同一個事務(wù)里先把該問卷下的舊題目和舊選項全部物理刪除再按照提交上來的最新結(jié)構(gòu)重新插入。好處是邏輯極其清晰不存在“哪些題目沒變、哪些選項要保留”的繁瑣判斷代碼量小且不容易出Bug。但先刪后插有個前提——同一份問卷如果已經(jīng)有用戶提交了答卷刪除題目會導(dǎo)致歷史答卷明細(xì)失去關(guān)聯(lián)。所以我的做法是問卷在草稿狀態(tài)下允許自由編輯一旦有答卷記錄就提示管理員必須先關(guān)閉問卷或創(chuàng)建新問卷。這個限制在業(yè)務(wù)上也說得通問卷發(fā)布后不允許改題否則統(tǒng)計口徑就亂了。答辯時把這個規(guī)則講出來老師會覺得你有業(yè)務(wù)思維。核心代碼大致是這樣Transactional public Long createOrUpdateQuestionnaire(QuestionnaireCreateDTO dto) { Questionnaire questionnaire new Questionnaire(); questionnaire.setTitle(dto.getTitle()); questionnaire.setDescription(dto.getDescription()); questionnaire.setStatus(0); questionnaireMapper.insert(questionnaire); if (CollectionUtils.isEmpty(dto.getQuestions())) { throw new BizException(問卷至少需要一道題目); } for (QuestionDTO q : dto.getQuestions()) { Question question new Question(); question.setQuestionnaireId(questionnaire.getId()); question.setType(q.getType()); question.setTitle(q.getTitle()); question.setRequired(q.getRequired()); question.setSortOrder(q.getSortOrder()); questionMapper.insert(question); if (q.getType() QuestionType.RADIO.getCode() || q.getType() QuestionType.CHECKBOX.getCode()) { if (CollectionUtils.isEmpty(q.getOptions()) || q.getOptions().size() 2) { throw new BizException(選擇題至少需要兩個選項); } for (OptionDTO o : q.getOptions()) { QuestionOption option new QuestionOption(); option.setQuestionId(question.getId()); option.setOptionText(o.getOptionText()); option.setSortOrder(o.getSortOrder()); optionMapper.insert(option); } } } return questionnaire.getId(); }注意Transactional注解它保證了問卷表、題目表、選項表的寫入要么全部成功要么全部回滾。如果少了事務(wù)可能出現(xiàn)“問卷建好了但題目沒插進(jìn)去”這種臟數(shù)據(jù)而且極難排查。把事務(wù)、校驗、異常處理三者組合好后端核心邏輯就已經(jīng)完成了大半。3.3 提交答卷匿名與實名場景下的冪等設(shè)計提交答卷是整個系統(tǒng)并發(fā)壓力最高的入口也是數(shù)據(jù)一致性要求最嚴(yán)格的模塊。流程拆解為四步第一步校驗問卷存在且狀態(tài)為已發(fā)布第二步校驗用戶是否已經(jīng)提交過如果提交過直接返回提示第三步插入answer_record獲得主鍵ID第四步遍歷答案列表逐條插入answer_detail。防止重復(fù)提交的最終防線是數(shù)據(jù)庫聯(lián)合唯一索引但代碼里同樣要寫判斷。為什么兩處都要做因為應(yīng)用層的查詢和插入之間存在時間窗口兩個并發(fā)請求可能同時通過“是否提交過”的校驗然后同時插入成功。此時唯一索引會攔住其中一個讓它拋出DuplicateKeyException。把這個異常捕獲后轉(zhuǎn)成“您已提交過該問卷”的友好提示系統(tǒng)就穩(wěn)了。如果問卷開啟了匿名模式就沒有user_id可用了可以用IP地址瀏覽器指紋User-Agent組合作為標(biāo)識或者干脆不做一人一次限制只記錄IP。這塊取舍要在論文里寫清楚實名問卷強(qiáng)約束匿名問卷弱約束。答案明細(xì)的統(tǒng)一數(shù)據(jù)模型設(shè)計也很關(guān)鍵。明細(xì)表同時保留option_id和answer_text兩個字段單選/多選題寫option_id填空題寫answer_text評分題兩個都用上。這樣一張表就能兼容所有題型統(tǒng)計和導(dǎo)出都方便。3.4 權(quán)限控制JWT要比Spring Security更適合畢設(shè)很多同學(xué)一聽權(quán)限設(shè)計就想到Spring Security然后被它的過濾器鏈和配置類折磨一整天。我的建議是畢設(shè)階段完全可以不用Spring Security用簡單的JWT攔截器方案就夠了代碼量小邏輯自己完全可控。具體做法是登錄成功生成一個token里面放入userId、username、role密鑰放在配置文件里后端寫一個AuthInterceptor實現(xiàn)HandlerInterceptor接口在preHandle方法中解析請求頭里的Authorization字段校驗token有效性然后把當(dāng)前登錄用戶信息放進(jìn)ThreadLocal。這樣Controller層通過UserContext.getUserId()就能拿到當(dāng)前用戶不用每個接口都從參數(shù)里傳userId。管理端接口再通過自定義注解加一個角色判斷比如RequireRole(Admin)在攔截器里校驗角色是否符合。這套方案在答辯時可以理直氣壯地解釋為“基于JWT的無狀態(tài)認(rèn)證配合攔截器實現(xiàn)接口粒度權(quán)限控制”而且面試官問起來你對每一行代碼都是清楚的不會被幾個Security配置類問住。4. Vue前端問卷編輯器、動態(tài)渲染和統(tǒng)計圖表的實現(xiàn)思路4.1 前端工程結(jié)構(gòu)按模塊拆組件避免單文件失控前端設(shè)計很容易出現(xiàn)一個誤區(qū)把問卷編輯器所有功能堆在一個組件里寫了兩千行還在繼續(xù)加。正確的做法是先把工程結(jié)構(gòu)按職責(zé)拆好。我的項目結(jié)構(gòu)大致是這樣src/ api/ # axios請求模塊 router/ # 路由配置 store/ # Pinia狀態(tài)管理 views/ login.vue # 登錄頁 admin/ QuestionnaireList.vue # 問卷列表 QuestionnaireEdit.vue # 問卷編輯器 Statistics.vue # 統(tǒng)計圖表頁 fill/ FillQuestionnaire.vue # 用戶填寫頁 components/ editor/ # 編輯器相關(guān)組件 QuestionPanel.vue # 左側(cè)題庫面板 CanvasPanel.vue # 中間畫布 PropertyPanel.vue # 右側(cè)屬性面板 answer/ # 填寫頁動態(tài)組件 RadioQuestion.vue CheckboxQuestion.vue TextQuestion.vue RateQuestion.vue這樣拆分的好處是問卷編輯器的三欄布局各司其職新增一種題型時只需要在編輯器的題庫面板加一個入口、新建一個answer組件其他部分不需要大改。這種可擴(kuò)展性在論文的“系統(tǒng)詳細(xì)設(shè)計”章節(jié)可以直接作為設(shè)計亮點寫進(jìn)去。4.2 編輯器三欄布局左側(cè)題庫、中間畫布、右側(cè)屬性問卷編輯器是整個前端最難寫的部分我當(dāng)時花了整整兩天才把交互理順。核心布局是左側(cè)題庫面板、中間畫布、右側(cè)屬性面板。數(shù)據(jù)模型使用一個響應(yīng)式的問卷對象const questionnaire reactive({ title: , description: , questions: [] })每道題在前端模型里包含本地id、題型、題干、是否必填、選項列表。本地id用uuid或Date.now()生成在和數(shù)據(jù)庫主鍵區(qū)分開的同時保證每道題在拖拽排序、刪除時都能被準(zhǔn)確找到。中間畫布的題目排序推薦使用vuedraggable組件拖拽完成后重新計算每道題的sortOrder。這里有一個容易忽略的細(xì)節(jié)拖拽的是題目在數(shù)組中的順序保存時要把數(shù)組索引作為sortOrder傳給后端否則刷新頁面后題目順序就亂了。右側(cè)屬性面板負(fù)責(zé)配置選中題目的屬性選項文本增刪、是否必填、題目類型切換。當(dāng)選中的題目類型切換時要注意清空選項列表否則會出現(xiàn)“單選題變成多選題但老選項還留著”的奇怪狀態(tài)。編輯器的整個狀態(tài)都保存在前端只有點擊“保存問卷”時才提交到后端。為什么這樣設(shè)計因為編輯過程是高頻率交互每動一下都請求后端不僅慢還會讓數(shù)據(jù)庫負(fù)載變大而且草稿狀態(tài)的編輯本來就不需要實時持久化。4.3 填寫頁動態(tài)渲染用組件映射處理所有題型填寫頁是所有普通用戶真正交互的頁面核心需求是根據(jù)題型動態(tài)渲染對應(yīng)控件。實現(xiàn)方式不復(fù)雜遍歷問卷詳情里的questions數(shù)組用component動態(tài)組件根據(jù)type渲染不同子組件。component :iscomponentMap[question.type] :questionquestion :model-valueanswers[question.id] update:model-valueanswers[question.id] $event /componentMap是一個對象映射key是題型編碼value是對應(yīng)的組件。這樣新增一種題型只需要注冊一個新的組件不用在頁面里堆一堆v-if。填寫頁的數(shù)據(jù)收集要特別注意用一個普通對象answers來保存所有題目的答案key是題目idvalue根據(jù)不同題型分別是單個選項ID、數(shù)組、字符串或數(shù)字。提交時再組裝成后端要求的格式。這塊前后端字段如果沒有對齊聯(lián)調(diào)階段會浪費大量時間我的經(jīng)驗是先寫接口文檔再動手寫代碼哪怕是只有自己能看的簡易文檔也比邊寫邊猜強(qiáng)。問卷填寫頁還需要處理一個邏輯跳題的場景比如用戶選了“否”后面兩道滿意度題就不應(yīng)該展示。這個可以在組件樹外層套一個v-if根據(jù)所在題目的跳題條件和當(dāng)前答案對象實時計算是否渲染。不要試圖改題目數(shù)組本身只控制顯示與否這樣答案對象的數(shù)據(jù)結(jié)構(gòu)始終穩(wěn)定。4.4 統(tǒng)計圖表數(shù)據(jù)結(jié)構(gòu)和ECharts的組裝技巧統(tǒng)計模塊是讓項目“看起來高級”的關(guān)鍵頁面。后端返回每個題目的統(tǒng)計結(jié)構(gòu)前端統(tǒng)一渲染。對于單選題后端返回的數(shù)據(jù)格式是{ questionId: 1, type: 1, title: 您的年齡段, options: [ { optionText: 00后, answerCount: 23 }, { optionText: 90后, answerCount: 45 } ] }前端拿到這個結(jié)構(gòu)直接組裝成ECharts餅圖的data數(shù)組chartData.value data.options.map(item ({ name: item.optionText, value: item.answerCount }))多選題的統(tǒng)計結(jié)果類似只是總數(shù)可能大于答卷總數(shù)。評分題我習(xí)慣用兩個圖表一個柱狀圖展示各分?jǐn)?shù)人數(shù)分布一個直接顯示平均分大數(shù)字視覺效果很好。用ECharts有三個容易踩的坑第一圖表容器必須有顯式高度否則render不會出圖第二組件卸載時務(wù)必調(diào)用chart.dispose()否則路由切換會導(dǎo)致內(nèi)存泄漏控制臺會報“ResizeObserver loop”警告第三圖表數(shù)據(jù)是異步獲取的容器要先渲染出來再初始化圖表否則寬度為0圖表會擠成一團(tuán)。我的解決方案是在拿到數(shù)據(jù)后用nextTick再調(diào)用setOption。5. 論文和部署文檔源碼之外那50%的畢設(shè)工作量5.1 論文結(jié)構(gòu)怎么安排才能避開“說明書”差評論文是畢業(yè)設(shè)計評分的重頭戲很多項目源代碼寫得不錯論文卻被批“像用戶手冊”原因就是只會貼截圖和代碼。標(biāo)準(zhǔn)的論文結(jié)構(gòu)是摘要、緒論、相關(guān)技術(shù)介紹、需求分析、系統(tǒng)設(shè)計、系統(tǒng)實現(xiàn)、系統(tǒng)測試、總結(jié)展望。需求分析部分不要只寫“用戶需要登錄后創(chuàng)建問卷”要配合用例圖和用例描述表格至少寫出管理員、普通用戶兩類角色的完整用例。系統(tǒng)設(shè)計部分畫系統(tǒng)架構(gòu)圖、功能模塊圖、數(shù)據(jù)庫ER圖加上核心表結(jié)構(gòu)的說明。系統(tǒng)實現(xiàn)部分挑三四個核心業(yè)務(wù)流程展開比如問卷創(chuàng)建流程、答卷提交流程、統(tǒng)計報表流程配核心代碼片段和運行截圖其他普通功能一筆帶過。最容易拿分的其實是系統(tǒng)測試章節(jié)。寫一份功能測試用例表列出用例編號、測試場景、操作步驟、預(yù)期結(jié)果、實際結(jié)果、是否通過表格做到二十條以上。老師一看就知道你確實跑過完整測試而不是寫完代碼就扔那兒了。論文里不建議大段貼SQL更不建議把整個Controller源碼復(fù)制進(jìn)去。只需要把關(guān)鍵設(shè)計思路、核心代碼片段、方法時序邏輯講清楚就行。論文的意義是證明你理解這個系統(tǒng)是怎么運轉(zhuǎn)的不是證明你會用CtrlC。5.2 部署文檔要寫什么照著這個清單做就能跑起來部署文檔是很多同學(xué)最后才補的東西但如果你打算把項目掛到簡歷或者GitHub上這一步寫好了會非常加分。我的部署文檔內(nèi)容包括五部分。第一環(huán)境版本清單明確寫出JDK、Maven、Node、MySQL、Nginx的版本號。第二數(shù)據(jù)庫初始化步驟告訴讀者執(zhí)行哪個sql腳本以及application.yml里的數(shù)據(jù)源配置該怎么改。第三后端打包運行mvn clean package生成jar包再用java -jar啟動。第四前端構(gòu)建npm install、npm run build生成dist目錄。第五Nginx配置把dist目錄作為網(wǎng)站根目錄并把接口請求反向代理到后端。一個標(biāo)準(zhǔn)的Nginx配置片段是這樣server { listen 80; server_name your-domain.com; root /opt/questionnaire-front/dist; index index.html; location / { try_files $uri $uri/ /index.html; } location /prod-api/ { proxy_pass http://127.0.0.1:8080/; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } }location /里的try_files配置必須寫否則Vue路由開啟history模式后刷新頁面會404。這個問題很多人部署完才發(fā)現(xiàn)其實就是Nginx不知道前端路由應(yīng)該回退到index.html。5.3 演示視頻和PPT的準(zhǔn)備思路答辯演示順序建議是登錄演示→創(chuàng)建問卷現(xiàn)場添加單選、多選、填空、評分幾類題目→發(fā)布問卷→用另一個測試賬號填寫問卷→管理員查看答卷列表→查看統(tǒng)計圖表頁面。整個過程控制在八分鐘以內(nèi)錄屏?xí)r字體盡量放大操作速度放慢。PPT控制在10到12頁。第一頁是題目和基本信息第二頁講選題背景和意義第三頁是需求分析第四頁是系統(tǒng)總體架構(gòu)第五頁是數(shù)據(jù)庫設(shè)計第六到第八頁放核心功能截圖第九頁是系統(tǒng)測試情況第十頁是總結(jié)與展望。別把PPT做成代碼展示會頁面里不要貼大段代碼老師看PPT的時間很短只會關(guān)注截圖和關(guān)鍵詞。6. 實測踩坑記錄從環(huán)境搭建到答辯現(xiàn)場的高頻問題6.1 環(huán)境與部署常見的坑附解決方案這些坑我全部親自踩過列出來給后面做的人省點時間?，F(xiàn)象原因解決辦法后端啟動報Communications link failureMySQL服務(wù)沒啟動或連接地址/賬號密碼配錯先確認(rèn)MySQL能連上再檢查jdbc url和密碼連接MySQL報時區(qū)錯誤JDBC連接串缺少serverTimezoneurl加上?serverTimezoneAsia/ShanghaiuseSSLfalse插入中文變成問號庫表字符集不是utf8mb4建庫時指定DEFAULT CHARSETutf8mb4前端請求后端跨域報錯前后端端口不同后端配置CorsFilter或Nginx反向代理同源訪問Vue打包后刷新404history路由模式?jīng)]有服務(wù)端支持Nginx加try_files配置或改用hash模式npm install執(zhí)行很慢默認(rèn)源在國外配置npm淘寶鏡像源再執(zhí)行install跨域問題多說一句。開發(fā)環(huán)境下我用后端CorsFilter解決生產(chǎn)環(huán)境用Nginx反代。如果你直接用Vite的proxy代理前端請求路徑也要統(tǒng)一加前綴。前后端聯(lián)調(diào)時最怕的就是“一會兒能通一會兒不能通”根源往往是CORS配置和代理配置混用。6.2 答辯老師最愛問的問題提前準(zhǔn)備好答案整理幾個我統(tǒng)計過的高頻問題附上參考回答思路?！盀槭裁催xMySQL不選Oracle”回答要點MySQL開源免費社區(qū)資料豐富安裝維護(hù)成本低對于本系統(tǒng)量級的數(shù)據(jù)性能和穩(wěn)定性已經(jīng)完全夠用。Oracle更強(qiáng)的地方在于企業(yè)級分布式場景但學(xué)習(xí)和部署成本都更高不適合作為畢設(shè)選題的主要數(shù)據(jù)庫?！叭绻麛?shù)據(jù)量大系統(tǒng)怎么擴(kuò)展”回答要點分層次回答。首先是索引優(yōu)化所有查詢字段都建索引其次是加Redis緩存熱點問卷和統(tǒng)計結(jié)果如果單表數(shù)據(jù)量真的大到千萬級可以采用分表分庫和數(shù)據(jù)歸檔策略。畢設(shè)階段做到前兩步就完全夠講。“題目類型怎么擴(kuò)展”回答要點后端新增type枚舉值前端新增對應(yīng)的動態(tài)渲染組件問卷編輯器題庫面板加一個入口校驗規(guī)則再補上。因為系統(tǒng)設(shè)計時已經(jīng)通過type字段和動態(tài)組件做了解耦加題型不需要改主體流程。“同一用戶重復(fù)提交怎么辦”回答要點應(yīng)用層在提交接口里查詢是否已存在答卷記錄數(shù)據(jù)庫層再用聯(lián)合唯一索引兜底出現(xiàn)DuplicateKeyException統(tǒng)一捕獲并提示。兩條防線同時生效。“項目如何防SQL注入”回答要點使用MyBatis-Plus的參數(shù)占位符機(jī)制所有SQL參數(shù)都是預(yù)編譯綁定杜絕字符串拼接。前端使用編碼組件進(jìn)行用戶輸入內(nèi)容轉(zhuǎn)碼防止XSS攻擊。6.3 讓老師打分更高的代碼規(guī)范加分項代碼規(guī)范屬于隱性評分點很多項目功能完整但分?jǐn)?shù)上不去問題往往出在這一塊。統(tǒng)一返回結(jié)果類。所有接口不要直接返回Map或者裸數(shù)據(jù)統(tǒng)一用Result 包裹Controller層代碼會清爽很多前端axios攔截器也容易做統(tǒng)一處理。全局異常處理器。用RestControllerAdvice注解寫一個GlobalExceptionHandler把業(yè)務(wù)異常NotFoundException、參數(shù)異常MethodArgumentNotValidException分別處理。這樣Controller里只用寫正常流程異常全部拋出去由全局處理器兜底。Service接口加實現(xiàn)類。Controller只負(fù)責(zé)接收參數(shù)和調(diào)用Service業(yè)務(wù)邏輯全部在Service實現(xiàn)里。像單表CRUD的項目不需要這么講究但問卷系統(tǒng)的題目保存、答卷提交這種業(yè)務(wù)復(fù)雜邏輯拆接口實現(xiàn)是合理的。參數(shù)校驗用注解。DTO字段上用NotBlank、NotNull、Size注解Controller方法參數(shù)加Validated。至少占比很重的“參數(shù)校驗”在論文里能寫成一節(jié)?？紤]到時間是有限的這里給一個明確的項目時間規(guī)劃參考數(shù)據(jù)庫設(shè)計1天后端核心接口3天前端管理端3天前端填寫頁加統(tǒng)計2天測試修Bug2天論文撰寫4天部署文檔加演示錄制1天。整體節(jié)奏控制在三周左右留出足夠緩沖時間應(yīng)對突發(fā)情況。最后分享一點個人體會。做這種畢業(yè)設(shè)計系統(tǒng)真正拉開差距的不是堆功能數(shù)量而是面對“為什么這么做”的問題時你能不能從表結(jié)構(gòu)、事務(wù)、索引、組件拆分這些具體決策開始講起一直講到業(yè)務(wù)閉環(huán)。我在做完這個問卷系統(tǒng)之后最明顯的感受是SpringBoot和Vue并不是被“用”會的而是被一個個真實問題逼著“查”會的。每當(dāng)遇到一個之前沒見過的報錯解決之后把原因記下來這些東西比項目本身值錢得多。希望這份完整的拆解過程能讓正在做同類題目的你少走幾條彎路。