做畢業(yè)設(shè)計(jì)選“基于SpringBoot的攝影分享網(wǎng)站系統(tǒng)”說(shuō)實(shí)話是個(gè)很穩(wěn)的選擇。SpringBoot本身在企業(yè)級(jí)開(kāi)發(fā)里已經(jīng)是事實(shí)標(biāo)準(zhǔn)攝影類網(wǎng)站又有明確的業(yè)務(wù)場(chǎng)景、豐富的交互功能、清晰的角色邊界用來(lái)展示技術(shù)能力和工程化素養(yǎng)非常合適。我自己帶過(guò)的學(xué)生里選這個(gè)方向的不在少數(shù)但做得好和做得一般的差距往往不在框架本身而在于細(xì)節(jié)——權(quán)限怎么設(shè)計(jì)、上傳怎么處理、檢索怎么做、部署怎么落地。這篇就把“有光”攝影分享網(wǎng)站從立項(xiàng)到答辯的完整思路拆開(kāi)講清楚每個(gè)環(huán)節(jié)要做什么、為什么要這么做、坑在哪里。不管你是想直接照著做還是想理解底層邏輯方便答辯時(shí)應(yīng)對(duì)提問(wèn)都值得看完。1. 項(xiàng)目立項(xiàng)與整體設(shè)計(jì)思路1.1 需求定位光為主題、分享為核“有光”這個(gè)名字很好攝影本來(lái)就是捕捉光的藝術(shù)。圍繞這個(gè)主題系統(tǒng)核心任務(wù)可以拆成兩條線一條是內(nèi)容線也就是攝影師上傳作品、展示作品一條是互動(dòng)線用戶瀏覽、點(diǎn)贊、評(píng)論、收藏形成社區(qū)氛圍。從畢業(yè)設(shè)計(jì)的評(píng)審角度來(lái)看這兩條線恰好覆蓋了大部分技術(shù)點(diǎn)。內(nèi)容線涉及文件上傳、存儲(chǔ)、圖片處理、數(shù)據(jù)管理互動(dòng)線涉及用戶鑒權(quán)、關(guān)系表設(shè)計(jì)、通知機(jī)制、并發(fā)控制。把這兩條線完整做下來(lái)系統(tǒng)的業(yè)務(wù)完整性就有了不再是“看起來(lái)很淺”的CRUD。用戶角色建議分三類普通用戶、攝影師、管理員。不用過(guò)度設(shè)計(jì)三類的權(quán)限邊界足夠講清楚RBAC的思路。普通用戶可以瀏覽、評(píng)論、點(diǎn)贊、收藏?cái)z影師可以額外上傳作品、管理自己的作品集管理員負(fù)責(zé)審核內(nèi)容、管理用戶、處理舉報(bào)。1.2 技術(shù)選型為什么是SpringBoot這套組合后端框架用SpringBoot 2.7.x別用3.x。3.x雖然已經(jīng)發(fā)布很久但很多第三方庫(kù)的兼容性、參考資料的匹配度都不如2.7成熟對(duì)畢業(yè)設(shè)計(jì)來(lái)說(shuō)沒(méi)必要冒險(xiǎn)。SpringBoot 2.7既是主流教材覆蓋的版本又能平滑適配后續(xù)要用的所有中間件。持久層建議用MyBatis-Plus不是因?yàn)樗菾PA“更好”而是因?yàn)樗拇a生成器、分頁(yè)插件、條件構(gòu)造器能極大壓縮開(kāi)發(fā)時(shí)間而且接口設(shè)計(jì)直觀。這里有一點(diǎn)容易被質(zhì)疑MyBatis-Plus是不是太“傻瓜化”了答辯時(shí)你可以這樣答項(xiàng)目核心難點(diǎn)不在單表CRUD而在多表關(guān)聯(lián)、分布式文件存儲(chǔ)、檢索排序這些場(chǎng)景MyBatis-Plus負(fù)責(zé)提升基礎(chǔ)開(kāi)發(fā)效率復(fù)雜SQL仍然手寫(xiě)二者相輔相成。存儲(chǔ)層選用MySQL 8.0緩存用Redis文件對(duì)象存儲(chǔ)用MinIO檢索用Elasticsearch加分詞器。這套組合幾乎是當(dāng)前中小型項(xiàng)目的標(biāo)準(zhǔn)配置每一項(xiàng)都對(duì)應(yīng)明確的業(yè)務(wù)場(chǎng)景不會(huì)顯得堆砌。1.3 模塊劃分與功能矩陣系統(tǒng)拆成六個(gè)核心模塊用戶中心、作品管理、社交互動(dòng)、內(nèi)容檢索、數(shù)據(jù)看板、后臺(tái)管理。每個(gè)模塊再細(xì)分成小功能畫(huà)成表格會(huì)更直觀模塊功能點(diǎn)技術(shù)要點(diǎn)用戶中心注冊(cè)/登錄/個(gè)人信息JWT鑒權(quán)、Redis會(huì)話、頭像上傳作品管理上傳/編輯/相冊(cè)分組MinIO存儲(chǔ)、圖片壓縮、EXIF讀取社交互動(dòng)點(diǎn)贊/評(píng)論/收藏/關(guān)注Redis緩存計(jì)數(shù)、異步通知內(nèi)容檢索關(guān)鍵詞搜索/標(biāo)簽篩選/排行ElasticsearchIK分詞數(shù)據(jù)看板用戶畫(huà)像/作品統(tǒng)計(jì)ECharts可視化后臺(tái)管理用戶審核/作品審核/舉報(bào)處理權(quán)限校驗(yàn)、多條件分頁(yè)權(quán)限控制統(tǒng)一基于Spring Security JWT實(shí)現(xiàn)。JWT無(wú)狀態(tài)、適合前后端分離相比Session方案在分布式環(huán)境下更友好。這里要注意JWT的密鑰要配置在application.yml里并通過(guò)環(huán)境變量覆蓋不要把硬編碼的密鑰直接提交到Git倉(cāng)庫(kù)。2. 核心細(xì)節(jié)解析與關(guān)鍵實(shí)現(xiàn)2.1 數(shù)據(jù)庫(kù)設(shè)計(jì)五張核心表之間的關(guān)系表設(shè)計(jì)是整個(gè)項(xiàng)目的地基很多學(xué)生在這里翻車后面返工非常痛苦。用戶表、作品表、評(píng)論表、點(diǎn)贊表、收藏表、關(guān)注表是六張必需的前四張人人都會(huì)建容易出錯(cuò)的是點(diǎn)贊和收藏。點(diǎn)贊表和收藏表建議單獨(dú)設(shè)計(jì)而不建議在作品表里加一個(gè)“l(fā)ike_count”字段就完事。單獨(dú)設(shè)計(jì)的好處有兩點(diǎn)一是可以記錄“誰(shuí)點(diǎn)贊過(guò)”支持用戶點(diǎn)進(jìn)自己的點(diǎn)贊列表查看二是通過(guò)唯一約束user_id work_id防止重復(fù)點(diǎn)贊。作品表里的like_count只作為冗余計(jì)數(shù)在事務(wù)里與點(diǎn)贊表同步更新避免每次統(tǒng)計(jì)都走count查詢。作品表有一個(gè)字段容易忽略cover_url。列表頁(yè)只需要顯示封面詳情頁(yè)才需要加載所有圖片。把封面單獨(dú)存列表查詢就只需要掃一行數(shù)據(jù)不用查JSON數(shù)組性能差異在數(shù)據(jù)量上來(lái)之后非常明顯。2.2 文件上傳MinIO與圖片處理的完整鏈路攝影網(wǎng)站的核心資源是圖片上傳模塊的設(shè)計(jì)直接影響用戶體驗(yàn)和系統(tǒng)穩(wěn)定性。整體流程是前端先請(qǐng)求后端獲取預(yù)簽名上傳地址拿到地址后直接傳給MinIO再由前端通知后端“上傳完成”后端再做數(shù)據(jù)落庫(kù)。這套流程很多人第一次接觸會(huì)覺(jué)得繞為什么要多一步原因有兩條一是文件不經(jīng)過(guò)應(yīng)用服務(wù)器避免了大文件傳輸占用應(yīng)用內(nèi)存和帶寬二是MinIO的預(yù)簽名URL可以限制有效時(shí)間和對(duì)象大小安全性更有保障。如果實(shí)在想簡(jiǎn)化也可以走應(yīng)用服務(wù)器再轉(zhuǎn)發(fā)但對(duì)并發(fā)上傳場(chǎng)景不友好。圖片處理建議在服務(wù)端做多尺寸裁剪。原始圖片能到5MB甚至更大直接展示會(huì)拖慢首屏。業(yè)界常見(jiàn)做法是生成三種規(guī)格縮略圖200px列表圖800px原圖最長(zhǎng)邊不超過(guò)2048px用于詳情頁(yè)。圖片處理可以用Thumbnailator或Java自帶的ImageIO抗幾個(gè)大圖就完了。如果追求工程化用ffmpeg或者ImgScalr都行。2.3 全文檢索Elasticsearch與IK分詞的集成搜索模塊是“有光”系統(tǒng)里最能拉開(kāi)技術(shù)檔次的功能。作品標(biāo)題、描述、標(biāo)簽都可以作為檢索字段單純用MySQL的LIKE查詢不是不行但一旦數(shù)據(jù)量大起來(lái)性能和多條件組合查詢的復(fù)雜度都會(huì)失控。我在項(xiàng)目里用的是Elasticsearch 7.x IK分詞器。索引的mapping設(shè)計(jì)要注意分詞器選擇標(biāo)題和標(biāo)簽用ik_max_word保證可切分成最細(xì)粒度的詞描述字段可以不用索引或者用ik_smart減少索引體積。檢索時(shí)用bool_query組合must、should、filter三種條件分別處理“關(guān)鍵詞匹配”“標(biāo)簽命中”“類型篩選”三種需求。索引同步是另一個(gè)容易踩坑的點(diǎn)。方案可以選擇監(jiān)聽(tīng)MySQL的binlog也可以選擇在業(yè)務(wù)代碼里顯式同步后者對(duì)畢設(shè)來(lái)說(shuō)更可控。上傳作品和編輯作品時(shí)在同一事務(wù)內(nèi)完成MySQL寫(xiě)入和ES索引更新失敗就回滾。查詢時(shí)優(yōu)先查ES拿不到再降級(jí)查MySQL。2.4 并發(fā)與緩存Redis在互動(dòng)場(chǎng)景中的角色點(diǎn)贊這個(gè)功能看起來(lái)簡(jiǎn)單但高頻并發(fā)下容易出問(wèn)題。我的處理方式是記錄在Redis的Hash結(jié)構(gòu)里key是作品IDfield是用戶IDvalue是點(diǎn)贊狀態(tài)。用戶點(diǎn)贊時(shí)不再直接寫(xiě)MySQL而是先寫(xiě)Redis再通過(guò)異步任務(wù)批量把Redis數(shù)據(jù)回寫(xiě)到MySQL。有人可能會(huì)問(wèn)為什么不直接寫(xiě)MySQL因?yàn)闊狳c(diǎn)作品的點(diǎn)贊頻率可能達(dá)到每秒幾十上百次直接落在數(shù)據(jù)庫(kù)上會(huì)持續(xù)觸發(fā)行鎖和IO而Redis的寫(xiě)入性能是內(nèi)存級(jí)別的?；貙?xiě)采用定時(shí)任務(wù)每5分鐘跑一次把變更的點(diǎn)贊記錄批量合并寫(xiě)入同時(shí)同步更新作品表的冗余計(jì)數(shù)。評(píng)論功能要控制最大深度。嵌套評(píng)論在視覺(jué)上很自然但查詢時(shí)遞歸展開(kāi)代價(jià)很高。經(jīng)驗(yàn)做法是只支持兩級(jí)一級(jí)評(píng)論掛在作品下二級(jí)評(píng)論掛在一級(jí)評(píng)論下查詢時(shí)一次取出在內(nèi)存里做樹(shù)形組裝。數(shù)據(jù)庫(kù)里用parent_id字段表達(dá)層級(jí)再額外存一個(gè)root_id方便清理整棵評(píng)論樹(shù)。2.5 安全與異常處理全局過(guò)濾器與統(tǒng)一異常體系XSS攻擊在交互類網(wǎng)站是不能忽視的。評(píng)論和作品描述都允許用戶輸入文本如果不對(duì)