最近剛把一個(gè)基于Java Web的工藝品展示系統(tǒng)做完從需求梳理到數(shù)據(jù)庫(kù)設(shè)計(jì)再到最后的部署上線前后改了三版。這個(gè)題目乍一看就是個(gè)普通的信息管理系統(tǒng)但真正動(dòng)手才發(fā)現(xiàn)手工藝品展示跟普通商品展示完全是兩碼事——它既要展示工藝細(xì)節(jié)又要有創(chuàng)作者與參觀者之間的交流討論還得有一套作品評(píng)價(jià)機(jī)制。這篇文章就把整個(gè)基于B/S架構(gòu)的手工藝品在線展示與交流平臺(tái)的設(shè)計(jì)思路、核心代碼邏輯、部署細(xì)節(jié)和踩坑記錄完整拆一遍不管是正在做畢業(yè)設(shè)計(jì)的學(xué)生還是想快速搭建一個(gè)作品展示類網(wǎng)站的同學(xué)都能直接照著參考。1. 項(xiàng)目定位與核心需求拆解1.1 這個(gè)系統(tǒng)到底在解決什么問題先明確一點(diǎn)這個(gè)系統(tǒng)不是電商系統(tǒng)不涉及到交易、庫(kù)存、支付它的核心就是“展示”和“交流”。手工藝品行業(yè)有個(gè)很特殊的地方作品的視覺呈現(xiàn)方式很重要同一個(gè)陶瓷杯不同角度拍出來(lái)質(zhì)感完全不同而且購(gòu)買或收藏之前用戶往往希望看到創(chuàng)作者本人對(duì)工藝過程的講述甚至和其他愛好者聊一聊這件作品好在哪、瑕疵在哪。所以這個(gè)基于B/S架構(gòu)的工藝品展示系統(tǒng)本質(zhì)上要做三件事作品展示、在線交流、評(píng)價(jià)管理。展示是指把作品圖片、工藝說明、創(chuàng)作者信息組織成一個(gè)清晰好看的信息流交流是指用戶可以對(duì)作品發(fā)表評(píng)論、提問或回復(fù)創(chuàng)作者可以回答評(píng)價(jià)管理則是一套規(guī)則讓用戶給作品打分系統(tǒng)根據(jù)分?jǐn)?shù)形成口碑?dāng)?shù)據(jù)。從畢業(yè)設(shè)計(jì)的角度來(lái)說這個(gè)題目屬于典型的“Java Web 傳統(tǒng)管理信息系統(tǒng)”范疇但因?yàn)樗尤肓擞脩艋?dòng)、權(quán)限控制、圖片上傳、數(shù)據(jù)統(tǒng)計(jì)這些元素比普通CRUD系統(tǒng)更有層次也比較容易在答辯時(shí)講出亮點(diǎn)。1.2 需求拆解展示、交流、評(píng)價(jià)三條主線我習(xí)慣把需求按角色來(lái)拆。系統(tǒng)里主要有四類角色游客、注冊(cè)用戶、創(chuàng)作者、管理員。不同角色看到的功能完全不一樣這也是系統(tǒng)設(shè)計(jì)里最核心的點(diǎn)。游客瀏覽首頁(yè)、按分類查看作品、查看作品詳情和評(píng)論但不能點(diǎn)贊、不能評(píng)價(jià)、不能發(fā)評(píng)論。這里要留意游客也是目標(biāo)用戶不能把所有頁(yè)面都鎖上否則搜索引擎和初次訪問的人什么都看不到項(xiàng)目演示時(shí)也顯得很單薄。注冊(cè)用戶游客注冊(cè)登錄后可以評(píng)論作品、給作品評(píng)分、收藏作品也可以修改個(gè)人資料。這里有一個(gè)重要設(shè)計(jì)決定注冊(cè)用戶不等于創(chuàng)作者普通用戶想要發(fā)布作品需要額外申請(qǐng)成為創(chuàng)作者或者由管理員在后臺(tái)把角色改成創(chuàng)作者。這樣做的好處是權(quán)限邊界清楚系統(tǒng)不會(huì)出現(xiàn)“人人都能上傳作品”的混亂狀態(tài)。創(chuàng)作者在注冊(cè)用戶能力的基礎(chǔ)上可以發(fā)布新作品、編輯自己的作品、下架作品還可以回復(fù)別人對(duì)自己作品的評(píng)論。創(chuàng)作者只能管理自己的作品不能動(dòng)別人的這一點(diǎn)在后端校驗(yàn)時(shí)一定要寫清楚。管理員負(fù)責(zé)用戶管理、分類管理、作品審核、評(píng)論審核、數(shù)據(jù)統(tǒng)計(jì)。因?yàn)樽髌芬唤?jīng)發(fā)布就對(duì)外開放必須有審核環(huán)節(jié)否則有人上傳違規(guī)圖片或者垃圾信息整場(chǎng)答辯演示就尷尬了。這三條主線相互交叉就構(gòu)成了系統(tǒng)的完整功能網(wǎng)游客逛展、用戶交流、創(chuàng)作者發(fā)布、管理員審核。整個(gè)數(shù)據(jù)庫(kù)設(shè)計(jì)和模塊開發(fā)都圍繞這個(gè)功能網(wǎng)展開。1.3 為什么選B/S架構(gòu)而不是C/S架構(gòu)先給結(jié)論對(duì)于這種“以瀏覽瀏覽為主、沒有任何高實(shí)時(shí)性要求”的系統(tǒng)B/S架構(gòu)是最合理的選擇。瀏覽器做客戶端用戶不用裝任何軟件打開網(wǎng)址就能用這對(duì)展示類項(xiàng)目來(lái)說體驗(yàn)最優(yōu)。從技術(shù)層面看C/S架構(gòu)通常需要專門開發(fā)客戶端比如C# WinForm或者Java Swing程序部署時(shí)每臺(tái)電腦都要裝客戶端升級(jí)版本還得逐個(gè)更新。而B/S架構(gòu)把業(yè)務(wù)邏輯和數(shù)據(jù)處理都集中在服務(wù)器端客戶端只負(fù)責(zé)渲染和交互所有的升級(jí)只需要在服務(wù)器上改一次用戶刷新頁(yè)面就能看到新效果。再考慮到畢業(yè)設(shè)計(jì)的演示場(chǎng)景答辯現(xiàn)場(chǎng)往往只有一臺(tái)電腦老師可能還會(huì)讓你在另一臺(tái)電腦上打開網(wǎng)址測(cè)試。如果是B/S架構(gòu)只要啟動(dòng)Tomcat或者其他容器局域網(wǎng)內(nèi)任何一臺(tái)電腦的瀏覽器都能訪問。而C/S架構(gòu)你需要考慮客戶端依賴、環(huán)境變量、JDK版本匹配等等非常折騰。用Java來(lái)實(shí)現(xiàn)B/S架構(gòu)還有一個(gè)隱含優(yōu)勢(shì)Java的Servlet規(guī)范天然就是為了Web服務(wù)設(shè)計(jì)的Spring Boot這種框架更是把部署簡(jiǎn)化到“打一個(gè)包、跑一條命令”。從項(xiàng)目復(fù)雜度來(lái)看一個(gè)工藝品展示系統(tǒng)屬于中小型Web應(yīng)用用B/S架構(gòu)不會(huì)遇到明顯的性能瓶頸反而是最穩(wěn)妥的選擇。2. 技術(shù)選型與方案設(shè)計(jì)2.1 Java技術(shù)棧Servlet/JSP還是Spring Boot這是很多畢業(yè)設(shè)計(jì)同學(xué)第一道坎。如果你的課程還在講JSP、Servlet老師也明確要求寫ServletJSPTomcat那你就按傳統(tǒng)方式做。但說實(shí)話現(xiàn)在企業(yè)里寫Java Web再用純粹的JSP已經(jīng)很少了Spring Boot已經(jīng)是絕對(duì)的主流。如果你不想在答辯時(shí)被問“為什么不用Spring Boot”建議直接用Spring Boot。選型理由很簡(jiǎn)單開發(fā)效率高。Spring Boot內(nèi)置Tomcat不用單獨(dú)配置一堆XML一個(gè)可執(zhí)行的jar包就能跑起來(lái)。生態(tài)成熟。接入MyBatis/JPA、Spring MVC、Spring Security都很方便社區(qū)資料多報(bào)錯(cuò)基本都能搜到。分層清晰。Controller、Service、Mapper分得明明白白評(píng)委一看代碼結(jié)構(gòu)就知道你懂分層架構(gòu)。方便擴(kuò)展。如果之后想加REST API給手機(jī)端用Spring Boot稍微改造就能做到。數(shù)據(jù)庫(kù)選型上用MySQL這是最經(jīng)典的搭配。如果你所在學(xué)校的環(huán)境是Oracle或者SQLServer也沒問題但MySQL的開源特性和常用性更適合學(xué)生項(xiàng)目而且云服務(wù)器上裝MySQL也容易。前端的做法我推薦兩種取決于你的邊界能力如果精力有限就用Thymeleaf模板引擎做服務(wù)端渲染頁(yè)面里寫HTML加模板語(yǔ)法后端把數(shù)據(jù)填充到Model里前端直接渲染如果你愿意多花點(diǎn)時(shí)間也可以做前后端分離后端提供JSON接口前端用Vue框架這樣技術(shù)含量更高項(xiàng)目文件夾里前后端分開看起來(lái)更專業(yè)。我在這個(gè)項(xiàng)目里選的是Spring Boot MyBatis MySQL Thymeleaf。原因很簡(jiǎn)單畢業(yè)設(shè)計(jì)周期有限Thymeleaf開發(fā)速度比Vue更快而且不需要在答辯現(xiàn)場(chǎng)解釋跨域和代理問題。2.2 后端層次架構(gòu)設(shè)計(jì)思路后端不要圖省事把所有業(yè)務(wù)邏輯都堆在Controller里一定要分層。標(biāo)準(zhǔn)的分層是Controller層負(fù)責(zé)接口接收和響應(yīng)Service層負(fù)責(zé)業(yè)務(wù)邏輯處理Mapper層負(fù)責(zé)數(shù)據(jù)庫(kù)操作。另外再補(bǔ)兩個(gè)包pojo/entity放實(shí)體類vo/dto放接收前端參數(shù)和返回?cái)?shù)據(jù)的對(duì)象。以一個(gè)具體場(chǎng)景為例用戶給作品打5分并寫了一條評(píng)論后端要做幾件事校驗(yàn)用戶是否登錄校驗(yàn)作品是否存在判斷該用戶是否已經(jīng)評(píng)論過這個(gè)作品如果同一個(gè)用戶對(duì)同一作品多次評(píng)價(jià)會(huì)造成惡意刷分插入評(píng)論記錄4. 更新作品的平均分5. 把作品熱度加一。這五步如果全寫在Controller里代碼會(huì)膨脹得很難看而且事務(wù)不好控制。放到Service層用一個(gè)方法把所有數(shù)據(jù)層操作包在一個(gè)事務(wù)里任何一步出錯(cuò)都能整體回滾數(shù)據(jù)不會(huì)出現(xiàn)“評(píng)論加了但評(píng)分沒更新”的情況。再比如權(quán)限校驗(yàn)系統(tǒng)里有游客、注冊(cè)用戶、創(chuàng)作者、管理員四種角色。最簡(jiǎn)單的方式是寫一個(gè)登錄攔截器在Controller之前判斷Session中是否有用戶再針對(duì)創(chuàng)作者后臺(tái)單獨(dú)加一個(gè)角色判斷。如果接口用Spring Security做整體權(quán)限控制初學(xué)的復(fù)雜度會(huì)上升。我建議用HandlerInterceptor或者AOP來(lái)攔截代碼少也容易理解。2.3 前端頁(yè)面與數(shù)據(jù)交互方案頁(yè)面組織上我按“首頁(yè)、分類列表、作品詳情、創(chuàng)作者后臺(tái)、用戶中心、管理后臺(tái)”這幾塊來(lái)做。首頁(yè)放輪播圖推薦位、熱門作品和最新作品分類頁(yè)支持側(cè)邊欄篩選作品詳情頁(yè)則把圖片、簡(jiǎn)介、評(píng)分、創(chuàng)作者信息、評(píng)論區(qū)全部放在一個(gè)頁(yè)面上。因?yàn)橛玫氖荰hymeleaf數(shù)據(jù)交互很簡(jiǎn)單Controller返回視圖名和Model數(shù)據(jù)模板里用th:each遍歷作品列表用th:href拼接詳情URL分頁(yè)時(shí)把頁(yè)碼和分類id作為查詢參數(shù)。像這樣div th:eachwork : ${page.list} a th:href{/work/detail(id${work.id})} img th:src${work.coverImage} alt封面 /a h3 th:text${work.title}作品標(biāo)題/h3 span th:text${work.avgScore}綜合評(píng)分/span /div要注意的幾個(gè)點(diǎn)圖片鏈接不要存絕對(duì)路徑要存相對(duì)路徑這樣項(xiàng)目挪到別的機(jī)器上也不受影響評(píng)論區(qū)的提交和回復(fù)可以用表單POST提交局部刷新用JS請(qǐng)求后端接口但不必引入太重的前端框架。如果你選擇前后端分離后端只需要返回JSON前端用axios調(diào)用頁(yè)面渲染交給Vue。那就要額外處理跨域一般用CrossOrigin注解或者在配置類里加CORS配置。我這次不用跨域反而省了很多排查時(shí)間。3. 數(shù)據(jù)庫(kù)設(shè)計(jì)核心表結(jié)構(gòu)與字段解析3.1 用戶、作品、評(píng)價(jià)三大核心表表結(jié)構(gòu)設(shè)計(jì)是整個(gè)項(xiàng)目的地基。我一開始設(shè)計(jì)得比較粗只有用戶表和作品表后來(lái)越開發(fā)越發(fā)現(xiàn)缺表、缺字段返工了好幾次。正確的做法是先畫ER圖把每個(gè)角色的操作路徑走一遍再落表。用戶表t_user核心字段id主鍵自增username登錄賬號(hào)唯一索引password加密后的密碼nickname昵稱頁(yè)面顯示使用role角色0游客/1用戶/2創(chuàng)作者/3管理員avatar頭像路徑phone/email聯(lián)系方式create_time注冊(cè)時(shí)間作品表t_work核心字段id主鍵title作品名稱description作品描述用TEXT類型記錄工藝說明、創(chuàng)作故事cover_image封面圖路徑images多圖列表存JSON數(shù)組字符串例如[/upload/1.jpg,/upload/2.jpg]category_id分類iduser_id創(chuàng)作者idstatus審核狀態(tài)0待審核/1已通過/2已下架/3審核駁回view_count瀏覽量點(diǎn)贊/收藏量可以單獨(dú)表或字段avg_score綜合評(píng)分冗余字段create_time發(fā)布時(shí)間評(píng)論表t_comment核心字段id主鍵work_id對(duì)應(yīng)作品iduser_id評(píng)論用戶idparent_id父評(píng)論id用于回復(fù)0表示頂級(jí)評(píng)論content評(píng)論內(nèi)容score評(píng)分1-5整數(shù)create_time評(píng)論時(shí)間除這三張表之外還需要分類表、收藏表、通知表。收藏表主要是用戶id加作品id唯一約束通知表是給創(chuàng)作者發(fā)“有人評(píng)論了你的作品”的站內(nèi)信如果不想要可以省掉。管理員日志表建議也建一個(gè)記錄關(guān)鍵操作答辯時(shí)能展示系統(tǒng)規(guī)范性。3.2 分類與圖片存儲(chǔ)的設(shè)計(jì)細(xì)節(jié)手工藝品的分類不能太粗也不能太細(xì)。太粗像“陶瓷、雕刻、編織”這種大類首頁(yè)展示還行但搜索結(jié)果會(huì)很扎堆太細(xì)像“青花瓷”“紫砂壺”“竹根雕”管理起來(lái)又太麻煩。我采用的是二級(jí)分類設(shè)計(jì)一級(jí)分類保持大類二級(jí)分類細(xì)分品種。分類表結(jié)構(gòu)id主鍵name分類名稱parent_id父分類id0表示一級(jí)分類sort排序號(hào)icon分類圖標(biāo)路徑例如“陶瓷”是一級(jí)分類下面關(guān)聯(lián)“日用陶瓷”“藝術(shù)陶瓷”“紫砂”等二級(jí)分類。前端分類導(dǎo)航只顯示一級(jí)分類點(diǎn)進(jìn)去后左側(cè)欄顯示該分類下的所有二級(jí)分類用戶點(diǎn)擊二級(jí)分類再篩選對(duì)應(yīng)作品。這樣層級(jí)清楚也不會(huì)造成頁(yè)面過深。圖片存儲(chǔ)其實(shí)是個(gè)很容易踩坑的點(diǎn)。很多人喜歡把圖片轉(zhuǎn)成Base64字符串存在數(shù)據(jù)庫(kù)里簡(jiǎn)單是簡(jiǎn)單但數(shù)據(jù)庫(kù)會(huì)變得巨臃腫查詢速度直線下降。正確做法是圖片文件上傳到服務(wù)器本地目錄比如項(xiàng)目根目錄下的/upload文件夾數(shù)據(jù)庫(kù)里只存相對(duì)路徑。MultipartFile接收上傳文件后用UUID重命名文件防止中文文件名亂碼和重復(fù)。String originalName file.getOriginalFilename(); String ext originalName.substring(originalName.lastIndexOf(.)); String fileName UUID.randomUUID().toString().replace(-, ) ext; File dest new File(uploadDir, fileName); file.transferTo(dest); // 數(shù)據(jù)庫(kù)里存/upload/文件名這里有個(gè)細(xì)節(jié)uploadDir一定要配置成絕對(duì)路徑并且要提前創(chuàng)建好目錄否則transferTo會(huì)報(bào)目錄不存在。同時(shí)也要對(duì)文件大小和類型做校驗(yàn)一般限制單張5MB以內(nèi)只允許jpg、png、gif這些常見格式。3.3 表結(jié)構(gòu)設(shè)計(jì)時(shí)容易忽略的幾個(gè)坑第一密碼不要用明文。有些人做課程設(shè)計(jì)圖省事密碼隨便存。但畢業(yè)設(shè)計(jì)評(píng)委經(jīng)常會(huì)問“密碼怎么存儲(chǔ)”如果回答明文印象分直接掉一大截。用BCrypt或者至少用加鹽的SHA-256做哈希Spring Security里自帶BCryptPasswordEncoder單獨(dú)引進(jìn)來(lái)也很簡(jiǎn)單。第二作品的評(píng)分不要實(shí)時(shí)去評(píng)論表里count再加avg。評(píng)論量大了以后這條查詢會(huì)成為性能瓶頸。正確做法是在t_work表里加一個(gè)avg_score字段每次用戶提交評(píng)論時(shí)在同一個(gè)事務(wù)里重新計(jì)算平均分并更新這個(gè)字段。讀的時(shí)候就不用查評(píng)論表了。第三狀態(tài)字段要用int類型盡量不用字符串。比如作品狀態(tài)0、1、2、3在代碼里可以定義常量來(lái)對(duì)應(yīng)避免字符串比對(duì)不準(zhǔn)確。狀態(tài)變化的地方比如審核通過、用戶下架要寫清業(yè)務(wù)邏輯尤其是“管理員把作品駁回后創(chuàng)作者需要能重新編輯再提交審核”這個(gè)閉環(huán)。第四所有時(shí)間字段建議用datetime不要用timestamp還好主要區(qū)別在于時(shí)區(qū)處理MySQL里datetime更直觀。讀取時(shí)在實(shí)體類里用LocalDateTime對(duì)應(yīng)避免java.util.Date帶來(lái)的時(shí)區(qū)麻煩。4. 核心功能模塊的實(shí)現(xiàn)細(xì)節(jié)4.1 作品展示模塊從列表到詳情的完整鏈路作品展示是整個(gè)系統(tǒng)的門面也是用戶訪問量最大的部分。列表頁(yè)要支持分類篩選、關(guān)鍵詞搜索、分頁(yè)和排序。我用的方案是MyBatis動(dòng)態(tài)SQL在Mapper里用if標(biāo)簽拼接查詢條件select idpageWorks resultTypecom.example.vo.WorkVO SELECT w.*, u.nickname, c.name AS categoryName FROM t_work w LEFT JOIN t_user u ON w.user_id u.id LEFT JOIN t_category c ON w.category_id c.id WHERE w.status 1 if testcategoryId ! null AND w.category_id #{categoryId} /if if testkeyword ! null and keyword ! AND (w.title LIKE CONCAT(%, #{keyword}, %) OR w.description LIKE CONCAT(%, #{keyword}, %)) /if ORDER BY w.create_time DESC LIMIT #{offset}, #{pageSize} /select這里的LIKE查詢?cè)谟脩羲阉鲿r(shí)會(huì)觸發(fā)全表掃描數(shù)據(jù)不多時(shí)沒關(guān)系但如果作品量大了可以再加一個(gè)全文索引或者改用Elasticsearch不過對(duì)畢業(yè)設(shè)計(jì)來(lái)說這一步已經(jīng)足夠了。分頁(yè)我建議自己用LIMIT實(shí)現(xiàn)不要引入PageHelper插件。PageHelper確實(shí)方便但有些版本和Spring Boot配合會(huì)碰到分頁(yè)失效的奇怪問題不如老老實(shí)實(shí)傳offset和pageSize邏輯透明答辯時(shí)也更好解釋。作品詳情頁(yè)要做的一件事是瀏覽量自增。每訪問一次view_count加一。這個(gè)操作不建議同步到數(shù)據(jù)庫(kù)請(qǐng)求里可以用Redis緩存自增再定時(shí)落庫(kù)。但如果項(xiàng)目里沒用Redis直接在Service加一條update語(yǔ)句也完全能接受因?yàn)楫厴I(yè)設(shè)計(jì)不需要對(duì)抗高并發(fā)。關(guān)鍵是更新瀏覽量時(shí)不要影響詳情查詢的速度。詳情頁(yè)還應(yīng)該顯示創(chuàng)作者信息。這里我踩了一個(gè)坑如果直接用作品表的user_id關(guān)聯(lián)用戶表查詢時(shí)用left join那創(chuàng)作者昵稱和頭像在列表頁(yè)和詳情頁(yè)都能拿到。但如果你做了VO實(shí)體類記得把用戶表的字段單獨(dú)封裝別把整張用戶表所有字段全帶出來(lái)尤其是密碼字段絕對(duì)不能漏到前端JSON里。4.2 評(píng)論與評(píng)分模塊事務(wù)和防刷是關(guān)鍵這個(gè)模塊是系統(tǒng)里業(yè)務(wù)邏輯最復(fù)雜的部分。普通用戶登錄后可以針對(duì)作品評(píng)論、評(píng)分也可以回復(fù)別人的評(píng)論。設(shè)計(jì)上要注意幾點(diǎn)首先是一個(gè)用戶對(duì)同一作品只能評(píng)分一次。我最初沒有做限制測(cè)試時(shí)自己給自己刷了五六條評(píng)分導(dǎo)致作品平均分跑到4.9看起來(lái)假得離譜。后來(lái)在評(píng)論表加了唯一約束UNIQUE KEY uk_work_user (work_id, user_id)并且把評(píng)分和評(píng)論放在同一條記錄里也就是“評(píng)分必須附帶評(píng)論內(nèi)容”防止用戶只打分不寫文字。其次是嵌套回復(fù)的層級(jí)限制。用戶A評(píng)論作品用戶B可以回復(fù)A但B不能回復(fù)C對(duì)A的回復(fù)。因?yàn)橐坏┰试S無(wú)限套娃前端展示評(píng)論區(qū)就非常復(fù)雜數(shù)據(jù)庫(kù)遞歸查詢也很頭疼。做法是新建評(píng)論時(shí)判斷parent_id如果parent_id不為0則查一下父評(píng)論的parent_id如果父評(píng)論的parent_id還是0允許回復(fù)否則拒絕。這樣評(píng)論最多兩層頁(yè)面展示清晰邏輯也簡(jiǎn)單。再就是平均分更新事務(wù)。用戶提交評(píng)論后Service里做三步Transactional public void addComment(CommentDTO dto, Long userId) { // 1. 校驗(yàn)作品存在且狀態(tài)為已通過 Work work workMapper.findById(dto.getWorkId()); if (work null || work.getStatus() ! 1) { throw new BusinessException(作品不存在或未上架); } // 2. 插入評(píng)論 Comment comment new Comment(); comment.setWorkId(dto.getWorkId()); comment.setUserId(userId); comment.setScore(dto.getScore()); comment.setContent(dto.getContent()); comment.setParentId(dto.getParentId() null ? 0 : dto.getParentId()); commentMapper.insert(comment); // 3. 更新作品的平均分和評(píng)論數(shù) MapString, Object scoreInfo commentMapper.getAvgScoreByWorkId(dto.getWorkId()); Double avgScore (Double) scoreInfo.get(avgScore); Long count (Long) scoreInfo.get(cnt); workMapper.updateScore(dto.getWorkId(), avgScore, count); }getAvgScoreByWorkId這個(gè)SQL是用來(lái)在插入評(píng)論后查詢?cè)撟髌匪性u(píng)論的平均分和評(píng)論數(shù)再寫回作品表。注意事務(wù)范圍內(nèi)先insert再select avgMySQL默認(rèn)隔離級(jí)別下這個(gè)查詢能拿到剛提交的數(shù)據(jù)所以在同一個(gè)事務(wù)里沒問題。評(píng)論內(nèi)容必須先過濾再入庫(kù)。最簡(jiǎn)單的辦法是引入一個(gè)HtmlUtils.htmlEscape()把尖括號(hào)、引號(hào)轉(zhuǎn)義掉防止XSS腳本注入。如果你想更徹底可以在前端展示時(shí)再轉(zhuǎn)義一次雙保險(xiǎn)。4.3 創(chuàng)作者后臺(tái)發(fā)布、審核、狀態(tài)管理創(chuàng)作者登錄后進(jìn)入專屬后臺(tái)可以發(fā)布作品、管理已有的作品列表、編輯作品、下架或重新上架作品。這個(gè)后臺(tái)本質(zhì)上是一個(gè)小型內(nèi)容管理系統(tǒng)。發(fā)布作品的表單字段包括作品名稱、分類、描述、封面圖、附加圖片。分類需要做成級(jí)聯(lián)選擇先選一級(jí)分類再選二級(jí)分類。由于分類在系統(tǒng)里是固定的可以提前把分類樹查出來(lái)放到Redis里緩存沒有Redis就每次查詢也沒關(guān)系因?yàn)榉诸惐頂?shù)據(jù)量很小。有一個(gè)容易忽略的點(diǎn)創(chuàng)作者提交作品后作品狀態(tài)默認(rèn)是0待審核狀態(tài)。在這個(gè)狀態(tài)下游客和普通用戶在瀏覽頁(yè)面是看不到這件作品的只有創(chuàng)作者自己在前臺(tái)通過“我的作品”列表才能看到。管理員在后臺(tái)看到待審作品后可以審核通過、駁回。駁回時(shí)最好要求管理員填寫駁回理由創(chuàng)作者編輯后重新提交狀態(tài)回到待審核。這里的權(quán)限校驗(yàn)要貫徹。作品的管理操作編輯、刪除、上下架必須校驗(yàn)當(dāng)前登錄用戶是不是作品的user_id否則一個(gè)創(chuàng)作者可以把別人的作品改成自己的數(shù)據(jù)就全亂了。我用一個(gè)簡(jiǎn)單的checkOwner方法在進(jìn)入編輯頁(yè)之前先判斷。public Work getOwnedWork(Long workId, Long userId) { Work work workMapper.findById(workId); if (work null || !work.getUserId().equals(userId)) { throw new BusinessException(無(wú)權(quán)操作); } return work; }另外創(chuàng)作者可以在作品詳情頁(yè)回復(fù)用戶評(píng)論?；貜?fù)本質(zhì)上也是插入一條評(píng)論記錄parent_id指向目標(biāo)評(píng)論的id。這里不需要再判斷目標(biāo)評(píng)論的層級(jí)嗎需要。我上面說的二級(jí)評(píng)論限制在創(chuàng)作者后臺(tái)回復(fù)時(shí)也要走同一套校驗(yàn)所以我把“檢查評(píng)論是否可被回復(fù)”的邏輯抽成了公共方法創(chuàng)作者回復(fù)和普通用戶回復(fù)共用一套代碼避免邏輯分叉。4.4 后臺(tái)管理模塊審核和統(tǒng)計(jì)管理員后臺(tái)要做的操作是查看作品列表包括待審、已發(fā)布、已下架等狀態(tài)、審核作品、管理用戶、管理分類、查看訪問統(tǒng)計(jì)數(shù)據(jù)。我經(jīng)驗(yàn)里最實(shí)用的是做一個(gè)簡(jiǎn)單數(shù)據(jù)看板展示總作品數(shù)、總用戶數(shù)、今日新增作品數(shù)、待審核數(shù)、評(píng)論總數(shù)。這些數(shù)據(jù)用幾個(gè)count查詢拼起來(lái)就好不需要引入ECharts之類的圖表庫(kù)哪怕只是表格也足夠。如果項(xiàng)目時(shí)間充足可以再加一個(gè)按分類的作品數(shù)量餅圖用ECharts畫起來(lái)不難效果也好看。審核操作本身要記錄操作日志。比如管理員“審核通過作品ID為10”這一操作寫入admin_log表附上操作人、操作時(shí)間、操作內(nèi)容。答辯時(shí)展示日志表能體現(xiàn)系統(tǒng)完整性和規(guī)范性這種細(xì)節(jié)很加分。5. 實(shí)操過程與全流程部署記錄5.1 開發(fā)環(huán)境準(zhǔn)備與版本匹配我先列一下我實(shí)際使用的環(huán)境清單JDK 1.8穩(wěn)定和Spring Boot 2.7.x配合良好Maven 3.6.xIDEA 2023MySQL 8.0Navicat用于數(shù)據(jù)庫(kù)管理Spring Boot 2.7.8MyBatis 2.3.0ThymeleafLombok簡(jiǎn)化實(shí)體類代碼有一點(diǎn)必須提醒Spring Boot 3.x已經(jīng)發(fā)布了但3.x要求JDK17起步MyBatis和很多老版本依賴的兼容適配又不太一樣。如果跟著網(wǎng)上的教程走很多教程用的是2.x版本你把項(xiàng)目建到3.x上反而容易報(bào)錯(cuò)。穩(wěn)妥起見畢業(yè)設(shè)計(jì)直接用Spring Boot 2.7.x JDK 8這套組合最成熟、踩坑最少。MySQL連接時(shí)要注意驅(qū)動(dòng)版本MySQL 8對(duì)應(yīng)依賴是com.mysql.cj.jdbc.DriverURL里要加上serverTimezoneAsia/Shanghai和useSSLfalse否則啟動(dòng)時(shí)會(huì)有時(shí)區(qū)報(bào)錯(cuò)和SSL警告。5.2 項(xiàng)目目錄結(jié)構(gòu)與核心配置我用標(biāo)準(zhǔn)的Maven目錄結(jié)構(gòu)包名一般寫成com.example.craft或者com.demo.artwork這里我建議別用全拼音用一個(gè)規(guī)范的英文包名就好。核心包結(jié)構(gòu)如下src/main/java/com/example/craft ├── controller // 接口層 ├── service // 業(yè)務(wù)邏輯層 ├── mapper // MyBatis數(shù)據(jù)訪問層 ├── entity // 數(shù)據(jù)庫(kù)實(shí)體 ├── vo // 視圖對(duì)象 ├── dto // 數(shù)據(jù)傳輸對(duì)象 ├── config // 配置類攔截器、靜態(tài)資源映射等 ├── interceptor // 登錄攔截器 └── common // 通用返回結(jié)果、異常處理application.yml核心配置server: port: 8080 spring: datasource: driver-class-name: com.mysql.cj.jdbc.Driver url: jdbc:mysql://localhost:3306/craft_db?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/ShanghaiuseSSLfalse username: root password: 123456 servlet: multipart: max-file-size: 5MB max-request-size: 20MB thymeleaf: cache: false mybatis: mapper-locations: classpath:mapper/*.xml type-aliases-package: com.example.craft.entity configuration: map-underscore-to-camel-case: truemap-underscore-to-camel-case一定要開這樣數(shù)據(jù)庫(kù)字段user_id可以自動(dòng)映射到實(shí)體類的userId省掉一大堆手動(dòng)映射。靜態(tài)資源映射也要單獨(dú)配一下因?yàn)樯蟼鞯膱D片在項(xiàng)目運(yùn)行目錄之外默認(rèn)訪問不到。用WebMvcConfigurer或者配置類里把/upload/**映射到本地磁盤目錄Override public void addResourceHandlers(ResourceHandlerRegistry registry) { registry.addResourceHandler(/upload/**) .addResourceHandler(file: uploadDir /); }5.3 從打包到部署兩種方式都要會(huì)開發(fā)階段直接在IDEA里啟動(dòng)Spring Boot主類就行。但作為畢業(yè)設(shè)計(jì)建議你學(xué)會(huì)打成jar包然后用命令行運(yùn)行。這樣答辯時(shí)換一臺(tái)電腦演示不用裝IDEA只要有JDK就行。打包命令mvn clean package -DskipTests打出來(lái)的jar在target目錄下名稱類似craft-0.0.1-SNAPSHOT.jar。運(yùn)行java -jar target/craft-0.0.1-SNAPSHOT.jar如果想部署到云服務(wù)器還得把數(shù)據(jù)庫(kù)導(dǎo)過去上傳jar包。上傳后建立目錄結(jié)構(gòu)把a(bǔ)pplication.yml里的數(shù)據(jù)庫(kù)地址改成云數(shù)據(jù)庫(kù)地址或服務(wù)器本機(jī)MySQL地址重新打一次包再啟動(dòng)。如果老師的驗(yàn)收環(huán)境必須用Tomcat那也可以打成war包。先把pom.xml的packaging改成war然后在啟動(dòng)類上繼承SpringBootServletInitializer并重寫configure方法。用Maven打war包后放到Tomcat的webapps目錄下啟動(dòng)Tomcat后訪問http://localhost:8080/war包名/注意多了個(gè)應(yīng)用上下文路徑所有頁(yè)面的URL都要帶上這個(gè)路徑前綴。為了避免這種麻煩你可以在application.yml里設(shè)置server.servlet.context-path: /但war包方式我建議直接放棄jar方式已經(jīng)能滿足絕大多數(shù)場(chǎng)景。5.4 初始化測(cè)試數(shù)據(jù)系統(tǒng)里不能沒有數(shù)據(jù)尤其手工類項(xiàng)目沒有幾張精美的手工藝作品圖頁(yè)面效果直接就塌了。我在開發(fā)階段準(zhǔn)備了一套測(cè)試數(shù)據(jù)大概二十件作品分布到陶瓷、木雕、編織、刺繡、金屬工藝五個(gè)分類里。圖片我是在開源圖庫(kù)網(wǎng)站找的免費(fèi)授權(quán)圖片用圖片壓縮工具壓到100KB以內(nèi)保證頁(yè)面加載快。生成測(cè)試數(shù)據(jù)的SQL腳本要單獨(dú)建一個(gè)data.sql文件每次重置數(shù)據(jù)庫(kù)后執(zhí)行一遍。數(shù)據(jù)里可以模擬幾個(gè)用戶一個(gè)是普通用戶一個(gè)是創(chuàng)作者一個(gè)是管理員。管理員賬號(hào)密碼可以直接在SQL里插入BCrypt加密后的值。INSERT INTO t_user (username, password, nickname, role) VALUES (admin, $2a$10$...BCryptHash..., 管理員, 3);這個(gè)BCrypt哈希值怎么生成寫一個(gè)最簡(jiǎn)單的main方法調(diào)用BCryptPasswordEncoder的encode方法就行。6. 常見問題與排查技巧實(shí)錄6.1 典型問題速查表做這類項(xiàng)目翻來(lái)覆去遇到的就那么幾個(gè)問題。我把高頻問題和排查思路整理成了一張表遇到問題先查表比一個(gè)個(gè)搜報(bào)錯(cuò)快得多。問題現(xiàn)象可能原因解決辦法啟動(dòng)時(shí)報(bào)數(shù)據(jù)庫(kù)時(shí)區(qū)異常URL缺少serverTimezone參數(shù)加上serverTimezoneAsia/Shanghai中文亂碼頁(yè)面編碼、響應(yīng)頭或數(shù)據(jù)庫(kù)編碼不一致數(shù)據(jù)庫(kù)建庫(kù)用utf8mb4頁(yè)面設(shè)置charsetutf-8過濾器設(shè)置請(qǐng)求和響應(yīng)編碼圖片上傳后訪問404靜態(tài)資源映射沒配配置類里把/upload/**映射到本地upload目錄圖片上傳報(bào)exceeds maximum size上傳大小超限在application.yml的multipart配置里調(diào)大max-file-size評(píng)論提交后平均分沒變事務(wù)沒生效或更新語(yǔ)句沒執(zhí)行檢查Service方法有沒有加Transactional檢查作品表updateScore語(yǔ)句登錄狀態(tài)一會(huì)有一會(huì)無(wú)Session域設(shè)置或攔截器順序問題統(tǒng)一用Session存用戶對(duì)象攔截器排除登錄、首頁(yè)、詳情頁(yè)等公開路徑列表分頁(yè)頁(yè)碼越界前端傳參沒校驗(yàn)后端統(tǒng)一封裝pageNum和pageSize非法時(shí)設(shè)置默認(rèn)值部署到服務(wù)器后訪問不到防火墻或安全策略未放行端口檢查服務(wù)器安全組和本機(jī)防火墻確保8080端口開放中文文件名圖片上傳報(bào)錯(cuò)文件名里帶中文和特殊字符用UUID重命名文件避免使用原始文件名6.2 排查思路與避坑經(jīng)驗(yàn)排查問題先看日志這是我一直強(qiáng)調(diào)的。Spring Boot的報(bào)錯(cuò)日志會(huì)打印出具體異常棧根據(jù)異常類型基本能判斷問題范圍。比如NullPointerException通常在Service層SQLSyntaxErrorException多半是SQL語(yǔ)句寫錯(cuò)FileNotFoundException基本是路徑拼錯(cuò)。一個(gè)很典型的坑是MyBatis查詢結(jié)果映射成實(shí)體類時(shí)返回null。出現(xiàn)這種問題第一懷疑map-underscore-to-camel-case配置沒生效第二懷疑實(shí)體類字段名和數(shù)據(jù)庫(kù)字段不一致第三懷疑MyBatis的resultType寫錯(cuò)了。自己排查時(shí)可以先在Mapper接口上加一個(gè)Select注解的簡(jiǎn)單查詢打印出來(lái)看看字段是否正常再定位是映射問題還是SQL問題。還有就是前后端傳參時(shí)時(shí)間格式格式化問題。比如詳情頁(yè)顯示“2024-05-12 15:30:00”如果你在實(shí)體類里直接用了LocalDateTime在Thymeleaf模板上顯示會(huì)默認(rèn)帶個(gè)T比如“2024-05-12T15:30:00”。這時(shí)候用模板引擎自帶的時(shí)間格式化函數(shù)或者在后端ToString格式化成字符串都是可以的。我一般是在VO里直接加一個(gè)格式化好的createTimeStr字段前端顯示這個(gè)字符串省事且直觀。另外測(cè)試功能時(shí)一定要用邊界數(shù)據(jù)。比如分類下拉框什么都不選參數(shù)是空值能不能正常查全部分類搜索框輸入特殊字符比如單引號(hào)會(huì)不會(huì)SQL報(bào)錯(cuò)評(píng)論字?jǐn)?shù)超過2000字頁(yè)面會(huì)不會(huì)卡死這些邊界問題在答辯前自己都測(cè)一遍老師提問時(shí)你的系統(tǒng)表現(xiàn)會(huì)好很多。6.3 完善項(xiàng)目的小技巧加分項(xiàng)其實(shí)這個(gè)項(xiàng)目做完整以后還有很多可以低成本的加分項(xiàng)。一個(gè)是讓頁(yè)面響應(yīng)式適配用Bootstrap或者純CSS保證手機(jī)和電腦都能看手工藝品的用戶很多是用手機(jī)瀏覽的頁(yè)面在手機(jī)上不能變形。另一個(gè)是給主要模塊加操作日志比如管理員審核、創(chuàng)作者下架作品都能記錄在日志表。還有一個(gè)是我前面提到的數(shù)據(jù)看板哪怕只是幾個(gè)數(shù)字卡片也說明你有數(shù)據(jù)可視化意識(shí)。再有就是善用Git。整個(gè)過程用Git管理版本每次功能做完提交一次commit即使改出問題也能回滾。有些老師答辯時(shí)還會(huì)問“開發(fā)流程”你完全可以把GitLog展示出來(lái)證明你有良好的工程習(xí)慣。這個(gè)習(xí)慣放在簡(jiǎn)歷上也是能寫的點(diǎn)。最后聊點(diǎn)個(gè)人體會(huì)這個(gè)項(xiàng)目做完我最深的感受是畢業(yè)設(shè)計(jì)做管理系統(tǒng)功能多不是關(guān)鍵關(guān)鍵是每個(gè)功能鏈路要閉環(huán)。像作品上傳、管理員審核、用戶評(píng)價(jià)、評(píng)分更新、創(chuàng)作者回復(fù)這條鏈路每一步的權(quán)限和數(shù)據(jù)狀態(tài)變化都理清楚系統(tǒng)自然就穩(wěn)了。很多同學(xué)做這類題做不動(dòng)往往不是不會(huì)寫代碼而是需求自己沒捋明白數(shù)據(jù)庫(kù)表一下缺一個(gè)字段一下少一張表最后只能一邊寫一邊改。所以我建議動(dòng)手之前至少花兩天時(shí)間做設(shè)計(jì)畫ER圖、畫頁(yè)面原型圖、畫角色流程圖。設(shè)計(jì)稿越細(xì)后面寫代碼越快。技術(shù)本身沒有多玄妙Spring Boot也好、MyBatis也好都是一些成熟工具的堆疊真正值錢的其實(shí)是“你清楚自己在做什么、為什么這么做”。這套思路不僅適用于這個(gè)工藝品展示系統(tǒng)換成任何Java Web管理類題目的畢業(yè)設(shè)計(jì)都完全通用。