簡(jiǎn)介移動(dòng)互聯(lián)網(wǎng)時(shí)代社區(qū)類(lèi)應(yīng)用的開(kāi)發(fā)模式正加速向前后端分離架構(gòu)演進(jìn)。前后端分離不僅讓后端通過(guò)RESTful API統(tǒng)一輸出數(shù)據(jù)也借助跨端框架讓一套業(yè)務(wù)代碼同時(shí)覆蓋小程序、App與H5。SpringBoot以其成熟的生態(tài)和快速構(gòu)建能力成為服務(wù)端實(shí)現(xiàn)的首選框架之一而Uniapp則為多端適配提供了高效的編譯方案。當(dāng)校園生活場(chǎng)景中的二手交易、失物招領(lǐng)、表白墻等信息需求被聚合時(shí)一套基于統(tǒng)一內(nèi)容表與擴(kuò)展表設(shè)計(jì)的數(shù)據(jù)庫(kù)結(jié)構(gòu)能支撐多模塊共存并減少重復(fù)開(kāi)發(fā)。結(jié)合Redis緩存、JWT鑒權(quán)、敏感詞過(guò)濾等工程實(shí)踐可顯著提升系統(tǒng)的安全性與響應(yīng)性能。本文以校園圈項(xiàng)目為實(shí)例完整拆解從數(shù)據(jù)庫(kù)建模到SpringBoot接口開(kāi)發(fā)、Uniapp多端適配及線上部署的全鏈路關(guān)鍵技術(shù)為社區(qū)類(lèi)應(yīng)用的開(kāi)發(fā)與二次擴(kuò)展提供可直接落地的參考。 從校園墻到完整生態(tài)SpringBoot Uniapp 前后端分離校園圈項(xiàng)目的全鏈路拆解每年開(kāi)學(xué)季和畢業(yè)季校園里的信息需求都會(huì)迎來(lái)一波爆發(fā)——有人找失物、有人出閑置、有人想表白、有人找課友這些零散的需求過(guò)去都貼在宿舍樓下的公告欄或者分散在幾十個(gè)QQ群里。一個(gè)能把這些場(chǎng)景聚合起來(lái)的校園圈子看起來(lái)只是論壇 集市 表白墻的功能拼接但真正動(dòng)手做起來(lái)涉及到的用戶(hù)體系、內(nèi)容審核、跨端適配和部署上線每一步都有不少坑。我花了大半個(gè)月基于 SpringBoot Uniapp 完整實(shí)現(xiàn)了一款前后端分離的校園圈項(xiàng)目覆蓋校園集市、表白墻、論壇、失物招領(lǐng)、校園墻、跳蚤市場(chǎng)六個(gè)核心模塊附帶了完整的數(shù)據(jù)庫(kù)設(shè)計(jì)。這篇文章不打算復(fù)述項(xiàng)目里每個(gè)文件的作用而是想把這套系統(tǒng)的設(shè)計(jì)邏輯、關(guān)鍵代碼實(shí)現(xiàn)、以及我在開(kāi)發(fā)中踩過(guò)的坑講清楚希望能給正準(zhǔn)備做同類(lèi)校園社區(qū)項(xiàng)目的同學(xué)提供一份可以直接參考的實(shí)操經(jīng)驗(yàn)。1. 這個(gè)校園圈項(xiàng)目解決了什么問(wèn)題以及為什么選這套技術(shù)組合1.1 校園場(chǎng)景的信息需求到底有多碎片化在動(dòng)手寫(xiě)代碼之前我先梳理了校園用戶(hù)的真實(shí)使用場(chǎng)景。校園里的信息需求有鮮明的周期性開(kāi)學(xué)季是二手書(shū)和宿舍用品的交易高峰考試周是資料拼單和課友招募的集中期平時(shí)則是失物招領(lǐng)和活動(dòng)組隊(duì)的常態(tài)需求。這些場(chǎng)景過(guò)去分散在QQ群、微信群、貼吧和公告欄里信息發(fā)布沒(méi)有分類(lèi)、沒(méi)有審核、沒(méi)有沉淀一條重要的尋物啟事發(fā)出去幾分鐘就被聊天記錄淹沒(méi)。校園圈這類(lèi)項(xiàng)目的核心價(jià)值不是做一個(gè)大而全的社交平臺(tái)而是把校園內(nèi)的高頻信息需求集中到一個(gè)有分類(lèi)、有審核、有沉淀的社區(qū)里。集市對(duì)應(yīng)交易需求表白墻對(duì)應(yīng)情感表達(dá)需求論壇對(duì)應(yīng)話題討論需求失物招領(lǐng)對(duì)應(yīng)緊急求助需求——每個(gè)模塊的用戶(hù)心理和使用頻率都不一樣這就意味著后端不能只做一個(gè)通用的內(nèi)容發(fā)布接口而是要針對(duì)不同模塊設(shè)計(jì)差異化的業(yè)務(wù)規(guī)則。1.2 選型時(shí)我對(duì)比過(guò)的方案以及最終決定的理由校園圈項(xiàng)目的技術(shù)選型我在動(dòng)手前對(duì)比了三套主流方案。第一套是傳統(tǒng)的 SSMSpring SpringMVC MyBatis配合服務(wù)端渲染模板比如 JSP 或者 Thymeleaf。這套方案的優(yōu)勢(shì)是結(jié)構(gòu)簡(jiǎn)單、學(xué)習(xí)曲線平緩非常適合課程設(shè)計(jì)但問(wèn)題也很明顯前后端耦合嚴(yán)重移動(dòng)端適配基本靠響應(yīng)式 CSS 硬撐做出來(lái)的體驗(yàn)和原生 App 差距很大。第二套是 SpringBoot 做后端、Vue 做 Web 管理端、再單獨(dú)用 Android 原生開(kāi)發(fā)移動(dòng)端。這套方案的體驗(yàn)最好但開(kāi)發(fā)量直接翻倍一套業(yè)務(wù)邏輯要分別在 Web 端和 Android 端各實(shí)現(xiàn)一遍對(duì)于個(gè)人開(kāi)發(fā)者或者小團(tuán)隊(duì)來(lái)說(shuō)維護(hù)成本太高。第三套就是最終選定的 SpringBoot Uniapp 前后端分離方案。后端統(tǒng)一提供 RESTful API前端用 Uniapp 一套代碼編譯到 H5、微信小程序和 Android App 三個(gè)平臺(tái)。對(duì)于校園圈這種以移動(dòng)端為主的場(chǎng)景Uniapp 的跨端能力可以把開(kāi)發(fā)效率提升一倍以上同時(shí) SpringBoot 的生態(tài)非常成熟做權(quán)限控制、文件上傳、定時(shí)任務(wù)這些通用能力都有現(xiàn)成的方案可以集成。從實(shí)際效果來(lái)看這個(gè)組合的收益非常明顯我的業(yè)務(wù)代碼只寫(xiě)了一套卻同時(shí)覆蓋了學(xué)生最常用的微信小程序和 Android App還順手把 H5 版本跑通了用于 PC 端管理。如果當(dāng)初選了原生開(kāi)發(fā)同樣的時(shí)間最多只能完成一個(gè)平臺(tái)。1.3 項(xiàng)目整體模塊劃分與信息流方向整個(gè)系統(tǒng)的功能模塊可以按照信息流向分成三個(gè)層面。用戶(hù)層是基礎(chǔ)包含微信授權(quán)登錄、手機(jī)號(hào)綁定、個(gè)人資料管理這一層為所有業(yè)務(wù)模塊提供統(tǒng)一身份體系。內(nèi)容層是核心校園集市、表白墻、論壇、失物招領(lǐng)四個(gè)模塊各自獨(dú)立但底層都依賴(lài)統(tǒng)一的內(nèi)容管理服務(wù)包括發(fā)布、編輯、刪除、審核、評(píng)論、點(diǎn)贊這些通用能力。運(yùn)營(yíng)層是保障包括管理員后臺(tái)的內(nèi)容審核、用戶(hù)禁言、分類(lèi)管理、數(shù)據(jù)統(tǒng)計(jì)等功能。從信息流方向來(lái)看用戶(hù)在小程序端發(fā)布內(nèi)容請(qǐng)求通過(guò) API 進(jìn)入后端后端完成身份校驗(yàn)、內(nèi)容合法性校驗(yàn)敏感詞過(guò)濾、圖片鑒黃、業(yè)務(wù)規(guī)則校驗(yàn)比如集市商品的分類(lèi)和價(jià)格格式寫(xiě)入數(shù)據(jù)庫(kù)后進(jìn)入待審核或直接發(fā)布狀態(tài)。其他用戶(hù)看到內(nèi)容后可以進(jìn)行評(píng)論、點(diǎn)贊、收藏等互動(dòng)操作。管理員在 Web 管理端可以查看所有內(nèi)容、處理舉報(bào)、下架違規(guī)內(nèi)容。這套設(shè)計(jì)的好處是六個(gè)業(yè)務(wù)模塊共享了同一套底層能力新增一個(gè)模塊時(shí)只需要配置分類(lèi)和業(yè)務(wù)規(guī)則不需要從零開(kāi)發(fā)一整套接口后續(xù)如果要擴(kuò)展課程資料分享、拼車(chē)、組隊(duì)等新場(chǎng)景成本會(huì)非常低。2. 數(shù)據(jù)庫(kù)設(shè)計(jì)六個(gè)功能模塊如何在一套表結(jié)構(gòu)下共存2.1 用戶(hù)、內(nèi)容、互動(dòng)的三核心表設(shè)計(jì)數(shù)據(jù)庫(kù)是整個(gè)項(xiàng)目的根基我一開(kāi)始就明確了設(shè)計(jì)原則所有業(yè)務(wù)模塊共享一套用戶(hù)體系所有內(nèi)容模塊共享一套內(nèi)容表互動(dòng)數(shù)據(jù)評(píng)論、點(diǎn)贊、收藏也統(tǒng)一處理。這種共性下沉、個(gè)性上浮的設(shè)計(jì)能最大程度避免每新增一個(gè)模塊就新建幾張表的窘境。核心的用戶(hù)表t_user設(shè)計(jì)如下id主鍵自增長(zhǎng)openid微信小程序登錄后的唯一標(biāo)識(shí)只在微信登錄時(shí)用到字段上建立唯一索引phone手機(jī)號(hào)用于綁定和找回賬號(hào)nickname昵稱(chēng)默認(rèn)為微信昵稱(chēng)avatar頭像地址role角色標(biāo)識(shí)0 普通用戶(hù)1 管理員status賬號(hào)狀態(tài)0 正常1 禁用create_time、update_time時(shí)間字段所有表都有這兩個(gè)字段便于排查問(wèn)題內(nèi)容方面我沒(méi)有為集市、表白墻、論壇、失物招領(lǐng)各自建一張內(nèi)容表而是設(shè)計(jì)了一張統(tǒng)一的內(nèi)容表t_contentid內(nèi)容IDuser_id發(fā)布者ID關(guān)聯(lián)用戶(hù)表type內(nèi)容類(lèi)型1 集市2 表白墻3 論壇4 失物招領(lǐng)title標(biāo)題集市商品名、論壇帖子標(biāo)題、失物招領(lǐng)物品名content正文內(nèi)容images圖片地址多個(gè)圖片用逗號(hào)分隔price價(jià)格字段僅集市和跳蚤市場(chǎng)使用其他類(lèi)型為 0category分類(lèi)信息比如集市里的數(shù)碼產(chǎn)品書(shū)籍教材生活用品contact聯(lián)系方式方便用戶(hù)直接溝通status內(nèi)容狀態(tài)0 待審核1 已發(fā)布2 已下架3 已刪除like_count、comment_count、view_count互動(dòng)計(jì)數(shù)冗余存儲(chǔ)避免每次統(tǒng)計(jì)都去查互動(dòng)表location失物招領(lǐng)模塊的地點(diǎn)信息通過(guò)type字段區(qū)分業(yè)務(wù)模塊用status字段控制內(nèi)容的生命周期用category字段做模塊內(nèi)的細(xì)分。這套設(shè)計(jì)讓六個(gè)模塊共用一套內(nèi)容查詢(xún)邏輯分頁(yè)列表、詳情查看、內(nèi)容審核都只需要寫(xiě)一套服務(wù)大大減少了重復(fù)代碼?；?dòng)方面設(shè)計(jì)了t_comment評(píng)論表和t_like點(diǎn)贊表。評(píng)論表記錄評(píng)論內(nèi)容、評(píng)論者、所屬內(nèi)容 ID 和父評(píng)論 ID支持樓中樓回復(fù)。點(diǎn)贊表的核心設(shè)計(jì)是防止重復(fù)點(diǎn)贊——user_id和content_id建立聯(lián)合唯一索引從數(shù)據(jù)庫(kù)層面保證一個(gè)用戶(hù)對(duì)一條內(nèi)容只能點(diǎn)贊一次。2.2 失物招領(lǐng)的獨(dú)特狀態(tài)機(jī)設(shè)計(jì)失物招領(lǐng)模塊和其他內(nèi)容模塊有一個(gè)本質(zhì)差異——它有明確的完結(jié)流程。一個(gè)失物招領(lǐng)發(fā)布后可能的狀態(tài)包括尋找中、已找到、已認(rèn)領(lǐng)、已撤銷(xiāo)。如果簡(jiǎn)單復(fù)用統(tǒng)一內(nèi)容表的狀態(tài)字段無(wú)法表達(dá)這種業(yè)務(wù)流轉(zhuǎn)。我的處理方式是失物招領(lǐng)內(nèi)容仍然存在t_content表中type4但額外設(shè)計(jì)了一張t_lost_found擴(kuò)展表記錄該內(nèi)容特有的業(yè)務(wù)屬性content_id關(guān)聯(lián)內(nèi)容表 IDitem_name物品名稱(chēng)lost_or_found類(lèi)型0 尋物1 招領(lǐng)location丟失或拾取的地點(diǎn)status0 進(jìn)行中1 已完成2 已撤銷(xiāo)complete_time完成時(shí)間這樣既保留了統(tǒng)一內(nèi)容表帶來(lái)的查詢(xún)便利又能針對(duì)失物招領(lǐng)做特殊業(yè)務(wù)處理。前端列表頁(yè)展示時(shí)根據(jù)lost_or_found字段區(qū)分展示尋物啟事和失物招領(lǐng)兩種卡片樣式詳情頁(yè)里如果狀態(tài)是已完成就展示完成時(shí)間和感謝語(yǔ)讓整個(gè)流程形成閉環(huán)。同樣的思路也應(yīng)用于集市模塊。商品上架-賣(mài)出下架-重新上架的狀態(tài)流轉(zhuǎn)通過(guò)t_content.status字段加集市擴(kuò)展表t_market_item的sold_status字段組合實(shí)現(xiàn)這樣的設(shè)計(jì)避免了對(duì)統(tǒng)一內(nèi)容表的頻繁狀態(tài)覆蓋。2.3 表白墻的匿名邏輯和內(nèi)容審核的關(guān)鍵實(shí)現(xiàn)表白墻和論壇有一個(gè)關(guān)鍵區(qū)別用戶(hù)發(fā)表白內(nèi)容時(shí)可以選擇匿名。這個(gè)匿名不是簡(jiǎn)單的昵稱(chēng)不顯示而是要保證評(píng)論和點(diǎn)贊時(shí)別人看不到用戶(hù)身份但管理員在后臺(tái)仍然能看到真實(shí)發(fā)布者方便處理惡意內(nèi)容。實(shí)現(xiàn)上我在t_content表中增加了一個(gè)is_anonymous字段。查詢(xún)內(nèi)容列表時(shí)如果該字段為 1則返回結(jié)果中的user_id置為 0、nickname置為匿名用戶(hù)、avatar置為默認(rèn)匿名頭像。這個(gè)邏輯在 SQL 層通過(guò)條件判斷實(shí)現(xiàn)也可以在 Service 層做數(shù)據(jù)脫敏處理。我選擇在 Service 層做一個(gè)公共的內(nèi)容脫敏方法所有模塊查詢(xún)內(nèi)容后都經(jīng)過(guò)這個(gè)方法處理避免每個(gè)接口都寫(xiě)一遍判斷邏輯。內(nèi)容審核方面我在后端實(shí)現(xiàn)了一個(gè)簡(jiǎn)單的敏感詞過(guò)濾工具類(lèi)。維護(hù)一個(gè)敏感詞列表發(fā)布內(nèi)容時(shí)先進(jìn)行文本匹配如果命中敏感詞根據(jù)嚴(yán)重程度決定是直接攔截還是轉(zhuǎn)人工審核。圖片審核調(diào)用云服務(wù)商的審核 API由于校園場(chǎng)景的特殊性圖片審核的閾值會(huì)比通用平臺(tái)更嚴(yán)格。所有待審核內(nèi)容進(jìn)入管理端的審核隊(duì)列管理員可以在 Web 后臺(tái)逐條查看、通過(guò)或駁回。2.4 索引設(shè)計(jì)和使用頻率最高的查詢(xún) SQL校園圈項(xiàng)目的查詢(xún)壓力集中在這幾個(gè)場(chǎng)景首頁(yè)信息流分頁(yè)、分類(lèi)列表分頁(yè)、我的發(fā)布列表、搜索。針對(duì)這些場(chǎng)景我設(shè)計(jì)了幾組關(guān)鍵索引idx_content_type_status(type, status)聯(lián)合索引這是內(nèi)容列表查詢(xún)最主要的索引按模塊和狀態(tài)過(guò)濾數(shù)據(jù)idx_content_user_id(user_id)索引查詢(xún)我的發(fā)布時(shí)使用idx_content_create_time(create_time)索引按時(shí)間排序的分頁(yè)場(chǎng)景使用idx_content_category_type(type, category)聯(lián)合索引分類(lèi)篩選場(chǎng)景idx_comment_content_id(comment_id)索引評(píng)論列表查詢(xún)idx_like_user_content(user_id, content_id)唯一索引既保證了防止重復(fù)點(diǎn)贊又能支撐我點(diǎn)贊過(guò)的內(nèi)容查詢(xún)列表頁(yè)的核心查詢(xún) SQL 大致長(zhǎng)這樣SELECT c.id, c.title, c.content, c.images, c.price, c.category, c.like_count, c.comment_count, c.create_time, u.nickname, u.avatar, u.id as user_id FROM t_content c LEFT JOIN t_user u ON c.user_id u.id WHERE c.type 1 AND c.status 1 ORDER BY c.create_time DESC LIMIT 10 OFFSET 0;這里用了 LEFT JOIN 獲取用戶(hù)信息。對(duì)于 10 萬(wàn)條數(shù)據(jù)量級(jí)的校園項(xiàng)目這套查詢(xún)配合索引響應(yīng)時(shí)間在毫秒級(jí)完全夠用。數(shù)據(jù)量再大的話可以引入 Redis 做熱數(shù)據(jù)緩存或者引入 ElasticSearch 做搜索但這是后話在項(xiàng)目初期不需要過(guò)度設(shè)計(jì)。3. SpringBoot 后端從接口設(shè)計(jì)到安全防護(hù)的完整落地3.1 項(xiàng)目分層結(jié)構(gòu)與統(tǒng)一返回格式的定義后端工程遵循標(biāo)準(zhǔn)的 SpringBoot 分層架構(gòu)Controller 層負(fù)責(zé)接口暴露Service 層負(fù)責(zé)業(yè)務(wù)邏輯Mapper 層負(fù)責(zé)數(shù)據(jù)庫(kù)操作。為了減少代碼量我引入了 MyBatis-Plus 作為 ORM 框架它的內(nèi)置 CRUD 方法和分頁(yè)插件可以省掉大部分基礎(chǔ) SQL 編寫(xiě)。一個(gè)容易被忽略但非常重要的設(shè)計(jì)是統(tǒng)一返回格式。所有接口的返回值都遵循同一個(gè)結(jié)構(gòu){ code: 200, message: success, data: {} }前端通過(guò)判斷code是否為 200 來(lái)決定業(yè)務(wù)流程是否繼續(xù)。如果接口報(bào)錯(cuò)code返回具體的錯(cuò)誤碼400 參數(shù)錯(cuò)誤、401 未登錄、403 無(wú)權(quán)限、500 服務(wù)器異常message返回給用戶(hù)看的提示信息。這個(gè)統(tǒng)一格式讓前端處理異常的邏輯變得非常簡(jiǎn)單——只要封裝一個(gè)請(qǐng)求工具統(tǒng)一攔截非 200 的響應(yīng)并彈出提示即可。分頁(yè)接口的返回格式也做了統(tǒng)一data字段固定包含records當(dāng)前頁(yè)數(shù)據(jù)、total總條數(shù)、current當(dāng)前頁(yè)碼、size每頁(yè)條數(shù)。3.2 JWT 登錄認(rèn)證的完整流程和 Token 過(guò)期處理校園圈項(xiàng)目采用 JWTJSON Web Token做登錄認(rèn)證。用戶(hù)通過(guò)微信登錄時(shí)后端拿著前端傳來(lái)的code去微信接口換取openid如果該openid已存在則直接登錄不存在則自動(dòng)注冊(cè)新用戶(hù)。登錄成功后后端生成一個(gè) JWT Token 返回給前端前端每次請(qǐng)求都在請(qǐng)求頭里帶上Authorization: Bearer [token]。JWT 的核心邏輯是在用戶(hù)登錄后把用戶(hù) ID 和角色等信息加密進(jìn)一個(gè) Token 字符串里服務(wù)端不再存儲(chǔ)會(huì)話信息。SpringBoot 后端通過(guò)攔截器或者過(guò)濾器統(tǒng)一解析請(qǐng)求頭里的 Token驗(yàn)證簽名取出用戶(hù) ID 和角色存入 ThreadLocal 供后續(xù)業(yè)務(wù)代碼使用。我對(duì)比了攔截器和過(guò)濾器兩種實(shí)現(xiàn)方式最終選擇了攔截器因?yàn)閿r截器可以更方便地配置放行路徑比如登錄接口、內(nèi)容列表接口不需要 Token而發(fā)布、點(diǎn)贊、評(píng)論接口需要 Token。Token 過(guò)期處理是個(gè)經(jīng)典問(wèn)題。JWT 默認(rèn)是把過(guò)期時(shí)間寫(xiě)在 Token 里的過(guò)期后前端拿舊 Token 請(qǐng)求接口會(huì)返回 401。我的方案是Token 有效期設(shè)置為 7 天前端在請(qǐng)求攔截器里判斷如果收到 401且當(dāng)前頁(yè)面不是登錄頁(yè)就跳轉(zhuǎn)到登錄頁(yè)重新授權(quán)。這個(gè)策略在校園場(chǎng)景下夠用用戶(hù)一般一周內(nèi)會(huì)多次打開(kāi)小程序不會(huì)頻繁需要重新登錄。如果需要更長(zhǎng)的免登錄周期可以引入 Refresh Token 機(jī)制但那屬于進(jìn)階設(shè)計(jì)校園項(xiàng)目前期不需要這么復(fù)雜。3.3 發(fā)布接口的參數(shù)校驗(yàn)與圖片上傳處理細(xì)節(jié)內(nèi)容發(fā)布是整個(gè)系統(tǒng)最核心的寫(xiě)操作。集市發(fā)布需要校驗(yàn)標(biāo)題、價(jià)格、分類(lèi)、描述失物招領(lǐng)需要校驗(yàn)物品名稱(chēng)、地點(diǎn)、類(lèi)型表白墻需要校驗(yàn)內(nèi)容長(zhǎng)度和敏感詞。這些校驗(yàn)如果在每個(gè)業(yè)務(wù)方法里都寫(xiě)一遍代碼會(huì)非常冗余。我的做法是在實(shí)體類(lèi)上使用 JSR-303 注解做基礎(chǔ)校驗(yàn)NotBlank、NotNull、Size等在 Controller 層配合Valid注解自動(dòng)完成參數(shù)校驗(yàn)業(yè)務(wù)方法里只需要做業(yè)務(wù)規(guī)則校驗(yàn)比如集市價(jià)格必須大于 0、失物招領(lǐng)狀態(tài)流轉(zhuǎn)是否合法。圖片上傳也是發(fā)布功能的重要環(huán)節(jié)。前端通過(guò) Uniapp 的uni.chooseImage選擇圖片調(diào)用后端上傳接口后端將圖片保存到服務(wù)器指定目錄返回圖片的訪問(wèn) URL。表面上看起來(lái)很簡(jiǎn)單但有幾個(gè)細(xì)節(jié)值得注意文件類(lèi)型白名單校驗(yàn)只允許 jpg、png、gif、webp 格式文件大小限制單張圖片不超過(guò) 5MB用戶(hù)端在上傳前先壓縮文件名重命名不用用戶(hù)原始文件名用 UUID 或時(shí)間戳重命名防止文件名沖突和路徑穿越攻擊圖片訪問(wèn)權(quán)限通過(guò)后端鑒權(quán)后生成臨時(shí) URL 訪問(wèn)防止資源被外部直接刷流量如果對(duì)安全要求沒(méi)那么高也可以直接放在靜態(tài)資源目錄下公開(kāi)訪問(wèn)我踩過(guò)的一個(gè)坑是 Nginx 上傳大小限制。默認(rèn) Nginx 的client_max_body_size是 1MB如果圖片傳到 Nginx 反向代理超過(guò) 1MB 的請(qǐng)求會(huì)被直接拒絕。需要手動(dòng)把配置改成client_max_body_size 10m才能解決。3.4 點(diǎn)贊、評(píng)論、瀏覽計(jì)數(shù)的并發(fā)安全實(shí)現(xiàn)互動(dòng)功能看起來(lái)簡(jiǎn)單但并發(fā)場(chǎng)景下容易出問(wèn)題。點(diǎn)贊的并發(fā)問(wèn)題通過(guò)數(shù)據(jù)庫(kù)唯一索引已經(jīng)解決了——重復(fù)點(diǎn)贊會(huì)插入失敗程序捕獲異常后返回友好提示即可。難點(diǎn)在計(jì)數(shù)更新。最初我用的是先查 count 再加一的邏輯在并發(fā)壓力下會(huì)出現(xiàn)丟失更新的問(wèn)題。后來(lái)改成了數(shù)據(jù)庫(kù)原子操作// 點(diǎn)贊時(shí)更新計(jì)數(shù) int updated contentMapper.increaseLikeCount(contentId); // SQL: UPDATE t_content SET like_count like_count 1 WHERE id #{contentId}這種寫(xiě)法把讀-改-寫(xiě)變成了數(shù)據(jù)庫(kù)層面的原子操作即使同一時(shí)間有 100 個(gè)人點(diǎn)贊計(jì)數(shù)也不會(huì)丟失。瀏覽量的設(shè)計(jì)更簡(jiǎn)單展示詳情時(shí)直接對(duì)view_count加一不做去重。對(duì)于校園項(xiàng)目瀏覽量本身就是一個(gè)營(yíng)銷(xiāo)指標(biāo)真實(shí)量級(jí)相比去重更重要。評(píng)論的并發(fā)問(wèn)題相對(duì)少主要是新增評(píng)論和刪除評(píng)論時(shí)的計(jì)數(shù)同步。刪除評(píng)論時(shí)先刪除評(píng)論記錄再原子更新內(nèi)容的comment_count減一。如果評(píng)論有子評(píng)論需要遞歸刪除這個(gè)操作放在事務(wù)里執(zhí)行保證數(shù)據(jù)一致性。4. Uniapp 跨端開(kāi)發(fā)的適配細(xì)節(jié)與核心頁(yè)面實(shí)現(xiàn)4.1 為什么 Uniapp 一套代碼能同時(shí)搞定小程序和 AppUniapp 的原理是把 Vue 語(yǔ)法編寫(xiě)的頁(yè)面通過(guò)編譯工具轉(zhuǎn)換成不同平臺(tái)的可執(zhí)行代碼。寫(xiě)小程序時(shí)編譯成 WXML/WXSS/JS寫(xiě) App 時(shí)編譯成原生應(yīng)用可運(yùn)行的代碼。開(kāi)發(fā)者使用 Vue 的語(yǔ)法和 Uniapp 提供的跨端 API底層差異由框架屏蔽。但這不意味著完全不用關(guān)心平臺(tái)差異。開(kāi)發(fā)中我遇到最典型的差異是登錄方式微信小程序里的登錄是uni.login獲取code然后傳給后端換openidApp 端沒(méi)有uni.login我用的是手機(jī)號(hào)驗(yàn)證碼登錄。針對(duì)這個(gè)差異我在登錄頁(yè)面根據(jù)#ifdef MP-WEIXIN和#ifdef APP-PLUS寫(xiě)了條件編譯代碼兩個(gè)平臺(tái)走不同的登錄流程對(duì)外暴露統(tǒng)一的登錄成功回調(diào)。另一個(gè)典型差異是存儲(chǔ)。小程序端用uni.setStorageSync存 Token 是沒(méi)有問(wèn)題的但 App 端如果 Token 涉及敏感數(shù)據(jù)建議使用plus.storage或者原生插件做安全存儲(chǔ)。因?yàn)榘踩燃?jí)不同我把 Token 這類(lèi)敏感信息的存儲(chǔ)單獨(dú)封裝了一個(gè)工具類(lèi)切換平臺(tái)時(shí)只改工具類(lèi)內(nèi)部實(shí)現(xiàn)業(yè)務(wù)代碼不用動(dòng)。4.2 首頁(yè)信息流、TabBar 導(dǎo)航與頁(yè)面棧設(shè)計(jì)校園圈有多個(gè) Tab首頁(yè)、集市、論壇、我的每個(gè) Tab 對(duì)應(yīng)一個(gè)獨(dú)立的頁(yè)面底部 TabBar 用 Uniapp 的pages.json配置。這里有一個(gè)設(shè)計(jì)取舍Tab 頁(yè)面之間用uni.switchTab切換而不是uni.navigateTo因?yàn)閟witchTab會(huì)保留頁(yè)面狀態(tài)用戶(hù)切換 Tab 后回來(lái)不會(huì)重新加載列表體驗(yàn)更好。首頁(yè)信息流的實(shí)現(xiàn)走的是后端分頁(yè)接口加前端觸底加載。滾動(dòng)容器用scroll-view還是頁(yè)面級(jí)滾動(dòng)這里要特別注意小程序里頁(yè)面級(jí)滾動(dòng)監(jiān)聽(tīng)觸底用onReachBottomscroll-view里用scrolltolower。兩種方式的性能表現(xiàn)有差異我最終選擇了頁(yè)面級(jí)滾動(dòng)配合onReachBottom實(shí)現(xiàn)更簡(jiǎn)單性能也更優(yōu)。集市列表頁(yè)因?yàn)樯婕吧唐房ㄆ?、價(jià)格展示、分類(lèi)篩選我把它做成了獨(dú)立頁(yè)面沒(méi)有放在首頁(yè)信息流里。首頁(yè)信息流采用內(nèi)容聚合策略后端一次性返回四種類(lèi)型的內(nèi)容按最新時(shí)間混合排序用戶(hù)在同一個(gè)流里能看到表白、二手、尋物等不同類(lèi)型的信息符合圈子的定位。4.3 圖片上傳前的壓縮處理與跨端兼容方案Uniapp 的uni.chooseImage在 H5、小程序、App 三個(gè)平臺(tái)的參數(shù)和行為有細(xì)微差異。最常用到的參數(shù)是count可選圖片數(shù)量、sizeType是否壓縮和sourceType相冊(cè)還是相機(jī)。小程序端支持sizeType: [compressed]會(huì)自動(dòng)壓縮圖片。但 App 端對(duì)sizeType的支持不一致有時(shí)傳了壓縮參數(shù)也沒(méi)效果。為了統(tǒng)一行為我封裝了自己的圖片選擇工具先調(diào)uni.chooseImage選圖拿到臨時(shí)路徑后在小程序端直接用uni.compressImage壓縮在 App 端調(diào)用plus.zip.compressImage壓縮。壓縮到 1280px 以?xún)?nèi)、質(zhì)量 80%單張圖片通?？梢詨旱?200KB 左右大大減輕了上傳壓力和存儲(chǔ)壓力。上傳時(shí)還要注意如果一次性上傳 9 張圖不要并行請(qǐng)求否則后端很容易收到大量并發(fā)請(qǐng)求導(dǎo)致超時(shí)。我是用遞歸的方式逐張上傳全部上傳完成后把返回的 URL 列表合并提交給發(fā)布接口。4.4 登錄狀態(tài)管理、路由守衛(wèi)和分享功能實(shí)現(xiàn)前端的登錄狀態(tài)管理我用了 Vuex 配合uni.setStorageSync持久化。用戶(hù)登錄成功后把用戶(hù)信息存入 Vuex同時(shí)寫(xiě)入本地存儲(chǔ)。每次啟動(dòng) App在 App.vue 的onLaunch生命周期里從本地存儲(chǔ)恢復(fù)登錄狀態(tài)到 Vuex。路由守衛(wèi)方面小程序的頁(yè)面跳轉(zhuǎn)沒(méi)有 Vue Router 那樣的全局守衛(wèi)我封裝了一個(gè)checkLogin工具函數(shù)在需要登錄的頁(yè)面的onShow或按鈕點(diǎn)擊事件里先判斷 Vuex 里的 Token 是否存在如果不存在就跳轉(zhuǎn)到登錄頁(yè)并記錄當(dāng)前頁(yè)面路徑登錄成功后可以自動(dòng)跳轉(zhuǎn)回來(lái)。關(guān)于分享功能這里有一個(gè)很多新手容易踩坑的細(xì)節(jié)微信小程序的分享默認(rèn)是分享當(dāng)前頁(yè)面點(diǎn)擊分享卡片打開(kāi)后只能打開(kāi)分享時(shí)所在的小程序頁(yè)面無(wú)法直接定位到具體的表白墻內(nèi)容頁(yè)。要實(shí)現(xiàn)分享帶參數(shù)的效果需要在onShareAppMessage里手動(dòng)拼上內(nèi)容 ID 作為參數(shù)onShareAppMessage() { return { title: this.detail.title, path: /pages/content/detail?id${this.detail.id} }; }App 端則更復(fù)雜涉及到plus.share的原生分享能力需要傳入分享圖片、標(biāo)題、URL 等參數(shù)。這塊我是在后期優(yōu)化時(shí)才完善的早期只實(shí)現(xiàn)了微信小程序端的分享。5. 校園圈項(xiàng)目的安全防護(hù)與性能優(yōu)化實(shí)踐5.1 接口防刷、SQL 注入和 XSS 攻擊的防御策略校園圈項(xiàng)目雖然面向校內(nèi)用戶(hù)但上線后同樣面臨各種惡意攻擊。接口防刷方面我在后端實(shí)現(xiàn)了一個(gè)簡(jiǎn)單的基于 Redis 的限流攔截器同一個(gè)用戶(hù)對(duì)同一個(gè)接口的請(qǐng)求頻率1 分鐘內(nèi)超過(guò) 30 次就返回操作太頻繁。對(duì)于發(fā)帖、評(píng)論這類(lèi)寫(xiě)接口頻率限制更嚴(yán)格1 分鐘最多 5 次。這樣能有效防止腳本大量灌水。SQL 注入方面MyBatis-Plus 的預(yù)編譯機(jī)制已經(jīng)能防御絕大部分注入攻擊。需要注意的坑是如果在 XML mapper 文件里使用了${}拼接參數(shù)就會(huì)重新引入注入風(fēng)險(xiǎn)。我統(tǒng)一約定所有參數(shù)傳遞都用#{}如果確實(shí)需要?jiǎng)討B(tài)表名或動(dòng)態(tài)排序字段用白名單校驗(yàn)——只允許傳入預(yù)設(shè)好的幾個(gè)值從源頭阻斷注入。XSS 攻擊是內(nèi)容社區(qū)的高發(fā)問(wèn)題。用戶(hù)發(fā)布內(nèi)容里如果帶有script標(biāo)簽或者事件屬性存儲(chǔ)后再渲染出來(lái)就會(huì)執(zhí)行惡意腳本。我的處理方案是后端在內(nèi)容入庫(kù)前對(duì)內(nèi)容做一次 XSS 過(guò)濾把、等危險(xiǎn)字符轉(zhuǎn)義。前端展示時(shí)跑的是經(jīng)過(guò)后端清洗后的安全內(nèi)容。有一個(gè)教訓(xùn)是初期我忽略了對(duì)images字段里的圖片 URL 做協(xié)議校驗(yàn)導(dǎo)致可以上傳javascript:開(kāi)頭的偽協(xié)議后來(lái)加了一層 URL 協(xié)議白名單校驗(yàn)只允許 http/https問(wèn)題才徹底解決。5.2 Redis 緩存熱門(mén)內(nèi)容和接口響應(yīng)優(yōu)化校園圈的數(shù)據(jù)訪問(wèn)有明顯的熱點(diǎn)效應(yīng)——首頁(yè)信息流被頻繁訪問(wèn)熱門(mén)帖子被反復(fù)打開(kāi)。為了提高響應(yīng)速度我引入了 Redis 作為緩存層。緩存策略是內(nèi)容列表接口在查詢(xún)數(shù)據(jù)庫(kù)之前先查 Redis 里有沒(méi)有緩存的數(shù)據(jù)如果有直接返回如果沒(méi)有查數(shù)據(jù)庫(kù)后寫(xiě)入緩存并設(shè)置過(guò)期時(shí)間比如 5 分鐘。這樣熱門(mén)列表的接口響應(yīng)時(shí)間從 300ms 左右降到了 20ms 以?xún)?nèi)用戶(hù)體驗(yàn)提升明顯。內(nèi)容詳情頁(yè)的緩存策略又不一樣。詳情頁(yè)的瀏覽量是實(shí)時(shí)更新的如果完全緩存會(huì)導(dǎo)致瀏覽量不漲。我的做法是內(nèi)容詳情只緩存 30 秒瀏覽量的增加通過(guò)異步方式更新到數(shù)據(jù)庫(kù)同時(shí)更新 Redis 里的計(jì)數(shù)。在校園用戶(hù)量級(jí)下這種準(zhǔn)實(shí)時(shí)的方案效果很好。但緩存方案也有一個(gè)需要注意的坑——緩存雪崩。如果在同一時(shí)間大量緩存同時(shí)過(guò)期請(qǐng)求會(huì)同時(shí)落到數(shù)據(jù)庫(kù)可能導(dǎo)致數(shù)據(jù)庫(kù)壓力驟增。我的緩解措施是設(shè)置緩存過(guò)期時(shí)間時(shí)加一個(gè)隨機(jī)偏移量比如 5 分鐘加 0~60 秒的隨機(jī)數(shù)避免緩存同時(shí)失效。5.3 管理后臺(tái)與用戶(hù)端的數(shù)據(jù)權(quán)限隔離校園圈的管理員后臺(tái)和用戶(hù)端是同一個(gè) SpringBoot 項(xiàng)目但接口路徑不同權(quán)限控制也不同。我使用 Spring Security 做權(quán)限控制配置了兩種角色ROLE_USER普通用戶(hù)和ROLE_ADMIN管理員。普通用戶(hù)的接口路徑以/api/user/**開(kāi)頭管理員的接口路徑以/api/admin/**開(kāi)頭通過(guò)注解PreAuthorize(hasRole(ADMIN))控制訪問(wèn)權(quán)限。這里有一個(gè)容易忽略的權(quán)限漏洞管理員的刪除接口、審核接口如果只做了角色校驗(yàn)沒(méi)做數(shù)據(jù)歸屬校驗(yàn)普通用戶(hù)只要拿到管理員接口的路徑偽造請(qǐng)求就能刪別人的內(nèi)容。所以我在管理員接口里除了做角色校驗(yàn)還通過(guò) Token 里的用戶(hù) ID 去查管理員表確認(rèn)操作人確實(shí)是有效管理員而不是僅僅依賴(lài) JWT 里的角色字段。前后端的數(shù)據(jù)權(quán)限隔離最終效果用戶(hù)端只能操作自己的內(nèi)容管理員端可以操作所有內(nèi)容但所有操作都有日志記錄方便追蹤問(wèn)題。5.4 從單機(jī)部署到前后端分離上線的完整步驟項(xiàng)目上線部署我選擇的方案是SpringBoot 后端打包成 JAR 包部署在云服務(wù)器上Uniapp 前端通過(guò) HBuilderX 發(fā)行微信小程序端上傳到微信公眾平臺(tái)審核發(fā)布App 端打包成 APK 或上傳到應(yīng)用商店。完整部署流程如下云服務(wù)器準(zhǔn)備我用的是一臺(tái) 2 核 4G 的 Linux 服務(wù)器安裝 JDK 8、MySQL 5.7、Redis、Nginx后端部署用 Maven 打包mvn clean package -DskipTests生成 JAR 包后通過(guò)nohup java -jar campus-circle.jar 后臺(tái)啟動(dòng)前端發(fā)布微信小程序端在 HBuilderX 里選擇發(fā)行-小程序-微信生成微信小程序代碼上傳到微信公眾平臺(tái)App 端選擇發(fā)行-原生App-云打包生成 APKNginx 配置反向代理將后端 API 路徑/api/反向代理到本地 8080 端口前端 H5 靜態(tài)資源直接由 Nginx 托管部署過(guò)程中最容易出問(wèn)題的環(huán)節(jié)是跨域。前端在開(kāi)發(fā)環(huán)境使用 HBuilderX 內(nèi)置瀏覽器時(shí)請(qǐng)求后端接口會(huì)存在跨域問(wèn)題我在后端配置了全局 CORS 允許跨域。但需要注意正式環(huán)境建議由 Nginx 代理轉(zhuǎn)發(fā)避免直接對(duì)公網(wǎng)開(kāi)放后端端口同時(shí)可以減少跨域引起的安全問(wèn)題。6. 從畢設(shè)到商用項(xiàng)目二次開(kāi)發(fā)方向與個(gè)人經(jīng)驗(yàn)總結(jié)6.1 六個(gè)模塊的功能邊界與擴(kuò)展空間這個(gè)項(xiàng)目的六個(gè)核心模塊雖然功能上已經(jīng)跑通了但距離一個(gè)真正成熟的校園社區(qū)產(chǎn)品還有不少距離。我自己梳理了后續(xù)可以擴(kuò)展的方向校園集市可以增加購(gòu)物車(chē)、訂單管理、在線聊天買(mǎi)賣(mài)雙方溝通、信用評(píng)價(jià)體系甚至可以對(duì)接校內(nèi)支付系統(tǒng)把跳蚤市場(chǎng)升級(jí)成真正的校園電商平臺(tái)失物招領(lǐng)可以增加基于地理位置的附近尋物推送當(dāng)用戶(hù)發(fā)布尋物啟事時(shí)系統(tǒng)自動(dòng)提醒附近的用戶(hù)論壇模塊可以增加話題標(biāo)簽、關(guān)注、熱榜等功能提升內(nèi)容分發(fā)效率整體可以考慮接入即時(shí)通訊 SDK實(shí)現(xiàn)用戶(hù)間的私信聊天增強(qiáng)社區(qū)互動(dòng)性6.2 部署上線后遇到的真實(shí)問(wèn)題和解決方案項(xiàng)目上線后我遇到了幾個(gè)前期設(shè)計(jì)時(shí)沒(méi)有預(yù)見(jiàn)到的問(wèn)題。第一個(gè)問(wèn)題是內(nèi)容審核的滯后性。早期所有內(nèi)容都需要管理員審核后才展示導(dǎo)致用戶(hù)體驗(yàn)很差——發(fā)個(gè)表白墻內(nèi)容要等幾個(gè)小時(shí)才顯示。后來(lái)改成先發(fā)后審策略新發(fā)布的內(nèi)容立即可見(jiàn)但被舉報(bào)超過(guò)一定次數(shù)后自動(dòng)隱藏管理員再人工復(fù)核。這個(gè)策略更符合校園場(chǎng)景的即時(shí)性需求也減輕了管理員的審核負(fù)擔(dān)。第二個(gè)問(wèn)題是圖片存儲(chǔ)空間的增長(zhǎng)。學(xué)生上傳的商品圖、失物招領(lǐng)圖每天都在增加服務(wù)器磁盤(pán)很快就吃緊了。我后來(lái)接入了阿里云 OSS 做對(duì)象存儲(chǔ)把圖片都遷移到 OSS 上利用它的生命周期管理策略定期將超過(guò) 180 天未訪問(wèn)的圖片轉(zhuǎn)儲(chǔ)到低頻訪問(wèn)存儲(chǔ)節(jié)省了大量成本。第三個(gè)問(wèn)題是小程序?qū)徍吮痪?。第一次提交小程序?qū)徍藭r(shí)因?yàn)楸戆讐δ苌婕坝脩?hù)生成內(nèi)容微信要求補(bǔ)充《互聯(lián)網(wǎng)信息服務(wù)承諾書(shū)》和內(nèi)容審核機(jī)制說(shuō)明。我補(bǔ)充了敏感詞過(guò)濾說(shuō)明和人工審核流程文檔后審核才通過(guò)。這個(gè)經(jīng)驗(yàn)在做類(lèi)似社交類(lèi)小程序時(shí)很值得提前準(zhǔn)備。6.3 這套架構(gòu)的通用性如何能遷移到什么場(chǎng)景嚴(yán)格來(lái)說(shuō)我做的不是一個(gè)校園圈項(xiàng)目而是一套帶用戶(hù)體系的內(nèi)容社區(qū)通用架構(gòu)。如果把type字段的值從集市、表白墻、論壇、失物招領(lǐng)換成租房、二手、拼車(chē)、招聘把用戶(hù)角色從學(xué)生換成小區(qū)業(yè)主或者公司員工這套系統(tǒng)的核心代碼幾乎無(wú)需改動(dòng)就能支撐一個(gè)新的社區(qū)產(chǎn)品。這也是我決定把數(shù)據(jù)庫(kù)設(shè)計(jì)單獨(dú)梳理出來(lái)的原因。數(shù)據(jù)庫(kù)設(shè)計(jì)決定了系統(tǒng)的上限——如果你的內(nèi)容表設(shè)計(jì)得只能支撐一種業(yè)務(wù)后續(xù)擴(kuò)展一個(gè)模塊就要重新建表、重新寫(xiě)接口那才是災(zāi)難。而如果一開(kāi)始就設(shè)計(jì)成統(tǒng)一內(nèi)容表 分類(lèi)字段 擴(kuò)展表的模式后續(xù)每新增一個(gè)業(yè)務(wù)場(chǎng)景只需要在配置中心增加一個(gè)分類(lèi)再針對(duì)特殊業(yè)務(wù)建一張擴(kuò)展表就完事了。我在設(shè)計(jì)t_content表時(shí)特意把type字段設(shè)計(jì)成可配置的并在后端寫(xiě)了一個(gè)內(nèi)容類(lèi)型配置類(lèi)。當(dāng)初的想法很簡(jiǎn)單以后不管是加課程資料還是拼車(chē)出行都只需要加一個(gè)類(lèi)型枚舉值然后寫(xiě)對(duì)應(yīng)的擴(kuò)展表和服務(wù)即可。這個(gè)設(shè)計(jì)在開(kāi)發(fā)階段幫了大忙因?yàn)楸戆讐图锌此仆耆煌臉I(yè)務(wù)其實(shí)共用了一套 CRUD 代碼。6.4 分享幾條我在這個(gè)項(xiàng)目中最深的體會(huì)第一不要把通用做成難用。起初我為了讓所有模塊共用一套內(nèi)容表把字段設(shè)計(jì)得非常抽象title、content、type這些名稱(chēng)結(jié)果到了寫(xiě)具體業(yè)務(wù)邏輯的時(shí)候每個(gè)模塊都要做大量 if-else 判斷。后來(lái)我把通用字段和個(gè)性字段分開(kāi)——通用字段放t_content個(gè)性字段放擴(kuò)展表代碼簡(jiǎn)潔了很多。好的設(shè)計(jì)是通用框架 可插拔擴(kuò)展而不是把所有東西都塞進(jìn)一張表里強(qiáng)行統(tǒng)一。第二跨端開(kāi)發(fā)的調(diào)試成本比想象中高。Uniapp 雖然一套代碼部署三端但每個(gè)端的調(diào)試方式和表現(xiàn)都有差異。小程序端可以通過(guò)微信開(kāi)發(fā)者工具調(diào)試App 端需要用 HBuilderX 的基座調(diào)試H5 端則直接在瀏覽器里調(diào)。我在開(kāi)發(fā)中遇到的問(wèn)題很大一部分是小程序端正常、App 端出現(xiàn)樣式錯(cuò)亂或者 API 不兼容這需要開(kāi)發(fā)者對(duì)各平臺(tái)的特性有一定了解。建議大家在掌握 Uniapp 基礎(chǔ)后盡早開(kāi)始多端聯(lián)調(diào)不要等全部功能開(kāi)發(fā)完再統(tǒng)一適配不然排錯(cuò)的成本會(huì)非常大。第三安全防護(hù)要前置不要上線了再補(bǔ)。我初期覺(jué)得校園項(xiàng)目沒(méi)什么攻擊價(jià)值很多安全策略都沒(méi)做結(jié)果上線后很快就遇到了刷帖、惡意評(píng)論和 XSS 注入的問(wèn)題。后來(lái)補(bǔ)這些安全策略花的時(shí)間比一開(kāi)始就做好要多得多。建議從項(xiàng)目第一天起就考慮登錄鑒權(quán)怎么做、參數(shù)校驗(yàn)怎么做、敏感詞過(guò)濾怎么做、內(nèi)容審核怎么做。這些都是內(nèi)容社區(qū)類(lèi)項(xiàng)目的基石不能指望以后再加。第四以終為始先想清楚運(yùn)營(yíng)需求再設(shè)計(jì)功能。校園圈這種項(xiàng)目技術(shù)實(shí)現(xiàn)只是基礎(chǔ)真正決定成敗的是運(yùn)營(yíng)規(guī)則。比如集市的二手交易是否需要擔(dān)保交易表白墻的匿名是否需要追溯失物招領(lǐng)的完成狀態(tài)由誰(shuí)標(biāo)記這些問(wèn)題如果不在設(shè)計(jì)階段想清楚開(kāi)發(fā)到一半再來(lái)改數(shù)據(jù)結(jié)構(gòu)工作量會(huì)翻倍。我在開(kāi)發(fā)前寫(xiě)了一份簡(jiǎn)單的產(chǎn)品需求文檔雖然只有幾頁(yè)但避免了后期的大規(guī)模返工這個(gè)習(xí)慣非常值得保留。這個(gè)校園圈項(xiàng)目從需求梳理、數(shù)據(jù)庫(kù)設(shè)計(jì)、后端開(kāi)發(fā)到前端適配、部署上線前后花了差不多二十天時(shí)間。中間踩過(guò)的坑從 Nginx 上傳大小限制到小程序?qū)徍吮痪苊恳粋€(gè)都是真實(shí)的成長(zhǎng)代價(jià)。如果你也準(zhǔn)備做類(lèi)似的校園社區(qū)項(xiàng)目希望這篇文章能幫你避開(kāi)我走過(guò)的彎路。哪怕只是某一個(gè)模塊的設(shè)計(jì)或者某一段代碼的實(shí)現(xiàn)給了你啟發(fā)那這篇整理就沒(méi)白寫(xiě)。本文還有配套的精品資源點(diǎn)擊獲取