基于微信的學生文具選購小程序——畢業(yè)設計從選題到答辯要解決的那些事每年畢業(yè)設計季都會看到一批類似微信小程序 電商的題目其中學生文具選購這個方向出鏡率相當高。別覺得它不起眼這類項目看著簡單但要把前臺選購、后臺管理、訂單狀態(tài)流轉、數(shù)據(jù)庫設計、論文排版、源碼整理全部串起來還是有很多細節(jié)容易翻車。我這里就把這個項目從功能拆解到技術選型、再到答辯準備一條線講清楚給打算做這類題目的同學一個相對完整的參考。這個題目的本質并不只是寫個小程序賣文具它是在考查一個計算機專業(yè)學生能不能完成一套完整的電商業(yè)務閉環(huán)用戶通過微信小程序瀏覽文具 → 加入購物車 → 提交訂單 → 后臺管理員管理商品/訂單/數(shù)據(jù)統(tǒng)計。在畢業(yè)設計的語境下它還要額外產(chǎn)出源碼、LW文檔設計文檔、演示視頻和答辯PPT。下面我從幾個容易被忽略的維度來拆解。1. 這個題目到底在考什么不止是寫小程序1.1 一個合格畢業(yè)設計的四項交付物很多人拿到類似題目第一反應是我會寫小程序前端這事穩(wěn)了結果做到中期才發(fā)現(xiàn)畢業(yè)設計要的東西比想象中多得多。按我見過的大多數(shù)學校要求這個題目至少要交付四樣東西完整可運行源碼小程序前端代碼WXML、WXSS、JS、JSON以及后端接口代碼如果走云開發(fā)模式就是云函數(shù)如果走傳統(tǒng)模式就是Java/Spring Boot或Node.js的接口工程。源碼還要有清晰的目錄結構而不是一個壓縮包扔在那里沒有說明。LW設計文檔通常又叫畢業(yè)設計說明書或者項目設計文檔包含需求分析、系統(tǒng)設計、數(shù)據(jù)庫設計、功能測試、總結等章節(jié)一般要求1.5萬字到2萬字圖比字重要。演示視頻三到五分鐘的操作演示從登錄、瀏覽商品、加購、下單到管理端修改商品狀態(tài)視頻里要能看出系統(tǒng)是真實跑起來的。答辯PPT核心講背景意義、技術架構、本人完成的工作、系統(tǒng)演示和測試結果。這四樣東西的權重經(jīng)常被低估。我見過有學生代碼寫得挺好但文檔里連數(shù)據(jù)庫關系圖都沒有老師直接一句話頂回去你這項目不是你自己做的吧所以這個題目的第一關是擺正心態(tài)它不是編程題而是一個系統(tǒng)設計 工程實現(xiàn) 文檔沉淀的綜合項目。1.2 難度定位中低偏上但能拉開差距單論開發(fā)難度這類小程序電商題屬于中低難度比算法類、底層系統(tǒng)類、大數(shù)據(jù)平臺類題目容易出成果。但是想拿高分反而難在有沒有把簡單的東西做完整。同樣叫文具選購小程序A同學只做了首頁展示、分類、加購、下單B同學多做了庫存不足提示、訂單倒計時取消、銷量排行榜、后臺數(shù)據(jù)統(tǒng)計圖表、圖片懶加載、支付模擬狀態(tài)機——兩人的完成度和答辯評價立刻拉開差距。所以題目是同一個做出來什么水平完全取決于你自己。1.3 為什么這類題目的通過率反而高因為它的業(yè)務邊界非常清晰。文具商品的屬性相對固定分類明確筆、本冊、美術用品、辦公耗材、書包等價格范圍穩(wěn)定沒有復雜的營銷邏輯或售后邏輯。相比做生鮮、做服裝、做二手交易文具選購把電商閉環(huán)濃縮得恰到好處特別適合在幾個月內完整開發(fā)并寫出規(guī)范文檔。這也是很多選題庫把它列為常規(guī)選項的根本原因。2. 功能模塊與業(yè)務閉環(huán)先畫清楚了再動手2.1 用戶端六個頁面撐起完整購買流程小程序端的核心頁面我建議按下面的結構來設計每一頁解決一個明確的用戶訴求頁面核心功能關鍵交互首頁輪播圖、熱門商品、秒殺/特價區(qū)、搜索入口下拉刷新、上拉加載分類頁左側分類導航右側商品列表分類切換、篩選排序搜索頁/結果頁按關鍵字搜索文具、歷史搜索記錄關鍵詞高亮、空狀態(tài)提示商品詳情頁商品圖片、價格、庫存、規(guī)格、詳細介紹加入購物車、立即購買購物車頁已選商品、數(shù)量增減、單選/全選、結算金額實時計算、庫存校驗訂單中心待付款/待發(fā)貨/待收貨/已完成 四個Tab取消訂單、確認收貨、刪除訂單除了購物流程用戶側還要有個人中心微信授權頭像昵稱、地址管理、瀏覽歷史。如果你為了省事把地址做成下單時手填輸入框也可以但體驗就會弱一些而且文檔里少了一張地址管理用例圖。2.2 管理端不要讓管理員在小程序里點點點管理端是畢業(yè)設計里最容易被做薄的地方很多學生只在數(shù)據(jù)庫里手動改數(shù)據(jù)或者勉強做了一個只有訂單列表的管理頁面。這里踩一個關鍵認知管理端一定是要有獨立入口的哪怕只是小程序里的管理員登錄隱藏入口。管理端模塊建議拆成四塊商品管理新品上架、下架、編輯價格庫存、上傳封面圖、設置分類。這里直接對應數(shù)據(jù)庫商品的增刪改查。分類管理補充/刪除文具分類分類排序。訂單管理查看全部訂單、按狀態(tài)篩選、發(fā)貨操作、備注。發(fā)貨操作在演示里很有畫面感老師會看到訂單狀態(tài)從待發(fā)貨變?yōu)榕渌椭?。?shù)據(jù)概覽統(tǒng)計商品總數(shù)、總銷售額、訂單量存量少的時候可以用條形圖展示TOP5熱賣商品。如果不想接圖表庫就用小程序原生的canvas畫一個簡單柱狀圖或者直接把統(tǒng)計數(shù)據(jù)做成數(shù)字卡片效果也夠。有些學生會問要不要做用戶管理。我的建議是保留一個簡單的用戶列表即可不要做刪除功能因為演示時把同學頭像弄消失不太好而且對主流程沒有幫助。2.3 數(shù)據(jù)庫與狀態(tài)機設計最見功底的位置文具選購小程序的表不需要很多但每張表都要經(jīng)得起推敲。我下面列出一套比較常見的庫表結構字段做了精簡用戶表openid唯一標識、昵稱、頭像、角色、創(chuàng)建時間分類表分類名、排序值、圖標商品表名稱、描述、價格、原價、庫存、銷量、封面圖、詳情圖、分類ID、是否上架、瀏覽量購物車表用戶ID、商品ID、數(shù)量、選中狀態(tài)訂單表訂單號、用戶ID、總金額、實付金額、狀態(tài)、收貨人、電話、地址、創(chuàng)建時間、支付時間、發(fā)貨時間訂單明細表訂單ID、商品ID、商品名稱、快照價格、商品圖片、購買數(shù)量地址表用戶ID、收貨人、電話、省市區(qū)、詳細地址、默認標記這里有一個容易被答辯老師抓住的點為什么要有訂單明細表而且明細表里要冗余保存商品名稱、價格、圖片因為在購買完成后商品可能被下架、改價甚至刪除訂單不能跟著變。所以明細表保存的就是下單那一刻的商品快照。文檔里把這個設計邏輯寫清楚評委很難挑出毛病。訂單狀態(tài)的流轉是另一個答辯高頻點。建議用一張表或者狀態(tài)圖表達待付款 → 待發(fā)貨 → 待收貨 → 已完成 ↓超時未支付 已關閉如果要加分還可以設計一個售后/退款狀態(tài)但需要注意工作量控制。有些學生給自己加了一個退貨退款流程結果做到后面時間不夠反而把主流程的穩(wěn)定性拖垮了。對于畢業(yè)設計來說做好正向狀態(tài)流轉 超時關閉已經(jīng)足夠完整。3. 技術選型對比微信云開發(fā)還是自建后端 API3.1 云開發(fā)模式快速出成果的首選現(xiàn)在微信小程序最流行的后端方案是微信云開發(fā)CloudBase它天生集成了云數(shù)據(jù)庫、云函數(shù)、云存儲。對畢業(yè)設計來說這個方案有幾個非?，F(xiàn)實的優(yōu)點不用自己申請服務器不用配置域名備案。你在微信開發(fā)者工具里點幾下環(huán)境和數(shù)據(jù)庫就建好了。不用實現(xiàn)微信登錄的完整后端邏輯。云函數(shù)側一個 login 函數(shù)接收前端傳過來的 code然后調用鑒權接口就能拿到 openid流程非常短。圖片直接傳到云存儲拿到的URL就能當商品封面圖使用省去圖片服務器的搭建。數(shù)據(jù)權限可以配置成僅創(chuàng)建者可讀寫或者所有人可讀非常適配電商場景商品表所有人可讀訂單表只有本人和管理員可讀。這個模式的代價是你寫的大部分邏輯都在云函數(shù)里沒法體現(xiàn)傳統(tǒng)后端的分層結構比如Controller、Service、DAO那一套。如果學校老師特別老派只看重Java SSH/Spring Boot那么你需要在文檔里把云函數(shù) 業(yè)務邏輯層這個映射關系寫清楚。3.2 自建后端模式更學院派但周期更長傳統(tǒng)方案是小程序前端 Spring Boot后端 MySQL數(shù)據(jù)庫 Redis可選。到位的話還可以加個 Nginx 部署、HTTPS 證書、服務器域名。這個方案的優(yōu)點顯而易見技術棧主流答辯時老師比較熟悉對分層架構的理解也更直觀。它的痛點是部署鏈路長。我見過某學生把Spring Boot接口在本地跑得好好的結果要在云服務器上部署時捅了幾天MySQL版本不一致、防火墻端口沒開、小程序 request 合法域名沒配置、JAR包內存不夠。最后光是解決部署問題就花了一個多星期。如果選擇這種方式建議至少提前一個月買服務器并把環(huán)境裝好域名也要早點備案因為小程序正式版要求 request 域名必須是 HTTPS 且已經(jīng)備案備案審核一般要一兩周。3.3 面對這兩種方案我給出的實用建議如果現(xiàn)在時間緊張只剩兩三個月或者你的Java功底一般我強烈推薦云開發(fā)方案。它的交付速度至少比自建后端快一倍而且可以讓你把精力留在體驗優(yōu)化上比如商品圖片、界面整潔度、演示流程。如果學校明確要求用Java/Spring Boot做后端或者你的選題需要體現(xiàn)前后端分離那就老老實實走傳統(tǒng)方案。我可以給一個折中的做法前端用微信小程序后端用Spring Boot但數(shù)據(jù)庫可以先用支付寶云或者騰訊云的云數(shù)據(jù)庫MySQL這樣省去自己裝MySQL的時間。3.4 技術方案對比表對比維度微信云開發(fā)Spring Boot自建后端開發(fā)速度快環(huán)境零配置慢環(huán)境搭建較多項目結構云函數(shù)即服務前后端分層清晰域名/備案基本不用管必須HTTPS備案支付能力仍需要商戶號通常模擬同樣需要商戶號通常模擬答辯契合度需要解釋云開發(fā)概念傳統(tǒng)架構更易被認可適合人群趕時間/后端基礎一般有Java基礎/要求嚴格4. 小程序端核心實現(xiàn)登錄、商品列表與訂單狀態(tài)流轉4.1 登錄鑒權不要讓每次請求都重新登錄小程序登錄的核心邏輯是前端調用wx.login拿到臨時 code把它發(fā)給后端或云函數(shù)后端通過該 code 換取 openid然后返回一個自定義登錄態(tài)。云開發(fā)模式下我把登錄函數(shù)寫得很短// 云函數(shù) login const cloud require(wx-server-sdk) cloud.init({ env: cloud.DYNAMIC_CURRENT_ENV }) exports.main async () { const wxContext cloud.getWXContext() const db cloud.database() const users db.collection(users) const res await users.where({ openid: wxContext.OPENID }).get() if (res.data.length 0) { await users.add({ data: { openid: wxContext.OPENID, nickname: , avatar: , createTime: Date.now() } }) } return { openid: wxContext.OPENID } }前端把這個返回的 openid 存到wx.setStorageSync后續(xù)的請求直接攜帶 openid 作為用戶標識。注意不要每次頁面加載都調一次wx.login否則云函數(shù)會頻繁查庫。我見過有的學生在首頁 onLoad 里調登錄接口在詳情頁又調一次不僅慢還容易被云開發(fā)資源限制狙擊。4.2 商品列表和購物車數(shù)據(jù)流向要清楚商品列表大多長這樣onLoad里請求 cloud functionproduct或者直接查products集合按分類過濾、按銷量排序。要注意的是不要把整個商品詳情的大圖字段也塞進列表否則小程序首屏加載很慢。列表查詢只取必要的字段比如_id, name, price, cover, sales詳情頁再單獨查 full content。購物車是另一個容易寫亂的模塊。我建議不要把購物車完全放本地緩存因為換手機、清理緩存后數(shù)據(jù)就沒了答辯時容易露怯也別把每一項都實時寫數(shù)據(jù)庫因為頻繁操作會導致請求次數(shù)暴漲。折中方案是選中狀態(tài)和臨時數(shù)量放在本地 storage最終點擊去結算時把勾選的數(shù)據(jù)一次性寫入訂單表和購物車表清理。4.3 下單與庫存處理這里藏著最大的并發(fā)坑很多學生寫的提交訂單接口邏輯是這樣// 偽代碼庫存不足情況 const product await db.collection(products).doc(productId).get() if (product.data.stock quantity) { await db.collection(products).doc(productId).update({ stock: product.data.stock - quantity }) // 創(chuàng)建訂單... }這個寫法在單人測試、單機部署時完全沒問題但答辯老師只要問一句兩個人同時買最后一個庫存怎么辦你就會被戳到。正確的處理方式至少應該是在數(shù)據(jù)庫層做庫存扣減的條件更新update({ stock: _.gte(quantity) })然后判斷更新結果影響行數(shù)是否為1再決定是否創(chuàng)建訂單。在云開發(fā)事務里執(zhí)行檢查庫存扣減庫存創(chuàng)建訂單三個操作確保原子性。如果用了傳統(tǒng)MySQL則使用SELECT ... FOR UPDATE或悲觀鎖加樂觀鎖版本號。我見過有學生在答辯時對這個點對答如流老師當場就點頭了。這說明復雜技術不一定真的寫很多代碼但一定要在邏輯上說得通。5. 真機運行與演示階段最容易踩的坑5.1 合法域名和 HTTPS 問題選云開發(fā)模式時如果你用wx.cloud.callFunction調用云函數(shù)是不需要配置 request 合法域名的。但如果你的項目里用了wx.request請求自建后端就必須在微信公眾平臺配置 HTTPS 合法域名。開發(fā)時可以在開發(fā)者工具里勾選不校驗合法域名可一旦到了演示那天如果還是在本地開發(fā)者工具里點那個勾再跑老師印象分會掉。所以演示前我強烈建議用真機預覽模式用微信掃小程序碼在手機上完整走一遍流程。你要提前確認云環(huán)境是本地的還是線上的數(shù)據(jù)是否夠看手機上字體大小會不會把按鈕擠出屏幕。5.2 微信支付個人開發(fā)者號大概率開通不了這個項目名叫文具選購老師默認會有支付流程但現(xiàn)實是個人主體的小程序申請微信支付幾乎都會被駁回因為它要求企業(yè)資質、對公賬戶、法人身份信息。畢業(yè)設計階段最好的處理方式是模擬支付訂單創(chuàng)建后狀態(tài)為待付款頁面展示一個確認支付按鈕點擊后調用一個模擬支付云函數(shù)將訂單狀態(tài)更新為待發(fā)貨。在文檔和答辯PPT里要主動說明本項目采用模擬支付流程已預留官方支付接口位置后續(xù)接入只需替換支付云函數(shù)內部實現(xiàn)。千萬不要在演示時真的跳到收銀臺然后尷尬地發(fā)現(xiàn)沒有商戶號。提前在演示腳本里注明模擬支付四個字反而顯得你考慮周全。5.3 云開發(fā)的環(huán)境和數(shù)據(jù)權限配置云開發(fā)有幾個高頻翻車點數(shù)據(jù)庫權限默認是僅創(chuàng)建者可讀寫商品表如果所有人都不能讀那前端商品列表一定是空白的。需要把商品表權限調成所有用戶可讀僅管理端可寫。云函數(shù)默認超時時間是3秒如果你在云函數(shù)里做了商品圖片壓縮或者批量寫入很容易超時。把超時時間調到10秒或更長比較穩(wěn)。云開發(fā)環(huán)境有免費額度限制但云函數(shù)調用次數(shù)、數(shù)據(jù)庫讀寫次數(shù)都有上限。演示時不要頻繁刷新頁面否則請求數(shù)會漲得很快有些同學碰上限后數(shù)據(jù)庫直接被停掉整個人都懵了。這些坑不是技術多深而是你沒有提前在測試環(huán)境里跑足量數(shù)據(jù)。我建議寫一個測試數(shù)據(jù)初始化腳本一次性在數(shù)據(jù)庫里插入幾十條文具商品數(shù)據(jù)包括分類、價格、銷量、圖片鏈接保證演示不卡殼。5.4 文具商品的數(shù)據(jù)與圖片不做土味頁面電商項目能不能拿高印象分很大程度看視覺。很多學生的項目圖片是從搜索引擎直接抓來的分辨率不一致、背景花花綠綠、甚至帶水印整個頁面看起來非常廉價。建議用一套風格統(tǒng)一的商品圖比如牛皮紙背景的文具擺拍圖實在沒有圖就在云存儲里放純色底加商品名文字也比亂七八糟的水印圖強。商品名稱和描述也要擬得認真比如晨光0.5mm黑色中性筆 12支裝、國譽Campus活頁本 B5 40頁這樣答辯老師看一眼就覺得項目是認真在做。6. 把代碼沉淀成 LW 文檔并準備一份能打答辯的PPT6.1 論文結構按老師習慣的套路走LW是畢業(yè)設計文檔的常見縮寫一般包含這幾個部分不同學校章節(jié)叫法略有差異但內容大同小異緒論項目背景、國內外現(xiàn)狀、研究意義、本文主要工作相關技術概述微信小程序開發(fā)框架、云開發(fā)/Spring Boot、WXML/WXSS/JS、數(shù)據(jù)庫技術需求分析可行性分析、功能性需求用例描述、非功能性需求性能、安全、兼容性系統(tǒng)設計總體架構圖、功能模塊劃分、業(yè)務流程圖、數(shù)據(jù)庫設計E-R圖、數(shù)據(jù)字典系統(tǒng)實現(xiàn)分模塊貼核心代碼并解釋邏輯注意只貼關鍵片段不是整頁整頁貼代碼系統(tǒng)測試測試環(huán)境、功能測試用例表、性能測試、結論總結與展望不足和后續(xù)改進方向頁數(shù)上不用刻意湊到100頁把圖表做清楚比空話強得多。我見過一份文檔內容只有40頁但每個模塊都有截圖、有流程說明老師給的評價比堆了80頁廢話的要高得多。6.2 畫圖的技巧能用一張圖說清楚的別用三段話設計文檔里幾張圖是必考題系統(tǒng)總體架構圖從下往上是 云數(shù)據(jù)庫→云函數(shù)/后端服務→小程序前端→微信用戶層次越清晰越能體現(xiàn)設計感。業(yè)務流程時序圖可以從用戶點擊立即購買出發(fā)畫一條線穿過前端頁面、購物車邏輯、下單接口、數(shù)據(jù)庫、訂單狀態(tài)。這里推薦用文字加箭頭的形式不要用特別復雜的UML工具套件夠用就行。E-R圖把上面提到的七八張表的關系連清楚重點標出訂單表與用戶、商品明細表之間的關系。界面原型圖直接用小程序真機截圖放在系統(tǒng)實現(xiàn)里比用原型工具畫的更真實也省時間。6.3 答辯高頻問題提前準備答案參照我這些年看到的問題以下這幾個高頻點如果都能答上來項目基本不太可能掛為什么選微信小程序而不是手機App回答框架方便分享、無需下載、開發(fā)成本低、符合學生購買習慣。訂單狀態(tài)是怎么流轉的要把待付款、待發(fā)貨、待收貨、已完成、已關閉之間的觸發(fā)條件說清楚。庫存超賣如何避免原子更新、事務、數(shù)據(jù)庫鎖選一個你實際用到的講透。用戶登錄態(tài)怎么維護說清楚 code、openid、前端本地存儲之間的關系。整個系統(tǒng)哪個部分是你自己做的最核心的一定要挑一個真正自己寫過的功能不要背概念。文檔里的產(chǎn)品分類截圖為什么只有三條因為測試數(shù)據(jù)不夠答辯前建議至少錄入8個分類、每類10個商品。另外一個小技巧準備一份“演示腳本”把每一步操作在什么時候做、預期看到什么結果列清楚提前預演三遍。真正上臺時不要按著腳本僵硬地念但心里始終有底。最后再分享一點個人經(jīng)驗這類小程序畢業(yè)設計程序寫完只算完成了一半后面的一半在于把文檔里的邏輯圖、界面截圖、測試表格補到位。你代碼里那些跑通了的流程同樣要在紙上畫出來、在文檔里講明白。文檔和代碼對齊了答辯的通過率就穩(wěn)了。至少我身邊的例子反復驗證這件事希望講完這些準備做這個題目的同學能少走幾段彎路。