馬拉松報(bào)名這種場(chǎng)景放在微信小程序里做其實(shí)非常典型。跑團(tuán)需要報(bào)名、賽事方需要管理報(bào)名數(shù)據(jù)、選手要查號(hào)碼簿和比賽信息一個(gè)報(bào)名系統(tǒng)要同時(shí)面對(duì)這三類(lèi)角色。我最近剛陪一個(gè)做畢設(shè)的朋友把這個(gè)項(xiàng)目從0到1完整走了一遍從需求梳理到數(shù)據(jù)庫(kù)設(shè)計(jì)從前端頁(yè)面到后端接口中間踩了不少坑也總結(jié)出一套可以復(fù)用的實(shí)現(xiàn)思路。這篇就圍繞“基于微信小程序的馬拉松報(bào)名系統(tǒng)”這個(gè)題目把項(xiàng)目里真正值得花時(shí)間的部分拆開(kāi)講清楚產(chǎn)品流程、表結(jié)構(gòu)、支付對(duì)接、號(hào)碼簿生成、論文寫(xiě)法以及那些不實(shí)際做一遍根本發(fā)現(xiàn)不了的問(wèn)題。如果你是計(jì)算機(jī)相關(guān)專(zhuān)業(yè)的學(xué)生正準(zhǔn)備做這類(lèi)“小程序報(bào)名”方向的畢設(shè)或課設(shè)這篇可以直接當(dāng)項(xiàng)目實(shí)施參考。如果只是對(duì)小程序開(kāi)發(fā)感興趣想了解一個(gè)完整業(yè)務(wù)系統(tǒng)長(zhǎng)什么樣也可以看到從用戶(hù)點(diǎn)擊報(bào)名到訂單支付的完整鏈路。1. 報(bào)名系統(tǒng)到底在解決什么問(wèn)題先說(shuō)業(yè)務(wù)。馬拉松報(bào)名和普通的電商下單有本質(zhì)區(qū)別它賣(mài)的不是實(shí)物商品而是一個(gè)參賽名額還附帶參賽項(xiàng)目選擇、參賽者信息填報(bào)、支付、號(hào)碼簿分配、報(bào)名數(shù)據(jù)統(tǒng)計(jì)這一整條鏈路。這就決定了系統(tǒng)必須有兩個(gè)核心身份普通跑者和賽事管理員。1.1 業(yè)務(wù)角色與基本流程梳理普通跑者端的典型流程是打開(kāi)小程序看賽事列表進(jìn)入賽事詳情頁(yè)了解比賽時(shí)間、地點(diǎn)、項(xiàng)目和費(fèi)用選擇自己報(bào)名的項(xiàng)目填寫(xiě)姓名、身份證號(hào)、手機(jī)號(hào)、緊急聯(lián)系人、衣服尺碼等信息提交訂單并支付支付成功后在小程序里查看報(bào)名狀態(tài)和號(hào)碼簿。管理員端則是另一套邏輯創(chuàng)建賽事、配置參賽項(xiàng)目全馬、半馬、歡樂(lè)跑、維護(hù)賽事介紹和公告、查看報(bào)名人數(shù)、導(dǎo)出報(bào)名名單、發(fā)布比賽相關(guān)通知。把這兩個(gè)角色的流程畫(huà)出來(lái)整個(gè)系統(tǒng)的主線(xiàn)就清楚了。后端核心是處理“報(bào)名訂單”這條數(shù)據(jù)流前端核心是讓跑者用盡可能少的步驟完成報(bào)名。做需求分析時(shí)最容易漏掉的是“名額限制”和“未支付訂單超時(shí)釋放”這兩個(gè)隱性需求后面我會(huì)專(zhuān)門(mén)講實(shí)現(xiàn)方案。1.2 功能模塊劃分與小程序頁(yè)面地圖我最終把功能分成四個(gè)模塊賽事模塊展示賽事列表、賽事詳情、參賽項(xiàng)目列表支持分頁(yè)加載和賽事公告。報(bào)名模塊報(bào)名表單、參賽項(xiàng)目選擇、尺碼選擇、訂單創(chuàng)建、在線(xiàn)支付。訂單模塊訂單列表、訂單詳情、支付狀態(tài)、取消訂單、號(hào)碼簿查看。個(gè)人中心模塊用戶(hù)信息展示、頭像昵稱(chēng)修改、我的報(bào)名記錄、關(guān)于賽事的信息。對(duì)應(yīng)的微信小程序頁(yè)面結(jié)構(gòu)大致是pages/index/index賽事列表首頁(yè)pages/event/detail賽事詳情頁(yè)pages/apply/apply報(bào)名表單頁(yè)pages/order/list我的報(bào)名記錄列表pages/order/detail訂單詳情頁(yè)pages/user/user個(gè)人中心頁(yè)頁(yè)面不多但每個(gè)頁(yè)面之間的數(shù)據(jù)流轉(zhuǎn)關(guān)系需要注意。比如賽事詳情頁(yè)要能直接跳轉(zhuǎn)報(bào)名頁(yè)并把賽事ID和項(xiàng)目ID帶過(guò)去報(bào)名成功后要能跳轉(zhuǎn)訂單詳情頁(yè)而不是簡(jiǎn)單彈一個(gè)“報(bào)名成功”的提示。這些交互細(xì)節(jié)做得順暢整體體驗(yàn)才會(huì)加分。1.3 技術(shù)選型我為什么選原生小程序而不是uni-app現(xiàn)在做微信小程序繞不開(kāi)一個(gè)選擇用原生開(kāi)發(fā)者工具寫(xiě)還是用uni-app這類(lèi)跨端框架。很多項(xiàng)目都會(huì)在這上面糾結(jié)。uni-app的優(yōu)勢(shì)是“一套代碼多端復(fù)用”同一套代碼可以編譯到微信小程序、支付寶小程序還能打包成Android和iOS的App。如果你的項(xiàng)目有后續(xù)多端上線(xiàn)的計(jì)劃選uni-app是合理的。但代價(jià)是調(diào)試鏈路變長(zhǎng)很多微信原生能力比如某些隱私接口、實(shí)時(shí)日志需要通過(guò)條件編譯去兼容遇到問(wèn)題排查成本會(huì)高不少。我做這個(gè)項(xiàng)目用的是原生小程序開(kāi)發(fā)。原因很簡(jiǎn)單這個(gè)項(xiàng)目只看微信一個(gè)端用原生框架能直接吃到微信開(kāi)發(fā)者工具的全部調(diào)試能力和最新的API支持比如頭像昵稱(chēng)填寫(xiě)能力、wx.requestPayment支付、onReachBottom分頁(yè)加載等。更關(guān)鍵的是項(xiàng)目的論文里在寫(xiě)“技術(shù)選型”時(shí)原生開(kāi)發(fā)能給出更直接的論據(jù)不需要引入額外框架開(kāi)發(fā)調(diào)試路徑短后續(xù)維護(hù)成本低。如果是在校生做畢設(shè)我更建議選原生。答辯時(shí)老師大概率會(huì)問(wèn)“為什么不用uni-app”這時(shí)候可以回答uniapp適合跨端需求本項(xiàng)目只面向微信生態(tài)采用原生開(kāi)發(fā)可以充分利用微信提供的原生能力和調(diào)試工具降低依賴(lài)復(fù)雜度。這個(gè)回答既客觀又能體現(xiàn)你的思考。2. 數(shù)據(jù)庫(kù)設(shè)計(jì)與核心接口約定數(shù)據(jù)庫(kù)設(shè)計(jì)決定這個(gè)項(xiàng)目能做多深。很多人的報(bào)名系統(tǒng)做出來(lái)像“玩具項(xiàng)目”很大程度上是因?yàn)楸碓O(shè)計(jì)太簡(jiǎn)單只有一張用戶(hù)表加一張訂單表賽事信息寫(xiě)死在頁(yè)面里。但一個(gè)真正能用的馬拉松報(bào)名系統(tǒng)賽事、參賽項(xiàng)目、訂單必須是分表的還要考慮號(hào)碼簿、公告這些擴(kuò)展能力。2.1 核心數(shù)據(jù)表設(shè)計(jì)我最終設(shè)計(jì)了六張核心表用戶(hù)表、賽事表、參賽項(xiàng)目表、報(bào)名訂單表、號(hào)碼簿表、公告表。用戶(hù)表主要字段字段類(lèi)型說(shuō)明idbigint主鍵openidvarchar微信openid唯一nicknamevarchar用戶(hù)昵稱(chēng)avatarvarchar頭像URLmobilevarchar手機(jī)號(hào)created_atdatetime創(chuàng)建時(shí)間updated_atdatetime更新時(shí)間openid是用戶(hù)在小程序體系里的唯一身份標(biāo)識(shí)后端登錄時(shí)通過(guò)wx.login拿到code再調(diào)用微信的接口換成openid。這里有個(gè)容易被坑的地方一個(gè)微信用戶(hù)在不同小程序里openid不同如果后續(xù)要跨小程序共享用戶(hù)數(shù)據(jù)需要引入unionid普通報(bào)名場(chǎng)景用openid就夠了。賽事表和參賽項(xiàng)目表是我特別想強(qiáng)調(diào)的部分因?yàn)楹芏嗟谝淮巫龅娜藭?huì)把“馬拉松賽事”和“參賽項(xiàng)目”混在一起直接在賽事表里放一個(gè)“全程馬拉松”“半程馬拉松”的字符串字段。這會(huì)導(dǎo)致后面按項(xiàng)目統(tǒng)計(jì)報(bào)名人數(shù)、按項(xiàng)目分配號(hào)碼簿時(shí)非常痛苦。我的做法是拆成兩張表。賽事表存比賽的基本信息比賽名稱(chēng)、封面圖、介紹、舉辦時(shí)間、舉辦地點(diǎn)、賽事?tīng)顟B(tài)、總名額限制。參賽項(xiàng)目表存每個(gè)賽事下的具體項(xiàng)目與賽事是主從關(guān)系字段包括項(xiàng)目名稱(chēng)全馬/半馬/歡樂(lè)跑、距離、報(bào)名費(fèi)、報(bào)名開(kāi)始時(shí)間、報(bào)名截止時(shí)間、項(xiàng)目名額限制、當(dāng)前已報(bào)名人數(shù)。訂單表的字段是重頭戲直接關(guān)系到支付流程能否走通。我的訂單表核心字段包括訂單號(hào)、用戶(hù)ID、賽事ID、參賽項(xiàng)目ID、報(bào)名聯(lián)系人姓名、身份證號(hào)、手機(jī)號(hào)、緊急聯(lián)系人、衣服尺碼、訂單狀態(tài)、報(bào)名費(fèi)金額單位分、支付時(shí)間、創(chuàng)建時(shí)間、更新時(shí)間。這里強(qiáng)調(diào)一個(gè)字段設(shè)計(jì)細(xì)節(jié)金額一律用“分”存儲(chǔ)用整數(shù)類(lèi)型。很多新手用decimal(10,2)存微信支付的金額結(jié)果回調(diào)金額比較時(shí)因?yàn)榫葐?wèn)題對(duì)不上很折磨人。微信支付的金額單位本身就是分后臺(tái)存儲(chǔ)保持一致轉(zhuǎn)成元做展示就行。2.2 報(bào)名訂單狀態(tài)機(jī)訂單狀態(tài)是整個(gè)系統(tǒng)的核心每個(gè)狀態(tài)轉(zhuǎn)換都要有明確觸發(fā)條件。我的狀態(tài)定義如下PENDING_PAY待支付。用戶(hù)提交報(bào)名信息后生成。PAID已支付。支付回調(diào)成功后進(jìn)入。CANCELLED已取消。用戶(hù)主動(dòng)取消或超時(shí)未支付自動(dòng)取消。REFUNDING退款中。用戶(hù)需要退賽時(shí)申請(qǐng)。REFUNDED已退款。退款完成后進(jìn)入。狀態(tài)機(jī)圖如果用文字描述就是待支付可以走向已支付和已取消已支付可以走向退款中退款中最終走向已退款。已退款和已取消都是終態(tài)不允許再回到可支付狀態(tài)。業(yè)務(wù)邏輯上要特別注意“超時(shí)未支付釋放名額”這個(gè)動(dòng)作。用戶(hù)在報(bào)名頁(yè)填完信息、提交訂單后如果一直不支付訂單不能一直占著名額。常用的策略是15分鐘或30分鐘未支付自動(dòng)取消訂單并釋放報(bào)名名額。這個(gè)動(dòng)作可以用后端定時(shí)任務(wù)掃描實(shí)現(xiàn)后面我會(huì)講具體實(shí)現(xiàn)。2.3 后端核心接口設(shè)計(jì)后端接口采用RESTful風(fēng)格返回統(tǒng)一的JSON結(jié)構(gòu)格式大致是{code, message, data}。接口按模塊劃分賽事模塊GET /api/event/list賽事分頁(yè)列表入?yún)age和sizeGET /api/event/{id}賽事詳情同時(shí)返回該賽事下的參賽項(xiàng)目列表報(bào)名模塊POST /api/order/create創(chuàng)建報(bào)名訂單POST /api/pay/params/{orderNo}獲取微信支付參數(shù)GET /api/order/detail/{orderNo}訂單詳情GET /api/order/list我的報(bào)名訂單列表POST /api/order/cancel取消訂單用戶(hù)模塊GET /api/user/info獲取用戶(hù)信息PUT /api/user/info更新用戶(hù)信息號(hào)碼簿模塊GET /api/user/bib/{orderNo}查看訂單對(duì)應(yīng)號(hào)碼簿接口設(shè)計(jì)里有個(gè)關(guān)鍵點(diǎn)需要用戶(hù)登錄態(tài)的接口后端在請(qǐng)求頭里約定一個(gè)Authorization字段存放登錄憑證。小程序端每次請(qǐng)求時(shí)帶上這個(gè)憑證后端通過(guò)攔截器統(tǒng)一校驗(yàn)。不要在每個(gè)接口里去判斷登錄狀態(tài)那樣代碼會(huì)散得到處都是。3. 小程序端核心功能的實(shí)現(xiàn)細(xì)節(jié)小程序端的實(shí)現(xiàn)質(zhì)量直接影響用戶(hù)對(duì)系統(tǒng)的第一印象。這一節(jié)挑幾個(gè)最有代表性的功能點(diǎn)展開(kāi)都是可以真正落地到代碼里的經(jīng)驗(yàn)。3.1 賽事列表分頁(yè)加載與緩存策略賽事列表頁(yè)是用戶(hù)打開(kāi)小程序看到的第一屏需要同時(shí)處理兩個(gè)問(wèn)題列表數(shù)據(jù)量大了之后不能一次性加載全部以及用戶(hù)反復(fù)進(jìn)入頁(yè)面時(shí)不能每次都重新請(qǐng)求接口。分頁(yè)加載用小程序原生的onReachBottom配合頁(yè)碼實(shí)現(xiàn)。初始page1每次請(qǐng)求返回?cái)?shù)據(jù)和hasMore標(biāo)記。當(dāng)頁(yè)面滾動(dòng)到底部觸發(fā)onReachBottom時(shí)判斷hasMore且當(dāng)前不在加載中就把page1再去請(qǐng)求。這里有個(gè)小細(xì)節(jié)請(qǐng)求期間要加一個(gè)loading標(biāo)志防止用戶(hù)快速滾動(dòng)時(shí)重復(fù)觸發(fā)請(qǐng)求。等請(qǐng)求回來(lái)再拼接到原有列表后面。緩存策略上我對(duì)賽事列表做了5分鐘緩存。緩存的實(shí)現(xiàn)不是簡(jiǎn)單的wx.setStorageSync存數(shù)據(jù)而是存一個(gè)帶過(guò)期時(shí)間的對(duì)象const CACHE_KEY event_list_cache const EXPIRE_TIME 5 * 60 * 1000 function getEventListCache() { const cache wx.getStorageSync(CACHE_KEY) if (!cache || !cache.expireTime) return null if (Date.now() cache.expireTime) { wx.removeStorageSync(CACHE_KEY) return null } return cache.data } function setEventListCache(data) { wx.setStorageSync(CACHE_KEY, { data, expireTime: Date.now() EXPIRE_TIME }) }這個(gè)做法在論文里能當(dāng)一個(gè)小亮點(diǎn)寫(xiě)上通過(guò)本地緩存減少不必要的網(wǎng)絡(luò)請(qǐng)求優(yōu)化用戶(hù)體驗(yàn)。3.2 報(bào)名表單信息校驗(yàn)與尺碼選擇報(bào)名表單是收集用戶(hù)信息的關(guān)鍵頁(yè)面。馬拉松報(bào)名必須收集的信息包括姓名、身份證號(hào)、手機(jī)號(hào)、緊急聯(lián)系人、參賽項(xiàng)目、衣服尺碼。我還在表單里加了“本人已閱讀并同意《參賽聲明》”的勾選這個(gè)是線(xiàn)下賽事報(bào)名的基本要求。身份證號(hào)校驗(yàn)這里要提一句不要只做正則的長(zhǎng)度和格式判斷真正有校驗(yàn)?zāi)芰Φ氖巧矸葑C第18位校驗(yàn)碼算法。簡(jiǎn)單說(shuō)就是前17位乘上對(duì)應(yīng)權(quán)重求和再對(duì)11取模得到校驗(yàn)碼。這個(gè)算法網(wǎng)上有公開(kāi)的標(biāo)準(zhǔn)實(shí)現(xiàn)用一小段函數(shù)就能校驗(yàn)身份證號(hào)真?zhèn)?。答辯時(shí)如果老師問(wèn)起身份證校驗(yàn)怎么做能說(shuō)出這個(gè)算法是很大的加分項(xiàng)。參賽項(xiàng)目在報(bào)名頁(yè)用radio-group實(shí)現(xiàn)每個(gè)項(xiàng)目顯示名稱(chēng)、距離和價(jià)格。衣服尺碼用按鈕組實(shí)現(xiàn)讓用戶(hù)點(diǎn)選。這里有個(gè)交互細(xì)節(jié)進(jìn)入頁(yè)面時(shí)先通過(guò)賽事詳情接口把項(xiàng)目列表拉下來(lái)緩存到頁(yè)面data里用戶(hù)選好項(xiàng)目后價(jià)格自動(dòng)聯(lián)動(dòng)顯示。注意不能把項(xiàng)目列表寫(xiě)死在代碼里因?yàn)椴煌愂碌捻?xiàng)目配置完全不同。在用戶(hù)點(diǎn)擊“提交訂單”時(shí)前端要做一次完整的表單校驗(yàn)。校驗(yàn)規(guī)則至少包括姓名不能為空、身份證號(hào)格式正確、手機(jī)號(hào)符合11位規(guī)則、緊急聯(lián)系人和手機(jī)號(hào)不能為空、已勾選同意聲明。校驗(yàn)通過(guò)后再調(diào)用創(chuàng)建訂單接口。后端接口里也要再校驗(yàn)一遍因?yàn)榍岸诵ｒ?yàn)可以被繞過(guò)后端必須作為安全邊界。3.3 支付流程從下單到支付回調(diào)支付是整個(gè)系統(tǒng)里最容易被卡住的環(huán)節(jié)。完整流程是這樣的第一步用戶(hù)在前端提交報(bào)名信息前端調(diào)用POST /api/order/create后端生成訂單狀態(tài)為PENDING_PAY返回訂單號(hào)。第二步前端拿到訂單號(hào)后請(qǐng)求POST /api/pay/params/{orderNo}。后端調(diào)用微信支付的“統(tǒng)一下單”接口傳入appid、商戶(hù)號(hào)、openid、訂單號(hào)、金額單位分、商品描述、回調(diào)通知地址等參數(shù)。微信返回prepay_id后后端再按微信規(guī)范生成二次簽名把timeStamp、nonceStr、package、signType、paySign這幾個(gè)參數(shù)返回給前端。第三步前端拿到參數(shù)后調(diào)用wx.requestPayment拉起收銀臺(tái)。第四步用戶(hù)支付成功后微信服務(wù)器會(huì)異步通知你配置的回調(diào)地址。后端在回調(diào)接口里對(duì)簽名做驗(yàn)簽驗(yàn)簽通過(guò)后更新訂單狀態(tài)為PAID同時(shí)在同一個(gè)事務(wù)里生成號(hào)碼簿記錄。這里有一個(gè)極容易踩坑的點(diǎn)支付回調(diào)不是只通知一次微信會(huì)重試多次而且回調(diào)的到達(dá)順序不一定和用戶(hù)支付順序一致。所以回調(diào)處理必須是冪等的。我的實(shí)現(xiàn)方式是在回調(diào)里先查訂單當(dāng)前狀態(tài)如果已經(jīng)是PAID就直接返回成功不再重復(fù)更新。還可以在訂單表上加一個(gè)唯一索引來(lái)兜底防止并發(fā)重復(fù)更新。另一個(gè)容易踩坑的點(diǎn)是前端不能用wx.requestPayment的返回值判斷支付結(jié)果因?yàn)橛脩?hù)可以在收銀臺(tái)里直接關(guān)閉頁(yè)面這時(shí)候requestPayment會(huì)報(bào)錯(cuò)但訂單可能已經(jīng)支付成功了。正確的做法是支付完成后前端主動(dòng)跳到訂單詳情頁(yè)由后端根據(jù)訂單狀態(tài)決定展示“待支付”還是“已支付”。我在項(xiàng)目里做的是支付回調(diào)發(fā)起后延遲一秒前端輪詢(xún)訂單詳情接口拿到最新?tīng)顟B(tài)再刷新頁(yè)面體驗(yàn)比較穩(wěn)。3.4 我的報(bào)名訂單列表與號(hào)碼簿展示“我的報(bào)名”本質(zhì)上是一個(gè)訂單列表按時(shí)間倒序展示用戶(hù)的所有報(bào)名記錄。每條記錄顯示賽事名稱(chēng)、參賽項(xiàng)目、訂單狀態(tài)、報(bào)名費(fèi)。點(diǎn)擊可以進(jìn)入訂單詳情頁(yè)。訂單詳情頁(yè)除了顯示訂單信息外還有一個(gè)關(guān)鍵功能已支付訂單要展示號(hào)碼簿。號(hào)碼簿樣式模擬線(xiàn)下馬博會(huì)領(lǐng)取的參賽號(hào)碼布上面顯示選手姓名、參賽項(xiàng)目和號(hào)碼。號(hào)碼的生成邏輯放在后端生成時(shí)機(jī)是支付成功的回調(diào)里這樣可以保證號(hào)碼在用戶(hù)支付成功的瞬間就已經(jīng)分配好用戶(hù)刷新訂單詳情就能看到。訂單狀態(tài)在頁(yè)面上的展示需要做狀態(tài)文案映射。比如待支付顯示“去支付”按鈕已支付顯示“已報(bào)名”狀態(tài)標(biāo)簽已取消顯示“已取消”。這里不要在前端寫(xiě)死狀態(tài)判斷可以把狀態(tài)碼和文案的映射關(guān)系放在一個(gè)統(tǒng)一的工具文件里后面維護(hù)起來(lái)省事。4. 后端能力與管理員側(cè)實(shí)現(xiàn)很多畢設(shè)項(xiàng)目把后端寫(xiě)成“接口轉(zhuǎn)發(fā)器”這是很吃虧的。一個(gè)報(bào)名系統(tǒng)如果要有競(jìng)爭(zhēng)力必須在后端體現(xiàn)業(yè)務(wù)邏輯比如名額管理、訂單超時(shí)處理、號(hào)碼簿生成、報(bào)名數(shù)據(jù)統(tǒng)計(jì)。這些都可以成為論文里的核心章節(jié)。4.1 后端工程結(jié)構(gòu)與技術(shù)選擇我個(gè)人做這個(gè)項(xiàng)目用的后端是Spring Boot MyBatis-Plus數(shù)據(jù)庫(kù)是MySQLRedis用作緩存和分布式鎖。微信支付相關(guān)邏輯用官方SDK封裝成WechatPayService。工程目錄按模塊分包src/main/java/com/example/marathon ├── controller // 接口層 ├── service // 業(yè)務(wù)邏輯層 ├── mapper // 數(shù)據(jù)訪問(wèn)層 ├── entity // 數(shù)據(jù)庫(kù)實(shí)體 ├── dto // 請(qǐng)求和響應(yīng)對(duì)象 ├── config // 全局配置、微信支付配置 ├── common // 統(tǒng)一返回、異常處理 ├── task // 定時(shí)任務(wù) └── utils // 工具類(lèi)分包清晰至少有兩個(gè)好處一是寫(xiě)論文時(shí)可以畫(huà)工程架構(gòu)圖二是改代碼時(shí)不會(huì)出現(xiàn)“所有代碼都在一個(gè)類(lèi)里”的窘境。4.2 心血管級(jí)并發(fā)名額扣減與超時(shí)釋放馬拉松報(bào)名有一個(gè)很現(xiàn)實(shí)的并發(fā)問(wèn)題熱門(mén)賽事名額有限大量跑者同時(shí)報(bào)名系統(tǒng)不能超賣(mài)。常規(guī)做法有兩種。第一種是數(shù)據(jù)庫(kù)樂(lè)觀鎖思路在參賽項(xiàng)目表上維護(hù)一個(gè)current_enrolled字段更新時(shí)帶上名額判斷UPDATE event_item SET current_enrolled current_enrolled 1 WHERE id #{itemId} AND current_enrolled max_enrolled如果更新返回的影響行數(shù)為1說(shuō)明扣減成功如果影響行數(shù)為0說(shuō)明名額已經(jīng)被搶完。這個(gè)SQL本身就是原子操作不需要額外加鎖。第二種是Redis Lua腳本扣減適合更大并發(fā)場(chǎng)景。但一個(gè)畢設(shè)項(xiàng)目用數(shù)據(jù)庫(kù)的原子更新其實(shí)已經(jīng)足夠了把current_enrolled max_enrolled這個(gè)條件寫(xiě)在SQL里是性?xún)r(jià)比最高的方案。我在代碼實(shí)現(xiàn)里用的就是第一種。超時(shí)未支付釋放名額的做法是訂單表在創(chuàng)建時(shí)記錄expire_time字段值等于當(dāng)前時(shí)間加15分鐘。后端用定時(shí)任務(wù)每?jī)煞昼姃呙枰淮握页鏊袪顟B(tài)為PENDING_PAY且expire_time小于當(dāng)前時(shí)間的訂單將其置為CANCELLED同時(shí)把參賽項(xiàng)目的current_enrolled扣回去?？刍厝サ腟QL是反向操作UPDATE event_item SET current_enrolled current_enrolled - 1 WHERE id #{itemId} AND current_enrolled 0這里要注意釋放名額和取消訂單需要放在同一個(gè)事務(wù)里避免出現(xiàn)訂單取消了但名額沒(méi)釋放的數(shù)據(jù)不一致問(wèn)題。4.3 號(hào)碼簿生成規(guī)則號(hào)碼簿是一個(gè)有儀式感的功能實(shí)現(xiàn)起來(lái)也不復(fù)雜。我的生成規(guī)則是賽事編碼 項(xiàng)目代碼 四位序列號(hào)。比如賽事編碼是M2025全馬項(xiàng)目代碼是A第一位通過(guò)報(bào)名的全馬選手號(hào)碼就是M2025A0001。具體實(shí)現(xiàn)是在支付回調(diào)成功的事務(wù)里查出當(dāng)前項(xiàng)目和賽事的編碼信息查該項(xiàng)目下已有的報(bào)名人數(shù)然后加1生成新的號(hào)碼。號(hào)碼生成后寫(xiě)入號(hào)碼簿表以后用戶(hù)查詢(xún)直接讀這張表就行。號(hào)碼簿還有一個(gè)細(xì)節(jié)在生成時(shí)順帶生成一個(gè)二維碼鏈接內(nèi)容是查號(hào)碼的頁(yè)面地址。線(xiàn)下賽事時(shí)工作人員掃碼可以核對(duì)選手信息。這個(gè)功能可以寫(xiě)進(jìn)論文作為系統(tǒng)亮點(diǎn)比單純的“增刪改查”項(xiàng)目高級(jí)不少。4.4 管理員統(tǒng)計(jì)與導(dǎo)出管理員端的核心價(jià)值是數(shù)據(jù)統(tǒng)計(jì)和導(dǎo)出。統(tǒng)計(jì)包括總報(bào)名人數(shù)、各項(xiàng)目報(bào)名人數(shù)、每日新增報(bào)名趨勢(shì)、訂單支付率。導(dǎo)出功能可以把報(bào)名名單導(dǎo)出為Excel方便賽事方線(xiàn)下使用字段包括姓名、身份證號(hào)、手機(jī)號(hào)、緊急聯(lián)系人、參賽項(xiàng)目、衣服尺碼、號(hào)碼簿號(hào)碼。導(dǎo)出用EasyExcel或者POI都可以。實(shí)現(xiàn)邏輯很簡(jiǎn)單查詢(xún)訂單列表把數(shù)據(jù)映射成Excel的每一行輸出到流。關(guān)鍵是導(dǎo)出條件要給夠管理員可以按賽事、按項(xiàng)目、按支付狀態(tài)篩選后導(dǎo)出。5. 論文怎么寫(xiě)才像“自己的”項(xiàng)目源碼做完以后論文說(shuō)明是另一個(gè)大頭。很多人代碼跑通了論文卻寫(xiě)得像“說(shuō)明書(shū)”或者“百度百科詞條”答辯直接翻車(chē)。這里分享一些寫(xiě)論文的經(jīng)驗(yàn)。5.1 論文的章節(jié)框架我建議按這個(gè)結(jié)構(gòu)寫(xiě)第一章緒論。寫(xiě)選題背景和意義、國(guó)內(nèi)外研究現(xiàn)狀、主要研究?jī)?nèi)容和工作安排。注意“研究現(xiàn)狀”一定要結(jié)合具體文獻(xiàn)寫(xiě)不要空談。第二章相關(guān)技術(shù)介紹。介紹微信小程序、Spring Boot、MySQL、微信支付相關(guān)技術(shù)但要結(jié)合本項(xiàng)目說(shuō)明為什么用這些技術(shù)不要寫(xiě)成教科書(shū)。第三章需求分析。寫(xiě)業(yè)務(wù)需求、功能需求、非功能需求配上用例圖。第四章系統(tǒng)設(shè)計(jì)。寫(xiě)總體架構(gòu)設(shè)計(jì)、功能模塊設(shè)計(jì)、數(shù)據(jù)庫(kù)設(shè)計(jì)、界面設(shè)計(jì)。數(shù)據(jù)庫(kù)設(shè)計(jì)要包含ER圖和核心表結(jié)構(gòu)。第五章系統(tǒng)實(shí)現(xiàn)。寫(xiě)客戶(hù)端各功能模塊的實(shí)現(xiàn)、服務(wù)端的實(shí)現(xiàn)、微信支付集成。這一章要配界面截圖和核心代碼片段。第六章系統(tǒng)測(cè)試。寫(xiě)測(cè)試環(huán)境、功能測(cè)試用例、測(cè)試結(jié)果分析。最后一章總結(jié)與展望。總結(jié)項(xiàng)目成果和不足展望未來(lái)可以擴(kuò)展的功能比如人臉識(shí)別檢錄入場(chǎng)、成績(jī)實(shí)時(shí)查詢(xún)等。這個(gè)框架是標(biāo)準(zhǔn)的軟件工程論文框架老師看了不會(huì)挑大問(wèn)題。5.2 圖表和代碼排版經(jīng)驗(yàn)論文里圖的力量遠(yuǎn)大于文字。你至少需要準(zhǔn)備這些圖系統(tǒng)總體架構(gòu)圖、功能模塊圖、業(yè)務(wù)流程圖報(bào)名流程、數(shù)據(jù)庫(kù)ER圖、支付時(shí)序圖、每個(gè)核心頁(yè)面的截圖。這些圖全部自己畫(huà)、自己截圖別從網(wǎng)上隨便找。時(shí)序圖這里不用專(zhuān)業(yè)的繪圖工具畫(huà)在Word里用文本框和箭頭就能完成。支付時(shí)序圖要著重表現(xiàn)用戶(hù)、小程序前端、后端服務(wù)、微信支付平臺(tái)四個(gè)角色之間的消息傳遞順序。這張圖畫(huà)好了答辯時(shí)講支付流程就非常省力。代碼部分不要大段貼在描述核心算法、關(guān)鍵業(yè)務(wù)邏輯時(shí)貼10到20行就夠了完整源碼可以放附錄。特別注意排版時(shí)中文標(biāo)點(diǎn)的一致性以及代碼塊的字號(hào)和等寬字體設(shè)置。很多老師會(huì)直接翻論文排版格式不統(tǒng)一的印象分很低。6. 常見(jiàn)問(wèn)題與避坑記錄做這個(gè)項(xiàng)目時(shí)踩了不少坑這里整理一個(gè)排查手冊(cè)供你直接參考。6.1 真機(jī)調(diào)試、合法域名與HTTPS問(wèn)題小程序開(kāi)發(fā)工具里請(qǐng)求接口默認(rèn)會(huì)報(bào)“url not in domain list”之類(lèi)的錯(cuò)誤。本地開(kāi)發(fā)階段可以在開(kāi)發(fā)者工具右上角“詳情-本地設(shè)置”里勾選“不校驗(yàn)合法域名”這樣能用HTTP的本地IP調(diào)試。但真機(jī)預(yù)覽時(shí)如果不校驗(yàn)會(huì)連不上而且一旦正式上線(xiàn)必須配置登錄微信公眾平臺(tái)在小程序后臺(tái)的“開(kāi)發(fā)管理-開(kāi)發(fā)設(shè)置-服務(wù)器域名”里配置request合法域名域名必須是已備案的HTTPS域名。我遇到過(guò)一種情況配置了合法域名但真機(jī)還是請(qǐng)求失敗排查后發(fā)現(xiàn)是SSL證書(shū)是自簽發(fā)的微信不認(rèn)。正式環(huán)境一定要用正規(guī)CA機(jī)構(gòu)簽發(fā)的證書(shū)云廠商提供的免費(fèi)證書(shū)也夠用。6.2 微信支付相關(guān)的問(wèn)題最經(jīng)典的坑有三個(gè)。第一個(gè)是金額單位。微信支付接口里所有金額都是“分”比如報(bào)名費(fèi)50元傳參時(shí)是5000不是0.01。我在聯(lián)調(diào)時(shí)就因?yàn)榍岸藗髁嗽?、后端按分處理?dǎo)致金額少了100倍還好及時(shí)發(fā)現(xiàn)。第二個(gè)是回調(diào)處理不冪等?；卣{(diào)接口被微信多次調(diào)用后如果每次都把狀態(tài)從“已支付”變成“已完成”頁(yè)面狀態(tài)會(huì)錯(cuò)亂。實(shí)現(xiàn)里必須加狀態(tài)判斷。第三個(gè)是微信支付要求商戶(hù)號(hào)要求小程序主體是企業(yè)或個(gè)體工商戶(hù)。個(gè)人主體的小程序沒(méi)法直接開(kāi)通微信支付。畢設(shè)階段可以做一個(gè)“模擬支付”開(kāi)關(guān)后端配置里增加mockPaytrue當(dāng)處于模擬模式時(shí)前端不調(diào)wx.requestPayment而是直接請(qǐng)求接口把訂單置為已支付。這個(gè)開(kāi)關(guān)保留在代碼里答辯演示時(shí)也不會(huì)尷尬。6.3 小程序?qū)徍伺c類(lèi)目如果這個(gè)系統(tǒng)真的要上線(xiàn)要提前確認(rèn)小程序的類(lèi)目。運(yùn)動(dòng)和賽事報(bào)名通常對(duì)應(yīng)“生活服務(wù)-體育”類(lèi)目可能需要提供相應(yīng)的資質(zhì)文件。審核時(shí)特別容易被拒的內(nèi)容包括誘導(dǎo)分享比如分享得獎(jiǎng)品、收集身份證號(hào)但沒(méi)有隱私保護(hù)說(shuō)明。解決辦法是在小程序后臺(tái)填寫(xiě)用戶(hù)隱私保護(hù)指引聲明收集身份證號(hào)、手機(jī)號(hào)等信息的用途并在用戶(hù)首次使用時(shí)彈出隱私授權(quán)彈窗。還有年審的問(wèn)題。認(rèn)證的小程序每年需要做一次年審認(rèn)證費(fèi)用一般是300元。如果你只是做畢設(shè)不需要管這些但論文里如果寫(xiě)上“系統(tǒng)上線(xiàn)需要考慮合規(guī)認(rèn)證與年審”會(huì)顯得你考慮得很全面。6.4 報(bào)名并發(fā)下的數(shù)據(jù)一致性第4節(jié)講過(guò)名額扣減SQL這里再補(bǔ)充一個(gè)真實(shí)場(chǎng)景。我在測(cè)試時(shí)用兩臺(tái)手機(jī)同時(shí)提交最后一個(gè)名額結(jié)果兩個(gè)訂單都顯示待支付但SQL扣減只成功一個(gè)。這說(shuō)明“創(chuàng)建訂單成功”和“名額扣減成功”必須放在同一個(gè)后端事務(wù)里。正確流程是后端收到創(chuàng)建訂單請(qǐng)求時(shí)先執(zhí)行名額扣減SQL扣減成功再插入訂單記錄整個(gè)操作在Transactional事務(wù)內(nèi)。如果扣減失敗直接返回“名額已滿(mǎn)”不生成訂單。6.5 小程序端的體驗(yàn)細(xì)節(jié)坑幾個(gè)看起來(lái)不起眼但影響體驗(yàn)的細(xì)節(jié)自定義頂部導(dǎo)航欄時(shí)狀態(tài)欄高度獲取接口已從wx.getSystemInfoSync逐步遷移到wx.getWindowInfo舊接口在基礎(chǔ)庫(kù)新版本上會(huì)告警。報(bào)名表單里的單選框點(diǎn)擊區(qū)域要大避免用戶(hù)誤觸。列表加載更多時(shí)在底部放一個(gè)“加載中”提示沒(méi)有更多數(shù)據(jù)時(shí)顯示“沒(méi)有更多了”不然用戶(hù)會(huì)一直往下滑。我個(gè)人在實(shí)際操作中的體會(huì)是做這類(lèi)“小程序報(bào)名支付”的項(xiàng)目最值得先花時(shí)間的是把訂單狀態(tài)機(jī)和數(shù)據(jù)庫(kù)字段定清楚。狀態(tài)機(jī)理清楚前后端聯(lián)調(diào)會(huì)順利很多字段設(shè)計(jì)好后面做統(tǒng)計(jì)和導(dǎo)出都不會(huì)返工。還有一個(gè)容易被忽略的點(diǎn)身份證號(hào)是敏感信息數(shù)據(jù)庫(kù)里不能明文存儲(chǔ)至少要做加密答辯時(shí)把這個(gè)點(diǎn)講出來(lái)老師會(huì)認(rèn)為你有安全意識(shí)。最后給個(gè)特別實(shí)在的建議代碼從第一天開(kāi)始就放到Git倉(cāng)庫(kù)里隨時(shí)提交我見(jiàn)過(guò)不止一個(gè)同學(xué)在答辯前一周發(fā)現(xiàn)代碼沒(méi)了那種絕望是真的不想再體驗(yàn)第二次。