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