先聊點(diǎn)實(shí)際的。微信小程序健身管理系統(tǒng)這個(gè)名字在各類畢設(shè)選題里出現(xiàn)頻率相當(dāng)高CSDN、GitHub上隨便一搜就是一大堆但真正能跑通、邏輯清晰、能經(jīng)得起答辯追問(wèn)的項(xiàng)目其實(shí)不多。這個(gè)題目之所以熱門是因?yàn)樗骖櫫恕扒岸私换フ故尽焙汀昂蠖藰I(yè)務(wù)邏輯”兩頭不管是小程序端還是管理端都有足夠的內(nèi)容可寫工作量飽滿技術(shù)棧也有一定的延展空間對(duì)本科畢設(shè)來(lái)說(shuō)是個(gè)非常合適的選題。我手頭這套基于微信小程序?qū)崿F(xiàn)的健身管理系統(tǒng)功能上覆蓋了用戶端和小程序內(nèi)部的管理端雙角色。用戶端主要解決“選課、約課、練后記錄”這條主鏈路管理端處理“課程排期、用戶審核、健身數(shù)據(jù)復(fù)核”這些偏后臺(tái)的事。整體技術(shù)路線走的是微信小程序原生 后端接口 MySQL 數(shù)據(jù)庫(kù)的經(jīng)典組合結(jié)構(gòu)清晰也方便后續(xù)擴(kuò)展。接下來(lái)我會(huì)把整套系統(tǒng)的設(shè)計(jì)思路、核心功能拆解、具體實(shí)現(xiàn)的關(guān)鍵代碼片段、踩坑記錄以及論文寫作時(shí)需要注意的要點(diǎn)一次性梳理清楚。1. 健身管理系統(tǒng)整體設(shè)計(jì)思路1.1 為什么選微信小程序而不是獨(dú)立App很多人在選題時(shí)會(huì)糾結(jié)健身管理系統(tǒng)用微信小程序做為什么不干脆做個(gè)App這個(gè)問(wèn)題的答案其實(shí)取決于使用場(chǎng)景和目標(biāo)用戶。健身管理系統(tǒng)面向的是健身房會(huì)員和運(yùn)營(yíng)人員。會(huì)員的典型動(dòng)作是翻看課程表、預(yù)約一節(jié)團(tuán)課、查看自己的鍛煉記錄。這些操作都是“低頻但必須隨時(shí)可用”的用戶不可能為了約一節(jié)瑜伽課專門下載一個(gè)幾十兆的App。微信小程序“用完即走”的特性恰好匹配這個(gè)場(chǎng)景在微信里搜索一下或掃個(gè)碼就能進(jìn)入預(yù)約完就退出下次需要時(shí)再打開(kāi)。從開(kāi)發(fā)成本上看小程序前端基于微信提供的組件體系和API開(kāi)發(fā)門檻低于原生App一套代碼在iOS和Android上都能跑不需要分別維護(hù)兩套工程。再加上微信生態(tài)本身就解決了登錄授權(quán)的問(wèn)題通過(guò)wx.login拿到code后端再用code換openid就能識(shí)別用戶身份省去了自己搭建賬號(hào)體系和短信驗(yàn)證的成本。還有一個(gè)很多人容易忽略的點(diǎn)健身管理系統(tǒng)作為畢設(shè)或課程設(shè)計(jì)項(xiàng)目小程序的形式更容易展示。答辯現(xiàn)場(chǎng)用微信掃一掃就能在手機(jī)上看效果比在電腦上啟動(dòng)一個(gè)模擬器要直觀得多。如果做成App還要考慮簽名、打包、安裝的問(wèn)題這些對(duì)于非專業(yè)安卓開(kāi)發(fā)的同學(xué)來(lái)說(shuō)都是額外的時(shí)間消耗。1.2 系統(tǒng)角色與核心功能劃分健身管理系統(tǒng)從業(yè)務(wù)上天然分成兩類角色普通用戶會(huì)員和健身管理員教練或運(yùn)營(yíng)人員。兩方在小程序端看到的界面和能執(zhí)行的操作完全不同。用戶端的核心功能我梳理下來(lái)主要圍繞三條主鏈路展開(kāi)看課瀏覽團(tuán)課課程列表查看課程詳情包括教練信息、上課時(shí)間、課程強(qiáng)度、剩余名額。約課選擇心儀的課程時(shí)間段進(jìn)行預(yù)約預(yù)約后在我的預(yù)約中查看狀態(tài)支持取消預(yù)約。記錄每次鍛煉結(jié)束后記錄訓(xùn)練內(nèi)容、時(shí)長(zhǎng)、消耗熱量系統(tǒng)對(duì)歷史記錄做統(tǒng)計(jì)分析用圖表展示每周的訓(xùn)練趨勢(shì)。管理端因?yàn)槭切〕绦騼?nèi)嵌的管理模式功能不追求大而全但必須覆蓋運(yùn)營(yíng)的基本訴求課程管理發(fā)布新課程、設(shè)置課程容量、管理排期。預(yù)約管理查看所有預(yù)約記錄處理異常預(yù)約統(tǒng)計(jì)約課率。用戶管理查看注冊(cè)用戶列表對(duì)用戶進(jìn)行備注或標(biāo)記。角色體系的劃分用一個(gè)role字段就能區(qū)分用戶表中role1是普通會(huì)員role2是管理員。管理員登錄后通過(guò)條件渲染切換導(dǎo)航欄和頁(yè)面入口不需要做復(fù)雜的路由攔截。當(dāng)然這只是前端層面的控制真正的權(quán)限校驗(yàn)必須放在后端接口里做這個(gè)后面在接口設(shè)計(jì)部分詳細(xì)說(shuō)。1.3 技術(shù)選型的考慮與得失這套系統(tǒng)的后端我選的是Node.js Express數(shù)據(jù)庫(kù)用MySQL。選這個(gè)組合的原因很簡(jiǎn)單JavaScript全棧前后端語(yǔ)言統(tǒng)一代碼寫起來(lái)順手而且Express的中間件機(jī)制做接口鑒權(quán)非常方便。如果你用的是Java Spring Boot或者Python Django本質(zhì)上沒(méi)區(qū)別只是語(yǔ)言層面的不同。選型時(shí)有一個(gè)原則需要守住選自己最熟悉、最快能出活的技術(shù)棧不要為了追求所謂的高并發(fā)、分布式去強(qiáng)行上微服務(wù)那是給自己找麻煩。微信小程序端用的是原生開(kāi)發(fā)沒(méi)有引入vant-weapp這類UI組件庫(kù)。原因是原生組件在小程序里的穩(wěn)定性最好自定義樣式的可控度也最高。雖然vant組件庫(kù)確實(shí)好看好用但引入后還會(huì)帶來(lái)樣式覆蓋、組件升級(jí)適配等額外問(wèn)題對(duì)于這種體量的項(xiàng)目原生寫法反而更省心。數(shù)據(jù)庫(kù)表設(shè)計(jì)是整個(gè)項(xiàng)目的地基我踩過(guò)一次坑后把表結(jié)構(gòu)重構(gòu)過(guò)一版最終的方案值得重點(diǎn)說(shuō)一下。2. 數(shù)據(jù)庫(kù)設(shè)計(jì)與核心接口實(shí)現(xiàn)2.1 核心數(shù)據(jù)表結(jié)構(gòu)健身管理系統(tǒng)最核心的表有四張用戶表、課程表、預(yù)約表、訓(xùn)練記錄表。另外還有一張管理員的公告表用來(lái)發(fā)布站內(nèi)通知功能不復(fù)雜但能讓系統(tǒng)顯得完整。用戶表字段并不需要很多核心字段是openid、nickname、avatar_url、phone、role。openid是用戶在小程序里的唯一標(biāo)識(shí)后端通過(guò)微信的code2Session接口換取它才是用戶身份的真正主鍵。nickname和avatar_url是用戶在小程序里主動(dòng)授權(quán)后獲取的個(gè)人信息。role區(qū)分用戶和管理員。課程表重點(diǎn)在于排期概念。一門實(shí)體課程比如“燃脂搏擊”一周可能有多節(jié)課每節(jié)課有自己獨(dú)立的時(shí)間段、教練、剩余名額所以課程表其實(shí)存儲(chǔ)的是“課程實(shí)例”字段包括course_name、coach_name、start_time、end_time、capacity、booked_count、difficulty、cover_url。booked_count是已預(yù)約人數(shù)每次有人成功預(yù)約就加1取消預(yù)約就減1前端詳情頁(yè)直接展示這個(gè)字段來(lái)判斷名額是否已滿。預(yù)約表存儲(chǔ)的是用戶和課程實(shí)例的多對(duì)多關(guān)系id、user_id、course_id、status、create_time。status字段有幾種取值0表示已取消、1表示已預(yù)約、2表示已完成。當(dāng)課程時(shí)間過(guò)去后用戶可以打卡確認(rèn)完成這時(shí)status更新為2。訓(xùn)練記錄表比較簡(jiǎn)單記錄用戶自主提交的訓(xùn)練數(shù)據(jù)user_id、exercise_type、duration_minutes、calories、record_date、remark。它的作用就是為統(tǒng)計(jì)圖表提供數(shù)據(jù)來(lái)源。2.2 預(yù)約狀態(tài)機(jī)設(shè)計(jì)預(yù)約是整個(gè)系統(tǒng)里業(yè)務(wù)邏輯最復(fù)雜的一個(gè)環(huán)節(jié)因?yàn)樗婕暗綘顟B(tài)流轉(zhuǎn)。我一開(kāi)始想得簡(jiǎn)單了以為只要一個(gè)status字段就夠了后來(lái)發(fā)現(xiàn)不行。比如用戶預(yù)約了一節(jié)課這節(jié)課還沒(méi)開(kāi)始用戶想取消這個(gè)狀態(tài)是“已預(yù)約但未開(kāi)始”可以取消。但如果這節(jié)課已經(jīng)結(jié)束了呢用戶就不能再取消了只能標(biāo)記完成或直接棄課。最終我設(shè)計(jì)了一套簡(jiǎn)單的預(yù)約狀態(tài)機(jī)一共四個(gè)狀態(tài)已預(yù)約status1預(yù)約成功課程未開(kāi)始此時(shí)用戶可以取消預(yù)約。已取消status0用戶主動(dòng)取消或管理員后臺(tái)取消名額釋放。已完成status2課程已結(jié)束且用戶完成了打卡這個(gè)狀態(tài)由用戶操作觸發(fā)。已過(guò)期status3課程結(jié)束但用戶未打卡系統(tǒng)定時(shí)任務(wù)自動(dòng)將這類預(yù)約標(biāo)記為已過(guò)期。這個(gè)設(shè)計(jì)在事務(wù)層面有幾個(gè)細(xì)節(jié)必須處理用戶發(fā)起預(yù)約時(shí)要判斷當(dāng)前時(shí)間是否已經(jīng)超過(guò)開(kāi)課時(shí)間如果超過(guò)了直接拒絕預(yù)約。還要判斷課程實(shí)例的booked_count是否小于capacity如果不小于說(shuō)明已經(jīng)約滿不能再約。這里容易踩的坑是并發(fā)問(wèn)題——兩個(gè)人同時(shí)提交預(yù)約都讀到剩余名額為1然后同時(shí)寫入預(yù)約記錄最終導(dǎo)致超賣。解決辦法是給booked_count的更新加一個(gè)條件UPDATE course SET booked_count booked_count 1 WHERE id ? AND booked_count capacity讓數(shù)據(jù)庫(kù)層面的原子操作來(lái)兜底。2.3 后端接口設(shè)計(jì)與權(quán)限校驗(yàn)后端接口統(tǒng)一以/api為前綴按模塊劃分路由。核心接口我整理了一張表方便對(duì)照接口路徑方法功能說(shuō)明權(quán)限要求/api/user/loginPOST微信登錄code換openid公開(kāi)/api/user/profileGET獲取當(dāng)前用戶信息用戶級(jí)/api/course/listGET獲取課程列表公開(kāi)/api/course/detailGET獲取課程詳情公開(kāi)/api/booking/createPOST創(chuàng)建預(yù)約用戶級(jí)/api/booking/cancelPOST取消預(yù)約用戶級(jí)/api/booking/listGET獲取我的預(yù)約列表用戶級(jí)/api/record/addPOST添加訓(xùn)練記錄用戶級(jí)/api/record/statsGET獲取統(tǒng)計(jì)圖表數(shù)據(jù)用戶級(jí)/api/admin/course/addPOST新增課程排期管理員/api/admin/booking/listGET查看全部預(yù)約管理員權(quán)限校驗(yàn)用的是最經(jīng)典的token方案。用戶登錄成功后后端返回一個(gè)自定義token前端把token存入wx.setStorageSync之后每個(gè)請(qǐng)求在header里帶上Authorization: Bearer token。后端寫一個(gè)認(rèn)證中間件從header里取出token解析出user_id和role掛載到req對(duì)象上。然后每個(gè)路由按需聲明權(quán)限等級(jí)// auth.js 中間件核心邏輯 const verifyToken (req, res, next) { const authHeader req.headers[authorization]; if (!authHeader || !authHeader.startsWith(Bearer )) { return res.status(401).json({ message: 未登錄 }); } const token authHeader.split( )[1]; try { const decoded jwt.verify(token, SECRET_KEY); req.userId decoded.userId; req.userRole decoded.role; next(); } catch (err) { return res.status(401).json({ message: token無(wú)效或已過(guò)期 }); } }; const requireAdmin (req, res, next) { if (req.userRole ! 2) { return res.status(403).json({ message: 無(wú)管理員權(quán)限 }); } next(); };前端頁(yè)面雖然做了角色區(qū)分但真正防住越權(quán)操作的是后端這層校驗(yàn)。管理端的接口必須加上requireAdmin不然任何人只要修改小程序的存儲(chǔ)數(shù)據(jù)就有權(quán)限調(diào)用管理接口這是開(kāi)發(fā)階段最容易忽視的安全漏洞。3. 小程序端核心功能實(shí)操3.1 登錄授權(quán)與用戶識(shí)別微信小程序的登錄流程跟普通Web網(wǎng)站的登錄完全不一樣。它沒(méi)有用戶名密碼的概念核心是微信的openid識(shí)別機(jī)制。具體流程是這樣的第一步小程序前端通過(guò)wx.login接口獲取一個(gè)臨時(shí)code這個(gè)code的有效期只有5分鐘而且只能用一次。第二步前端把code發(fā)給自己的后端接口后端拿到code后調(diào)用微信官方的code2Session接口用code換回openid和session_key。第三步后端拿著openid去數(shù)據(jù)庫(kù)里查用戶如果從來(lái)沒(méi)注冊(cè)過(guò)就自動(dòng)建一條新記錄。最后后端自己簽發(fā)一個(gè)token返回給前端前端存起來(lái)供后續(xù)請(qǐng)求使用。這里有一點(diǎn)值得注意wx.login拿到的code只能換一次openid如果換成功了你重新調(diào)用wx.login拿新code之前的code就失效了。所以在寫代碼時(shí)不要在一個(gè)頁(yè)面里反復(fù)調(diào)用wx.login應(yīng)該把登錄邏輯放到一個(gè)統(tǒng)一的入口處理。用戶昵稱頭像的獲取現(xiàn)在微信政策收緊后無(wú)法直接通過(guò)wx.getUserProfile無(wú)限次彈窗獲取了。新方案是在頁(yè)面里放一個(gè)按鈕用戶主動(dòng)點(diǎn)擊“授權(quán)頭像昵稱”后通過(guò)button的open-typechooseAvatar拿到頭像地址typenickname拿到昵稱輸入框。這兩塊的操作是小程序開(kāi)發(fā)里比較容易被卡住的點(diǎn)因?yàn)榕f接口在基礎(chǔ)庫(kù)版本升級(jí)后已經(jīng)不能用了。3.2 課程列表與預(yù)約流程實(shí)現(xiàn)課程列表是這個(gè)系統(tǒng)里用戶最常用的頁(yè)面。列表頁(yè)用onShow生命周期加載數(shù)據(jù)因?yàn)橛脩魪脑斍轫?yè)返回列表頁(yè)時(shí)名額可能已經(jīng)被搶占了需要刷新。我用wx.request請(qǐng)求課程列表接口把返回的數(shù)據(jù)渲染成卡片// courseList.js 關(guān)鍵請(qǐng)求邏輯 onShow() { this.fetchCourseList(); }, fetchCourseList() { wx.request({ url: ${BASE_URL}/api/course/list, method: GET, success: (res) { const list res.data.map((item) { // 計(jì)算課程狀態(tài)0-可預(yù)約 1-已約滿 2-已開(kāi)始 const now new Date(); const start new Date(item.start_time); let status 0; if (item.booked_count item.capacity) status 1; if (now start) status 2; return { ...item, status }; }); this.setData({ courseList: list }); } }); }預(yù)約按鈕的處理邏輯最核心的一點(diǎn)是先判斷狀態(tài)再調(diào)接口。前端判斷當(dāng)前課程是否可約后端再次判斷并做原子更新雙重校驗(yàn)。前端判斷是為了體驗(yàn)后端判斷是為了正確性。用戶點(diǎn)擊“立即預(yù)約”時(shí)先彈一次確認(rèn)框然后調(diào)預(yù)約接口。預(yù)約成功后不要急著跳轉(zhuǎn)直接把當(dāng)前課程的booked_count更新一下讓用戶立刻看到名額變化。如果接口返回“約滿了”之類的錯(cuò)誤彈toast提示并刷新列表。取消預(yù)約我額外加了一個(gè)時(shí)間限制開(kāi)課前30分鐘內(nèi)不允許取消。這個(gè)限制放在后端做前端只做展示。為什么因?yàn)橛脩舳藭r(shí)間可能不準(zhǔn)依賴用戶設(shè)備時(shí)間做業(yè)務(wù)判斷是危險(xiǎn)的以服務(wù)器時(shí)間為準(zhǔn)才是正確姿勢(shì)。3.3 訓(xùn)練打卡與圖表統(tǒng)計(jì)訓(xùn)練記錄模塊的價(jià)值在于給用戶一個(gè)正向反饋閉環(huán)。每次練完用戶錄入訓(xùn)練類型、時(shí)長(zhǎng)、消耗熱量這些數(shù)據(jù)累積起來(lái)就能用圖表展示趨勢(shì)。圖表功能我一開(kāi)始想用ec-canvasECharts的小程序版但后來(lái)發(fā)現(xiàn)項(xiàng)目體積會(huì)增加不少而且在小程序Canvas里的渲染效果在低端機(jī)上有點(diǎn)卡。最后我方案改成用CSS手繪簡(jiǎn)易柱狀圖雖然不如ECharts好看但勝在輕量、穩(wěn)定、零依賴。簡(jiǎn)化版的柱狀圖實(shí)現(xiàn)思路是后端返回一周內(nèi)每天的鍛煉時(shí)長(zhǎng)總和前端把七天數(shù)據(jù)渲染成七根豎條高度按比例計(jì)算view classchart view classbar-item wx:for{{weeklyStats}} wx:keyindex view classbar-value styleheight: {{item.percent}}%{{item.duration}}min/view view classbar-label{{item.label}}/view /view /view這里最需要注意的細(xì)節(jié)是percent字段的計(jì)算規(guī)則最長(zhǎng)的一天設(shè)為100%其他天數(shù)按比例換算而不是按所有天數(shù)的總和換算。如果按總和換算會(huì)出現(xiàn)一周只練了一次但柱子也頂?shù)胶芨叩那闆r視覺(jué)上會(huì)誤導(dǎo)用戶。統(tǒng)計(jì)接口的SQL其實(shí)也不復(fù)雜就是按日期分組求和SELECT DATE(record_date) AS record_day, SUM(duration_minutes) AS total_duration FROM fitness_record WHERE user_id ? AND record_date DATE_SUB(CURDATE(), INTERVAL 7 DAY) GROUP BY DATE(record_date) ORDER BY record_day4. 常見(jiàn)問(wèn)題與排查技巧實(shí)錄4.1 網(wǎng)絡(luò)請(qǐng)求失敗的排查清單小程序開(kāi)發(fā)中wx.request請(qǐng)求失敗是出現(xiàn)頻率最高的問(wèn)題。我總結(jié)過(guò)一張排查清單遇到請(qǐng)求失敗按順序查基本不跑偏第一域名是否配置到合法域名。開(kāi)發(fā)時(shí)可以在開(kāi)發(fā)者工具里勾選“不校驗(yàn)合法域名”但真機(jī)預(yù)覽時(shí)必須把后端域名加到小程序后臺(tái)的request合法域名列表里。很多人本地調(diào)試沒(méi)問(wèn)題一上真機(jī)就請(qǐng)求失敗九成是這個(gè)原因。需要注意這個(gè)小程序后臺(tái)有個(gè)“校驗(yàn)合法域名”的開(kāi)關(guān)如果域名沒(méi)有備案就算加進(jìn)去了也會(huì)校驗(yàn)失敗。第二請(qǐng)求頭是否缺少參數(shù)。后端接口要求必須在header里帶上token如果token沒(méi)存進(jìn)去或已過(guò)期后端返回401前端拿到錯(cuò)誤碼后沒(méi)有做統(tǒng)一處理就會(huì)表現(xiàn)為“請(qǐng)求失敗”。我的做法是在請(qǐng)求封裝里統(tǒng)一響應(yīng)401狀態(tài)自動(dòng)清除緩存的過(guò)期token并跳轉(zhuǎn)到登錄頁(yè)。第三WXS腳本里發(fā)起不了請(qǐng)求。WXS是在視圖層運(yùn)行的腳本它和JavaScript運(yùn)行環(huán)境是隔離的無(wú)法調(diào)用wx.request。有次我寫了個(gè)需求想在wxs里實(shí)時(shí)判斷課程是否開(kāi)始結(jié)果發(fā)現(xiàn)wxs里連new Date()都有兼容問(wèn)題更別提發(fā)請(qǐng)求了。正確的做法是在wxs里只做純計(jì)算判斷邏輯放到事件處理函數(shù)中。小程序請(qǐng)求封裝的推薦寫法是統(tǒng)一封裝一個(gè)request方法把baseURL、token注入、錯(cuò)誤碼處理都收攏到一處不要在每個(gè)頁(yè)面里直接裸調(diào)wx.request。這樣后面對(duì)接新接口、統(tǒng)一加loading效果都方便。4.2 緩存數(shù)據(jù)更新不及時(shí)的問(wèn)題關(guān)于緩存我踩過(guò)一個(gè)很典型的坑。課程列表數(shù)據(jù)在onShow里刷新了但課程詳情頁(yè)的數(shù)據(jù)是寫在onLoad里的。因?yàn)樾〕绦蝽?yè)面的onLoad在頁(yè)面實(shí)例創(chuàng)建時(shí)只執(zhí)行一次從詳情頁(yè)跳到列表頁(yè)再回來(lái)詳情頁(yè)不會(huì)重新觸發(fā)onLoad于是展示的還是舊數(shù)據(jù)。解決辦法是區(qū)分onLoad和onShow的職責(zé)第一次進(jìn)入頁(yè)面時(shí)拉取數(shù)據(jù)放在onLoad里從其他頁(yè)面返回需要刷新時(shí)把拉取動(dòng)作放在onShow里。具體場(chǎng)景里我會(huì)在詳情頁(yè)的onShow里判斷一個(gè)參數(shù)如果從預(yù)約成功的回調(diào)返回就刷新數(shù)據(jù)否則沿用原有數(shù)據(jù)。關(guān)于wx.setStorageSync緩存設(shè)置了過(guò)期時(shí)間的問(wèn)題小程序原生的Storage API不帶過(guò)期機(jī)制存進(jìn)去就一直在。如果不想讓某個(gè)緩存數(shù)據(jù)一直是臟數(shù)據(jù)可以在存入時(shí)附帶一個(gè)時(shí)間戳讀取時(shí)判斷const CACHE_KEY course_list; const CACHE_TTL 5 * 60 * 1000; // 5分鐘 function getCourseListFromCache() { const cached wx.getStorageSync(CACHE_KEY); if (!cached) return null; if (Date.now() - cached.timestamp CACHE_TTL) { wx.removeStorageSync(CACHE_KEY); return null; } return cached.data; }這種帶過(guò)期時(shí)間的緩存在課程列表這種對(duì)實(shí)時(shí)性要求不高的場(chǎng)景下很合適既能減少后端壓力又能避免用戶每次進(jìn)入都看到加載動(dòng)畫。4.3 組件層級(jí)的兼容性問(wèn)題實(shí)現(xiàn)底部導(dǎo)航欄時(shí)小程序原生的tabBar只能配置固定的兩個(gè)位置的功能頁(yè)。因?yàn)榻∩砉芾硐到y(tǒng)里有“首頁(yè)”“課程”“記錄”“我的”四個(gè)頁(yè)面剛好四個(gè)tab直接用原生tabBar完全沒(méi)有問(wèn)題。真正麻煩的是自定義導(dǎo)航欄。有些頁(yè)面需要根據(jù)滾動(dòng)位置調(diào)整導(dǎo)航欄背景色這種效果用原生導(dǎo)航欄實(shí)現(xiàn)不了要設(shè)置navigationStyle: custom。自定義后就涉及到狀態(tài)欄高度適配的問(wèn)題不同機(jī)型的頂部安全區(qū)高度不一樣。我用的是wx.getWindowInfo()獲取狀態(tài)欄高度再手動(dòng)加上自定義導(dǎo)航欄的高度const { statusBarHeight } wx.getWindowInfo(); this.setData({ navHeight: statusBarHeight 44 });這個(gè)44是navigationBar的標(biāo)準(zhǔn)高度。iPhone X系列和普通機(jī)型在這個(gè)值上沒(méi)有區(qū)別區(qū)別都在狀態(tài)欄高度上。如果適配不對(duì)會(huì)出現(xiàn)導(dǎo)航欄按鈕被劉海遮擋的問(wèn)題。還有textarea組件層級(jí)穿透的問(wèn)題在表單頁(yè)面需要錄入訓(xùn)練備注時(shí)textarea是原生組件層級(jí)高于普通view會(huì)出現(xiàn)z-index設(shè)了也沒(méi)用的現(xiàn)象。如果非要用textarea通常配合cover-view來(lái)解決。為了規(guī)避這個(gè)坑我在訓(xùn)練記錄頁(yè)面直接用input代替了textarea訓(xùn)練備注一般也就一句話input的單行輸入完全夠用也省了一堆適配工作。4.4 預(yù)約并發(fā)超賣問(wèn)題的處理開(kāi)發(fā)初期我模擬過(guò)兩個(gè)人同時(shí)搶同一個(gè)課程最后一個(gè)名額的情況果然出現(xiàn)了超賣——兩個(gè)人都預(yù)約成功了但課程容量只有20人最后booked_count變成了21。原因很簡(jiǎn)單我原本的邏輯是SELECT判斷名額再INSERT預(yù)約記錄中間有時(shí)間差兩個(gè)請(qǐng)求都通過(guò)了判斷。修復(fù)方式前面提到過(guò)用一條原子SQLconst updateResult await db.query( UPDATE course SET booked_count booked_count 1 WHERE id ? AND booked_count capacity, [courseId] ); if (updateResult.affectedRows 0) { return res.json({ message: 該課程已約滿 }); } // 只有更新成功才插入預(yù)約記錄這種樂(lè)觀鎖方案實(shí)現(xiàn)簡(jiǎn)單對(duì)課程預(yù)約這種場(chǎng)景完全夠用。如果硬要用Redis分布式鎖那是殺雞用牛刀而且還要額外部署Redis增加了項(xiàng)目的復(fù)雜度。5. 論文寫作與答辯準(zhǔn)備心得5.1 論文結(jié)構(gòu)怎么組織“項(xiàng)目源碼論文說(shuō)明”這個(gè)組合意味著論文說(shuō)明部分同樣很重要。很多人的項(xiàng)目能跑通但論文寫得一塌糊涂答辯時(shí)被老師一問(wèn)就露餡。我建議按以下結(jié)構(gòu)組織緒論講背景、意義、國(guó)內(nèi)外研究現(xiàn)狀。注意這個(gè)部分不要抄書重點(diǎn)寫清楚“為什么健身管理需要系統(tǒng)化”這個(gè)問(wèn)題。相關(guān)技術(shù)介紹微信小程序技術(shù)框架、Node.js技術(shù)棧、MySQL數(shù)據(jù)庫(kù)。寫技術(shù)介紹時(shí)注意不要只寫概念最好把“為什么選這個(gè)技術(shù)”“它解決什么問(wèn)題”寫透。需求分析功能性需求用戶端和管理端的用例圖、非功能性需求性能、安全、易用性。系統(tǒng)設(shè)計(jì)總體架構(gòu)圖、功能模塊設(shè)計(jì)、數(shù)據(jù)庫(kù)E-R圖、核心表結(jié)構(gòu)設(shè)計(jì)字段說(shuō)明。系統(tǒng)實(shí)現(xiàn)每個(gè)模塊的實(shí)現(xiàn)截圖配關(guān)鍵代碼說(shuō)明。代碼不需要全部貼貼核心片段加解釋即可。系統(tǒng)測(cè)試功能測(cè)試用例表、測(cè)試結(jié)果。測(cè)試部分一定要真實(shí)寫不要只寫“全部通過(guò)”要寫清楚測(cè)試了哪些場(chǎng)景、有沒(méi)有發(fā)現(xiàn)bug、怎么修復(fù)的。寫論文時(shí)有一個(gè)非常實(shí)用的建議先畫圖表再圍繞圖表寫文字。系統(tǒng)架構(gòu)圖、用例圖、時(shí)序圖、E-R圖這四張圖畫出來(lái)論文的核心骨架就定下來(lái)了。文字是在骨架上填肉的過(guò)程圖片可以自己做也可以用在線繪圖工具。5.2 數(shù)據(jù)庫(kù)設(shè)計(jì)的編寫要點(diǎn)論文里的數(shù)據(jù)庫(kù)設(shè)計(jì)部分不建議把所有表的所有字段都羅列一遍那樣太長(zhǎng)太啰嗦。正確姿勢(shì)是選擇最核心的表詳細(xì)說(shuō)明其他表用一張匯總表帶過(guò)。比如用戶表、課程表、預(yù)約表這三張表是系統(tǒng)最核心的業(yè)務(wù)表每張表單獨(dú)用一個(gè)表格列出字段名、數(shù)據(jù)類型、是否主鍵、是否為空、字段說(shuō)明。訓(xùn)練記錄表、公告表這些輔助表可以合并成一個(gè)表格展示。這樣既體現(xiàn)了設(shè)計(jì)深度又不至于讓論文變成數(shù)據(jù)庫(kù)字典。數(shù)據(jù)庫(kù)設(shè)計(jì)的圖示我用的是E-R圖。E-R圖不需要畫得有多精美關(guān)鍵是實(shí)體、屬性、聯(lián)系要理清楚。用戶和課程的預(yù)約關(guān)系是多對(duì)多通過(guò)預(yù)約表作為中間表來(lái)分解這個(gè)關(guān)系一定要在E-R圖里清楚表達(dá)出來(lái)很多答辯老師喜歡盯著E-R圖問(wèn)。5.3 答辯前的加試準(zhǔn)備答辯環(huán)節(jié)被問(wèn)得最多的問(wèn)題我整理過(guò)一份清單提前準(zhǔn)備基本都能應(yīng)對(duì)系統(tǒng)有哪些角色權(quán)限怎么控制的答用戶角色和管理員角色后端用JWT鑒權(quán)中間件控制管理接口額外校驗(yàn)角色字段。預(yù)約功能并發(fā)沖突怎么處理答數(shù)據(jù)庫(kù)原子更新條件判斷s booked_count capacity受影響行數(shù)為0則拒絕預(yù)約。數(shù)據(jù)庫(kù)為什么要設(shè)計(jì)預(yù)約表答因?yàn)橛脩艉驼n程是多對(duì)多關(guān)系需要中間表解除復(fù)雜關(guān)聯(lián)。token過(guò)期了怎么辦答前端攔截401響應(yīng)清除本地緩存跳轉(zhuǎn)登錄頁(yè)重新獲取token。系統(tǒng)有什么可以改進(jìn)的地方答可擴(kuò)展消息推送、引入ECharts做更豐富的可視化、部署到云服務(wù)器統(tǒng)一域名訪問(wèn)。還有一個(gè)容易被問(wèn)到的點(diǎn)登錄功能為什么要通過(guò)自己的后端中轉(zhuǎn)而不是小程序直接調(diào)微信接口換openid答案是安全因素。微信的code2Session接口需要用到AppSecret這個(gè)密鑰一旦暴露在小程序前端就等于公開(kāi)了任何人都能冒充你的小程序身份。所以必須由后端調(diào)用微信接口AppSecret只保存在后端環(huán)境變量里。6. 開(kāi)發(fā)過(guò)程中的時(shí)間與版本管理建議這個(gè)系統(tǒng)我一個(gè)人從數(shù)據(jù)庫(kù)設(shè)計(jì)到小程序上線調(diào)試前后用了三周半時(shí)間。時(shí)間分配大致是數(shù)據(jù)庫(kù)設(shè)計(jì)及表結(jié)構(gòu)優(yōu)化用了3天后端接口編碼和自測(cè)用了5天小程序前端頁(yè)面開(kāi)發(fā)用了7天前后端聯(lián)調(diào)和修Bug用了4天論文寫作和答辯準(zhǔn)備用了6天。版本管理一定要用Git哪怕只有一個(gè)人寫也要用。理由很簡(jiǎn)單你在加新功能時(shí)改著改著發(fā)現(xiàn)舊的邏輯更合理要回退有Git就一條git checkout命令的事。我第一版預(yù)約狀態(tài)機(jī)設(shè)計(jì)得過(guò)于復(fù)雜后來(lái)花了半天時(shí)間回退到簡(jiǎn)單四狀態(tài)方案。代碼提交時(shí)養(yǎng)成寫清晰message的習(xí)慣比如feat: 新增課程列表頁(yè)面、fix: 修復(fù)預(yù)約并發(fā)超賣問(wèn)題。習(xí)慣的養(yǎng)成對(duì)于論文里的“系統(tǒng)測(cè)試”章節(jié)也很有用因?yàn)槟憧梢苑璆it提交記錄來(lái)回憶什么時(shí)候修了哪些問(wèn)題。最后再分享一個(gè)實(shí)際開(kāi)發(fā)中的小技巧wx.request的timeout默認(rèn)是60000毫秒但有些接口在高并發(fā)下響應(yīng)慢。如果用戶看不到加載中的提示就會(huì)反復(fù)點(diǎn)擊預(yù)約按鈕造成重復(fù)請(qǐng)求?？梢栽陬A(yù)約接口里加一個(gè)冪等判斷同一用戶在同一秒內(nèi)重復(fù)提交相同課程預(yù)約直接返回“處理中”不要走第二次數(shù)據(jù)庫(kù)更新邏輯。健身管理系統(tǒng)這個(gè)項(xiàng)目邊界清晰、需求明確、技術(shù)棧常見(jiàn)用來(lái)做畢設(shè)或面試作品都很合適。希望這篇拆解能幫你把系統(tǒng)做得更扎實(shí)。