1. 項(xiàng)目概述與需求拆解1.1 這個(gè)項(xiàng)目到底在做什么先說(shuō)結(jié)論這是一個(gè)典型的“管理信息系統(tǒng)”類畢業(yè)設(shè)計(jì)核心業(yè)務(wù)就一句話——讓用戶能按時(shí)間段預(yù)約運(yùn)動(dòng)場(chǎng)地讓管理員能管理場(chǎng)地和審核預(yù)約。整個(gè)系統(tǒng)的原型在現(xiàn)實(shí)生活中隨處可見(jiàn)比如羽毛球館預(yù)約、籃球場(chǎng)包場(chǎng)、健身房私教課預(yù)約本質(zhì)都是“資源 時(shí)間段 用戶”三者之間的匹配問(wèn)題。拿這個(gè)題目舉例城市運(yùn)動(dòng)空間場(chǎng)地預(yù)約系統(tǒng)表面上是個(gè)網(wǎng)站實(shí)際拆開(kāi)看就是三張核心表用戶表、場(chǎng)地表、預(yù)約記錄表。所有復(fù)雜功能都是圍繞這三張表做增刪改查再加上一些狀態(tài)流轉(zhuǎn)比如預(yù)約成功、已取消、已使用、已過(guò)期。理解了這一點(diǎn)整個(gè)項(xiàng)目的難度就降下來(lái)了——它不是一個(gè)算法題也不是什么高并發(fā)架構(gòu)它考察的是你對(duì)業(yè)務(wù)建模、MVC分層、數(shù)據(jù)庫(kù)設(shè)計(jì)這些基本功的掌握程度。我見(jiàn)過(guò)很多同學(xué)拿到這類題目后上來(lái)就急著寫代碼結(jié)果寫到一半發(fā)現(xiàn)表結(jié)構(gòu)有問(wèn)題又回頭重構(gòu)數(shù)據(jù)庫(kù)白白浪費(fèi)大量時(shí)間。正確的做法是先把業(yè)務(wù)流程捋清楚誰(shuí)在用這個(gè)系統(tǒng)用這個(gè)系統(tǒng)做什么系統(tǒng)需要記錄哪些數(shù)據(jù)數(shù)據(jù)之間是什么關(guān)系這三個(gè)問(wèn)題想明白了后面的開(kāi)發(fā)就是體力活。1.2 為什么選ThinkPHP5而不是其他框架題目里明確指定了ThinkPHP5但很多同學(xué)其實(shí)不理解為什么選它。我在這里多解釋幾句因?yàn)榇疝q的時(shí)候老師大概率會(huì)問(wèn)。ThinkPHP5是國(guó)內(nèi)使用率非常高的PHP MVC框架它的特點(diǎn)用一個(gè)詞概括就是“輕量但完整”。它不像Laravel那樣有大量的設(shè)計(jì)模式和依賴注入概念上手門檻低也不像原生PHP那樣什么都得自己寫連個(gè)數(shù)據(jù)庫(kù)連接都要折騰半天。ThinkPHP5提供了路由、ORM、模板引擎、驗(yàn)證器、中間件這些開(kāi)箱即用的功能對(duì)畢業(yè)設(shè)計(jì)這個(gè)場(chǎng)景來(lái)說(shuō)功能剛好夠用而且資料多、問(wèn)答多遇到問(wèn)題搜一下就能解決。再一個(gè)很現(xiàn)實(shí)的原因是大部分高校的畢業(yè)設(shè)計(jì)選題庫(kù)里有大量ThinkPHP的項(xiàng)目很多選題和這個(gè)相似導(dǎo)師和往屆學(xué)長(zhǎng)都熟悉這套框架答辯時(shí)溝通成本低。如果你非要用Spring Boot或者Django技術(shù)上當(dāng)然也行但出問(wèn)題的概率會(huì)大不少而且無(wú)人可問(wèn)。畢業(yè)設(shè)計(jì)的首要目標(biāo)是“順利用合適的工具完成一個(gè)完整項(xiàng)目”不是炫技。1.3 功能模塊怎么劃分才合理一個(gè)合格的畢業(yè)設(shè)計(jì)應(yīng)該有明確的功能邊界不能想到哪做到哪。我按照常規(guī)的“前臺(tái) 后臺(tái)”模式來(lái)劃分模塊這也是最多選題采用的架構(gòu)。前臺(tái)部分用戶端用戶注冊(cè)與登錄手機(jī)號(hào)或郵箱注冊(cè)、密碼加密存儲(chǔ)、登錄態(tài)保持場(chǎng)地瀏覽與篩選按運(yùn)動(dòng)類型羽毛球、籃球、網(wǎng)球等、按場(chǎng)館位置、按價(jià)格區(qū)間篩選場(chǎng)地場(chǎng)地詳情頁(yè)查看場(chǎng)地照片、設(shè)施描述、可預(yù)約時(shí)間段、價(jià)格在線預(yù)約選擇日期、選擇時(shí)間段、提交訂單、在線支付一般用模擬支付即可個(gè)人中心查看我的預(yù)約記錄、取消預(yù)約、修改個(gè)人資料評(píng)價(jià)功能可選加分項(xiàng)對(duì)已使用場(chǎng)地進(jìn)行評(píng)價(jià)打分后臺(tái)部分管理端管理員登錄獨(dú)立于用戶端的登錄入口儀表盤概覽今日預(yù)約數(shù)、今日營(yíng)收、總場(chǎng)地?cái)?shù)、總用戶數(shù)用圖表展示場(chǎng)地管理場(chǎng)地信息的增刪改查包括場(chǎng)地名稱、類型、位置、圖片、價(jià)格、狀態(tài)預(yù)約管理查看全部預(yù)約記錄支持按日期/場(chǎng)地/用戶篩選可手動(dòng)取消異常預(yù)約用戶管理查看注冊(cè)用戶列表可禁用異常賬號(hào)系統(tǒng)設(shè)置場(chǎng)地開(kāi)放時(shí)間段配置、預(yù)約規(guī)則設(shè)置比如提前幾天可約、每次最多約幾小時(shí)為什么說(shuō)這個(gè)劃分合理因?yàn)榍芭_(tái)和后臺(tái)分離體現(xiàn)了“面向不同角色的系統(tǒng)設(shè)計(jì)”思想而且每個(gè)模塊都能對(duì)應(yīng)到數(shù)據(jù)庫(kù)表和控制器方法代碼結(jié)構(gòu)清晰寫起來(lái)不繞。答辯時(shí)老師問(wèn)“你這個(gè)系統(tǒng)有哪些功能”你能條理清楚地說(shuō)出前臺(tái)幾個(gè)模塊、后臺(tái)幾個(gè)模塊印象分就上來(lái)了。2. 數(shù)據(jù)庫(kù)設(shè)計(jì)與建模2.1 數(shù)據(jù)表整體設(shè)計(jì)思路數(shù)據(jù)庫(kù)設(shè)計(jì)是整個(gè)項(xiàng)目的命根子。代碼寫得丑可以改表結(jié)構(gòu)設(shè)計(jì)錯(cuò)了后面所有功能都要跟著返工。我見(jiàn)過(guò)太多人栽在這一步。設(shè)計(jì)表的時(shí)候腦子里要始終繃著一根弦這張表要支撐哪些頁(yè)面哪些查詢最頻繁數(shù)據(jù)增長(zhǎng)后會(huì)不會(huì)有問(wèn)題對(duì)于這個(gè)預(yù)約系統(tǒng)我建議設(shè)計(jì)以下數(shù)據(jù)表表名用途關(guān)鍵字段admin_user管理員表id, username, password, last_login_timeuser用戶表id, phone, password, nickname, avatar, status, create_timevenue場(chǎng)地表id, name, type, address, price, image, description, statusvenue_schedule場(chǎng)地時(shí)間模板表id, venue_id, weekday, start_time, end_time, statusorder_info預(yù)約訂單表id, order_no, user_id, venue_id, book_date, start_time, end_time, total_price, status, create_time, cancel_timeevaluate評(píng)價(jià)表id, order_id, user_id, venue_id, content, score, create_time為什么需要 venue_schedule 這張表這是我特別想強(qiáng)調(diào)的一點(diǎn)。很多人圖省事只做一張場(chǎng)地表和一個(gè)預(yù)約訂單表然后時(shí)間的可用性全靠查訂單表來(lái)判斷有沒(méi)有沖突。這種方式在小數(shù)據(jù)量下跑得通但一旦某個(gè)場(chǎng)地有大量預(yù)約記錄每次查詢都要遍歷所有訂單來(lái)算可用時(shí)間段SQL寫得又復(fù)雜又慢。更合理的做法是給每個(gè)場(chǎng)地配一個(gè)“時(shí)間模板表”這張表定義的是“該場(chǎng)地在正常情況下每周幾的幾點(diǎn)到幾點(diǎn)是開(kāi)放的”。用戶在預(yù)約時(shí)前端展示的時(shí)間段就是從這張表查出來(lái)的用戶提交預(yù)約時(shí)再去訂單表里查該場(chǎng)地該日期該時(shí)間段有沒(méi)有被占。這樣職責(zé)就分離了模板表管“可以約什么時(shí)段”訂單表管“哪個(gè)時(shí)段被約了”。兩個(gè)一對(duì)比可用時(shí)段一目了然。2.2 核心表結(jié)構(gòu)拆解我重點(diǎn)拆解兩張表一張是場(chǎng)地表一張是預(yù)約訂單表。這兩張表設(shè)計(jì)的合理性直接決定系統(tǒng)好不好用。場(chǎng)地表venueCREATE TABLE venue ( id int(11) unsigned NOT NULL AUTO_INCREMENT, name varchar(100) NOT NULL COMMENT 場(chǎng)地名稱, type varchar(50) NOT NULL COMMENT 類型羽毛球/籃球/網(wǎng)球等, address varchar(255) NOT NULL COMMENT 詳細(xì)地址, price decimal(10,2) NOT NULL COMMENT 每小時(shí)價(jià)格, image varchar(255) DEFAULT COMMENT 場(chǎng)地圖片, description text COMMENT 場(chǎng)地描述, status tinyint(1) NOT NULL DEFAULT 1 COMMENT 狀態(tài)1啟用 0停用, create_time int(11) NOT NULL COMMENT 創(chuàng)建時(shí)間, update_time int(11) NOT NULL COMMENT 更新時(shí)間, PRIMARY KEY (id), KEY idx_type (type) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT運(yùn)動(dòng)場(chǎng)地表;這里有幾個(gè)細(xì)節(jié)值得說(shuō)明。第一type字段加索引因?yàn)榍芭_(tái)大概率會(huì)有按類型篩選的需求。第二price用decimal而不是float這個(gè)是我踩過(guò)坑的地方float在PHP和MySQL的交互中經(jīng)常出現(xiàn)精度丟失比如顯示成222.9999999之類的情況。第三status字段預(yù)留了停用功能方便管理員下架某個(gè)場(chǎng)地而不刪除數(shù)據(jù)這個(gè)對(duì)后臺(tái)操作非常友好。預(yù)約訂單表order_info是整張系統(tǒng)里最重要的表CREATE TABLE order_info ( id int(11) unsigned NOT NULL AUTO_INCREMENT, order_no varchar(32) NOT NULL COMMENT 訂單號(hào), user_id int(11) NOT NULL COMMENT 用戶ID, venue_id int(11) NOT NULL COMMENT 場(chǎng)地ID, book_date date NOT NULL COMMENT 預(yù)約日期, start_time time NOT NULL COMMENT 開(kāi)始時(shí)間, end_time time NOT NULL COMMENT 結(jié)束時(shí)間, total_price decimal(10,2) NOT NULL COMMENT 總價(jià), status tinyint(1) NOT NULL DEFAULT 0 COMMENT 狀態(tài)0待支付 1已支付 2已取消 3已使用 4已過(guò)期, create_time int(11) NOT NULL, cancel_time int(11) DEFAULT NULL COMMENT 取消時(shí)間, PRIMARY KEY (id), UNIQUE KEY idx_order_no (order_no), KEY idx_user_id (user_id), KEY idx_venue_date (venue_id,book_date) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT預(yù)約訂單表;訂單號(hào)用唯一索引這是為了防止并發(fā)下生成重復(fù)訂單號(hào)。復(fù)合索引 idx_venue_date 是我建議每個(gè)做這類系統(tǒng)的人都加上的因?yàn)樽詈诵牡臎_突查詢就是“查某場(chǎng)地某日期被哪些時(shí)間段占了”這個(gè)復(fù)合索引能讓查詢走索引速度飛快。status字段的4種狀態(tài)需要反復(fù)推敲待支付、已支付、已取消、已使用、已過(guò)期。注意“已過(guò)期”這個(gè)狀態(tài)往往是新手容易漏掉的——用戶約了場(chǎng)地但沒(méi)去后臺(tái)統(tǒng)計(jì)時(shí)總得有個(gè)地方標(biāo)記這種單子。如果把過(guò)期訂單直接刪掉那營(yíng)收統(tǒng)計(jì)就對(duì)不上了。2.3 表關(guān)系與約束設(shè)計(jì)表與表之間的關(guān)系用一句話總結(jié)就是用戶表一對(duì)多訂單表場(chǎng)地表一對(duì)多訂單表訂單表一對(duì)一評(píng)價(jià)表。這種關(guān)系在ThinkPHP5的模型里非常容易表達(dá)用 hasMany 和 belongsTo 兩個(gè)方法就能搞定。我建議在模型層面寫上明確的關(guān)聯(lián)關(guān)系而不是每次查詢都手動(dòng)join。原因有兩點(diǎn)一是代碼更可讀寫上關(guān)聯(lián)之后直接用$user-orders就能拿到該用戶的全部訂單邏輯一目了然二是在列表頁(yè)面需要展示關(guān)聯(lián)數(shù)據(jù)比如訂單列表里要顯示場(chǎng)地名、用戶名只要用ThinkPHP5的with預(yù)載入就能避免N1查詢問(wèn)題一次性把關(guān)聯(lián)數(shù)據(jù)查出來(lái)性能提升是實(shí)打?qū)嵉?。還有一個(gè)容易忽略的問(wèn)題外鍵約束。很多同學(xué)因?yàn)橄勇闊┰跀?shù)據(jù)庫(kù)層面完全不加物理外鍵。這個(gè)習(xí)慣我理解但在本場(chǎng)景下我建議至少把邏輯外鍵用好也就是業(yè)務(wù)層面去保證數(shù)據(jù)完整性。舉例來(lái)說(shuō)當(dāng)一個(gè)訂單關(guān)聯(lián)的場(chǎng)地被管理員刪除時(shí)如果訂單表里有殘留數(shù)據(jù)前臺(tái)就會(huì)報(bào)錯(cuò)因?yàn)?venue_id 查不到對(duì)應(yīng)場(chǎng)地了。我的建議是場(chǎng)地表只用status字段做軟刪除不真正delete記錄這樣歷史訂單永遠(yuǎn)能查到場(chǎng)地快照信息邏輯上就閉環(huán)了。3. 核心業(yè)務(wù)邏輯與關(guān)鍵實(shí)現(xiàn)3.1 預(yù)約主流程怎么設(shè)計(jì)預(yù)約是整個(gè)系統(tǒng)的心臟。我來(lái)完整描述一遍用戶從進(jìn)入系統(tǒng)到預(yù)約成功的完整時(shí)序這中間每一步都有對(duì)應(yīng)代碼要寫。第一步用戶登錄后在前臺(tái)選擇某個(gè)運(yùn)動(dòng)類型系統(tǒng)查詢出啟用狀態(tài)的場(chǎng)地列表。第二步用戶點(diǎn)擊某個(gè)場(chǎng)地進(jìn)入詳情頁(yè)頁(yè)面加載時(shí)向后端發(fā)起一個(gè)請(qǐng)求攜帶場(chǎng)地id和日期參數(shù)后端返回該日期下所有可用時(shí)間段。第三步用戶選擇一個(gè)時(shí)間段系統(tǒng)自動(dòng)計(jì)算價(jià)格確認(rèn)后點(diǎn)擊“提交預(yù)約”后端生成待支付訂單。第四步模擬支付用戶點(diǎn)擊支付后訂單狀態(tài)變?yōu)橐阎Ц断到y(tǒng)扣減該時(shí)段的可預(yù)約數(shù)量本系統(tǒng)中體現(xiàn)為寫入一條訂單記錄。第五步用戶在個(gè)人中心看到“已支付”的訂單到場(chǎng)后管理員在后臺(tái)可將訂單標(biāo)記為“已使用”。這里最關(guān)鍵的是第二步和第三步因?yàn)闋砍兜健皶r(shí)間沖突檢測(cè)”。我見(jiàn)過(guò)太多人在這里寫出漏洞兩個(gè)用戶同時(shí)提交同一個(gè)場(chǎng)地同一個(gè)時(shí)間段的預(yù)約結(jié)果兩個(gè)都成功了這就叫超賣。避免超賣的核心思路其實(shí)很簡(jiǎn)單——把“檢查沖突”和“寫入訂單”放在同一個(gè)數(shù)據(jù)庫(kù)事務(wù)里并且利用數(shù)據(jù)庫(kù)的鎖機(jī)制保證同一時(shí)刻只有一個(gè)請(qǐng)求在操作同一條記錄。在ThinkPHP5中可以使用事務(wù) 悲觀鎖Db::startTrans(); try { // 鎖住該場(chǎng)地該日期的相關(guān)記錄防止并發(fā) $lockKey venue_ . $venueId . _ . $bookDate; $existing Db::name(order_info) -where(venue_id, $venueId) -where(book_date, $bookDate) -where(status, in, [0, 1]) -lock(true) -select(); // 檢測(cè)時(shí)間沖突 foreach ($existing as $order) { if (!($endTime $order[start_time] || $startTime $order[end_time])) { throw new \Exception(該時(shí)間段已被預(yù)約); } } // 寫入訂單 Db::name(order_info)-insert($orderData); Db::commit(); } catch (\Exception $e) { Db::rollback(); return error($e-getMessage()); }lock(true)在ThinkPHP5中會(huì)生成FOR UPDATE語(yǔ)句加上事務(wù)的隔離性就能很大程度避免并發(fā)下的超賣問(wèn)題。當(dāng)然真正的生產(chǎn)環(huán)境可能還需要更復(fù)雜的做法但這是畢業(yè)設(shè)計(jì)里能寫出并講清楚的方案而且面試答辯也夠用了。3.2 場(chǎng)地時(shí)間沖突檢測(cè)的實(shí)現(xiàn)細(xì)節(jié)時(shí)間沖突檢測(cè)聽(tīng)起來(lái)高端其實(shí)是初中數(shù)學(xué)里“區(qū)間重疊”的問(wèn)題。兩個(gè)時(shí)間段 [a, b] 和 [c, d] 有沖突要么 a 在 c 和 d 之間要么 c 在 a 和 b 之間。寫成代碼就是// 已知新預(yù)約的時(shí)段是 startTime 到 endTime foreach ($existingOrders as $order) { // 場(chǎng)景1新預(yù)約開(kāi)始時(shí)間在已有訂單時(shí)間段內(nèi) if ($startTime $order[start_time] $startTime $order[end_time]) { return 該時(shí)間段已被占用; } // 場(chǎng)景2新預(yù)約結(jié)束時(shí)間在已有訂單時(shí)間段內(nèi) if ($endTime $order[start_time] $endTime $order[end_time]) { return 該時(shí)間段已被占用; } // 場(chǎng)景3新預(yù)約完全包含了已有訂單時(shí)間段 if ($startTime $order[start_time] $endTime $order[end_time]) { return 該時(shí)間段已被占用; } }上面這段代碼是業(yè)務(wù)層寫法邏輯對(duì)但效率一般。更優(yōu)雅的寫法是把沖突檢測(cè)直接放在SQL里查 “是否存在某條訂單其開(kāi)始時(shí)間小于新結(jié)束時(shí)間且結(jié)束時(shí)間大于新開(kāi)始時(shí)間”存在即為沖突。SELECT COUNT(*) FROM order_info WHERE venue_id ? AND book_date ? AND status IN (0,1) AND start_time ? AND end_time ?是不是簡(jiǎn)潔了很多這條SQL的意思是只要存在一條訂單它的開(kāi)始時(shí)間早于你要預(yù)約的結(jié)束時(shí)間且它的結(jié)束時(shí)間晚于你要預(yù)約的開(kāi)始時(shí)間那就一定有重疊。這個(gè)寫法建議在答辯時(shí)介紹因?yàn)轶w現(xiàn)了對(duì)SQL的深入理解比在PHP里寫循環(huán)判斷高一個(gè)層次。另外還要注意狀態(tài)過(guò)濾。status IN (0,1)表示只有“待支付”和“已支付”的訂單才占用時(shí)間段已取消2、已使用3的訂單不參與沖突判斷。已使用為什么也不算沖突因?yàn)槟莻€(gè)時(shí)段已經(jīng)過(guò)去了用戶約的是未來(lái)的時(shí)間自然不會(huì)撞上。這個(gè)問(wèn)題我在調(diào)試時(shí)還真遇到過(guò)——有個(gè)同學(xué)把status條件漏了導(dǎo)致已經(jīng)使用的訂單也占著時(shí)段場(chǎng)地永遠(yuǎn)顯示不可約。3.3 前端展示時(shí)間段的業(yè)務(wù)處理場(chǎng)地詳情頁(yè)的可用時(shí)間段展示看起來(lái)只是把數(shù)據(jù)庫(kù)里的時(shí)間模板查出來(lái)再減去已經(jīng)被約的時(shí)間但里面藏了一個(gè)業(yè)務(wù)細(xì)節(jié)跨時(shí)段的選擇。舉個(gè)例子場(chǎng)地開(kāi)放時(shí)間是 8:00-22:00每次預(yù)訂時(shí)長(zhǎng)最少1小時(shí)也可以約2小時(shí)、3小時(shí)。用戶選擇了 9:00-11:00這時(shí)候頁(yè)面應(yīng)該自動(dòng)高亮 9:00-11:00 這個(gè)區(qū)間。這個(gè)交互難嗎不難但處理不好很影響體驗(yàn)。我建議前端用時(shí)間線的形式展示把一天從開(kāi)放時(shí)間到結(jié)束時(shí)間切成固定粒度的格子比如每30分鐘一格已被預(yù)約的格子置灰用戶點(diǎn)擊某個(gè)起始格子后再點(diǎn)擊結(jié)束格子頁(yè)面自動(dòng)計(jì)算格數(shù)并顯示價(jià)格。這個(gè)方案實(shí)現(xiàn)簡(jiǎn)單交互直觀而且能天然避免用戶選出一個(gè)非法時(shí)間段。至于具體的切格子邏輯可以放在前端用JS處理后端只需要提供兩個(gè)數(shù)據(jù)場(chǎng)地時(shí)間模板open_time - close_time和該日期的已預(yù)約時(shí)間數(shù)組。我這邊的經(jīng)驗(yàn)是前端時(shí)間格子的數(shù)據(jù)從后端一次性取完格式統(tǒng)一成類似[9:00, 9:30, 10:00, 10:30]這種格式前端只需要做數(shù)組差集把已預(yù)約的時(shí)間點(diǎn)剔除剩下能點(diǎn)的就是可用時(shí)段。別把時(shí)間沖突判斷也放到前端做——前端判斷只能用來(lái)提升體驗(yàn)后端該查的沖突還是要查因?yàn)榍岸耸强梢酝ㄟ^(guò)開(kāi)發(fā)者工具繞過(guò)驗(yàn)證的這個(gè)安全邊界一定得分清楚。3.4 后臺(tái)管理功能的要點(diǎn)后臺(tái)管理看似只是增刪改查但我覺(jué)得有兩點(diǎn)值得單獨(dú)說(shuō)一下。第一儀表盤的統(tǒng)計(jì)SQL怎么寫。很多同學(xué)拿到“統(tǒng)計(jì)今天預(yù)約量”這種需求第一反應(yīng)是用where(create_time, , strtotime(today))但后面你會(huì)發(fā)現(xiàn)這種寫法沒(méi)法用索引而且統(tǒng)計(jì)口徑容易出錯(cuò)。我一般建議用日期函數(shù)來(lái)按天分組$today date(Y-m-d); $todayCount Db::name(order_info) -where(book_date, $today) -where(status, 1) -count(); $typeData Db::name(order_info) -alias(o) -join(venue v, o.venue_id v.id) -field(v.type, COUNT(*) as num) -group(v.type) -select();注意這里統(tǒng)計(jì)的是 book_date 字段而不是 create_time因?yàn)闃I(yè)務(wù)上“今日預(yù)約數(shù)”應(yīng)該按使用日期算而不是按下單時(shí)間算。這個(gè)口徑問(wèn)題答辯時(shí)老師可能會(huì)問(wèn)提前想清楚就能答得漂亮。第二后臺(tái)的權(quán)限控制。雖然這個(gè)系統(tǒng)只有一種管理員角色不需要做復(fù)雜的RBAC權(quán)限管理但我建議至少做一個(gè)簡(jiǎn)單的“登錄過(guò)濾器”——讓后臺(tái)所有控制器都繼承一個(gè)帶登錄校驗(yàn)的基類控制器未登錄就跳轉(zhuǎn)登錄頁(yè)。ThinkPHP5的中間件機(jī)制很適合干這個(gè)事在 base.php 里注冊(cè)一個(gè) LoginCheck 中間件再用中間件的參數(shù)排除掉 login 相關(guān)接口十幾行代碼的事但整個(gè)后臺(tái)的安全感完全不一樣。4. 實(shí)操過(guò)程中的細(xì)節(jié)與避坑4.1 環(huán)境搭建的坑拿這個(gè)項(xiàng)目練手或做畢設(shè)我強(qiáng)烈建議直接用集成環(huán)境來(lái)搭運(yùn)行環(huán)境——比如用現(xiàn)成的PHP集成面板一次性搞定PHP 7.x、MySQL 5.7、Apache/Nginx。ThinkPHP5官方要求PHP版本大于5.4但我實(shí)測(cè)下來(lái)PHP 7.0以上才能完全發(fā)揮ThinkPHP5的性能優(yōu)勢(shì)而且很多擴(kuò)展庫(kù)比如驗(yàn)證碼類庫(kù)在PHP7.0下運(yùn)行更穩(wěn)定。有一個(gè)坑必須提ThinkPHP5的官方文檔以5.0版本為基準(zhǔn)但5.1版本在數(shù)據(jù)結(jié)構(gòu)上有一些變化比如Db::name()與Db::table()的區(qū)別、模型查詢的返回值類型等。很多網(wǎng)上教程都是照著5.0寫的如果你用的5.1直接照抄代碼可能跑不通。我的建議是鎖定一個(gè)版本推薦5.0.24或5.1.41這兩個(gè)比較成熟的版本然后所有資料都搜對(duì)應(yīng)版本的關(guān)鍵詞。還有一個(gè)環(huán)境層面的隱蔽問(wèn)題偽靜態(tài)配置。ThinkPHP5的URL默認(rèn)是入口文件加參數(shù)的方式比如/index.php?s/index/index/index這種URL雖然能用但很丑而且容易被某些WEB環(huán)境誤判為安全風(fēng)險(xiǎn)。正確的做法是配置偽靜態(tài)規(guī)則讓URL變成/index/index/index這種簡(jiǎn)潔模式。Apache和Nginx的偽靜態(tài)規(guī)則在文檔里都有但很多人忽略了一個(gè)細(xì)節(jié)配置完后必須重啟服務(wù)而且要把入口文件的App斷點(diǎn)設(shè)置到public目錄。4.2 權(quán)限設(shè)計(jì)與會(huì)話管理很多做這類系統(tǒng)的人前臺(tái)用戶和后臺(tái)管理員用的是同一個(gè)數(shù)據(jù)表這個(gè)設(shè)計(jì)我認(rèn)為不太妥當(dāng)。原因很簡(jiǎn)單在后續(xù)擴(kuò)展時(shí)前臺(tái)用戶能訪問(wèn)的接口和后臺(tái)管理員能訪問(wèn)的接口經(jīng)常不一樣如果混在一張表里所有權(quán)限判斷都要先去判斷身份代碼寫起來(lái)很別扭。分開(kāi)處理的好處是用戶登錄態(tài)存到 session 或者使用 token 時(shí)可以直接帶上身份前綴比如user_1和admin_1后面再擴(kuò)展永遠(yuǎn)不用回頭改鑒權(quán)邏輯。會(huì)話管理方面ThinkPHP5默認(rèn)使用Session保存登錄態(tài)我在實(shí)操中建議把Session過(guò)期時(shí)間設(shè)置得短一點(diǎn)比如兩個(gè)小時(shí)并開(kāi)啟var_session_invalidate相關(guān)的配置防止Session文件堆積過(guò)多。如果你做了API接口給移動(dòng)端用還得考慮用Token機(jī)制建議為每條請(qǐng)求生成一個(gè)唯一Token而不是直接把用戶ID傳給后端這些細(xì)節(jié)雖然不復(fù)雜但能體現(xiàn)工程化思維。4.3 前端樣式與組件選型前端部分不用自己從零寫直接在知名UI框架上改就行。我經(jīng)常推薦的前端方案是后臺(tái)用免費(fèi)的AdminLTE或者現(xiàn)成的后臺(tái)管理模板基于Bootstrap前臺(tái)頁(yè)面則根據(jù)場(chǎng)地的運(yùn)動(dòng)屬性做定制設(shè)計(jì)。注意一個(gè)易踩的坑官方模板里很多是jQuery風(fēng)格插件而前端設(shè)計(jì)如果用了現(xiàn)代CSS框架引入順序一旦寫錯(cuò)頁(yè)面直接就崩了。最好的辦法是選擇一個(gè)整體打包好的Bootstrap模板不要自己混搭多個(gè)來(lái)源的組件庫(kù)除非你對(duì)前端打包非常熟練。我實(shí)操時(shí)會(huì)把公共部分比如頭部導(dǎo)航、側(cè)邊欄、底部信息放到include文件里用ThinkPHP5的{include filecommon/header /}標(biāo)簽引入。這個(gè)習(xí)慣看似無(wú)足輕重但至少能在你改完公共內(nèi)容后少改幾十個(gè)文件。關(guān)于地圖功能如果有定位和地圖展示盡量使用現(xiàn)成的地圖JavaScript API不要自己去實(shí)現(xiàn)坐標(biāo)系統(tǒng)。千萬(wàn)不要在畢業(yè)設(shè)計(jì)里自研地圖一旦涉及坐標(biāo)轉(zhuǎn)換、離線瓦片這些內(nèi)容工作量會(huì)指數(shù)級(jí)上升核心業(yè)務(wù)還沒(méi)有做完就已經(jīng)崩潰了。4.4 安全與防刷容易被忽視的加分項(xiàng)畢業(yè)設(shè)計(jì)往往重功能、輕安全但這塊恰恰是答辯時(shí)可以拉開(kāi)差距的地方。我建議把下面三個(gè)安全點(diǎn)至少做上一個(gè)寫進(jìn)論文里也能撐起一節(jié)。第一密碼不能明文存儲(chǔ)。用ThinkPHP5自帶的password_hash()函數(shù)做哈希校驗(yàn)用password_verify()。這不是什么高深技術(shù)但很多同學(xué)還是把密碼直接放在數(shù)據(jù)庫(kù)里被答辯老師看到印象分直接打?qū)φ邸５诙乐筍QL注入。ThinkPHP5框架本身對(duì)SQL注入做了不少防護(hù)比如where(id, 1)這種鏈?zhǔn)讲樵兌际穷A(yù)編譯的。但如果你圖方便在查詢條件里直接拼接了字符串比如-where(id . $input)那就等于繞開(kāi)了框架的防護(hù)等于裸奔。群里經(jīng)常有人跑來(lái)說(shuō)系統(tǒng)被刪庫(kù)了一問(wèn)基本都是在SQL里拼了用戶輸入。第三防止接口被惡意刷。預(yù)約系統(tǒng)天然有被腳本刷單的風(fēng)險(xiǎn)。最簡(jiǎn)單的防護(hù)是給預(yù)約接口加上圖形驗(yàn)證碼我在實(shí)現(xiàn)時(shí)會(huì)用驗(yàn)證碼擴(kuò)展同時(shí)限定單個(gè)用戶單日最多生成10個(gè)待支付訂單。這個(gè)邏輯在訂單寫入前判斷一下就好代碼量不大但對(duì)真實(shí)性的提升很明顯。5. 常見(jiàn)問(wèn)題與排查技巧實(shí)錄5.1 高頻報(bào)錯(cuò)和處理方案我在調(diào)試這種預(yù)約類項(xiàng)目時(shí)總結(jié)了一份“高頻報(bào)錯(cuò)速查表”在這里分享給大家每一條都是實(shí)際踩過(guò)的報(bào)錯(cuò)現(xiàn)象根因分析解決辦法Class app\index\controller\Base not found控制器繼承的基類命名空間寫錯(cuò)檢查控制器的namespace聲明以及 use 語(yǔ)句的路徑頁(yè)面白屏無(wú)任何輸出PHP語(yǔ)法錯(cuò)誤或未開(kāi)啟錯(cuò)誤顯示在app.php中開(kāi)啟show_error_msg true檢查日志文件SQLSTATE[HY000]: General error數(shù)據(jù)表字段與代碼字段不一致對(duì)比代碼中的字段名與數(shù)據(jù)庫(kù)中實(shí)際字段特別是create_time是否存在表單提交后收不到數(shù)據(jù)請(qǐng)求方式或字段名不匹配檢查form表單method是否POST、name屬性是否與$this-request-post()獲取的鍵名一致時(shí)間顯示為時(shí)間戳一串?dāng)?shù)字PHP配置中時(shí)區(qū)或格式化漏了查詢后用date(Y-m-d H:i:s, $item[create_time])格式化驗(yàn)證碼無(wú)法顯示GD庫(kù)未開(kāi)啟修改PHP配置文件解除gd擴(kuò)展的注釋重啟服務(wù)最終極的一招排查法是在開(kāi)發(fā)階段就開(kāi)啟調(diào)試模式。ThinkPHP5的.env文件里把a(bǔ)pp_debug設(shè)為true頁(yè)面下方會(huì)把執(zhí)行SQL、文件加載、運(yùn)行時(shí)間全部列出來(lái)。我曾經(jīng)幫人排查一個(gè)點(diǎn)擊預(yù)約按鈕后毫無(wú)反應(yīng)的Bug打開(kāi)調(diào)試模式發(fā)現(xiàn)是SQL語(yǔ)句里字段名寫錯(cuò)了被拋出的SQL異常精準(zhǔn)定位到是哪一個(gè)表哪一個(gè)字段兩分鐘解決。所以第一個(gè)建議就是開(kāi)發(fā)期間永遠(yuǎn)開(kāi)著調(diào)試模式關(guān)掉它只會(huì)讓問(wèn)題藏得更深。5.2 數(shù)據(jù)上出現(xiàn)的小數(shù)和精度問(wèn)題價(jià)格計(jì)算是預(yù)約系統(tǒng)逃不開(kāi)的一個(gè)點(diǎn)。很多人會(huì)直接用float類型來(lái)存價(jià)格和算總額但一定要警惕浮點(diǎn)數(shù)的精度問(wèn)題。比方說(shuō) 0.1 0.2 在計(jì)算機(jī)里并不是 0.3而是 0.30000000000000004。價(jià)格字段必須用decimal而且在PHP中做運(yùn)算時(shí)建議使用整數(shù)分單位換成分來(lái)運(yùn)算或者至少使用bcadd、bcmul這類高精度函數(shù)。// 計(jì)算訂單總價(jià)單位換算成分 $totalPrice bcmul($venue[price], $hours, 2);bcmul第三個(gè)參數(shù)是保留小數(shù)位數(shù)傳2就代表保留兩位。用這種方式算出來(lái)的金額用于寫入訂單表不會(huì)出現(xiàn)莫名其妙的25.00000001這種數(shù)。這個(gè)坑可以說(shuō)是所有電商類系統(tǒng)都會(huì)遇到的提前做對(duì)晚上睡得踏實(shí)。價(jià)格之外還有一個(gè)常見(jiàn)的坑是日期處理。PHP 的date(w)返回的是0到6的數(shù)字0代表周日很多人在做“按星期幾開(kāi)放場(chǎng)地”時(shí)習(xí)慣讓1代表周一于是有個(gè)“周日沒(méi)場(chǎng)地”的Bug。我的建議是直接用PHP的date(N), 它返回1到7周一為1周日為7跟中國(guó)人的習(xí)慣一致避免偏移。5.3 并發(fā)與性能的討論邊界“并發(fā)”這個(gè)詞對(duì)畢業(yè)設(shè)計(jì)來(lái)說(shuō)其實(shí)是個(gè)敏感話題。要搞清楚程度你不需要做分布式、不需要做消息隊(duì)列但你需要證明自己“知道并發(fā)是什么并做了一定程度的應(yīng)對(duì)”。這個(gè)系統(tǒng)里并發(fā)最高的場(chǎng)景就是“多人同時(shí)搶同一個(gè)熱門場(chǎng)地的時(shí)間段”。我在代碼里用悲觀鎖解決沖突前面已經(jīng)介紹過(guò)這已經(jīng)能覆蓋絕大多數(shù)場(chǎng)景。如果再往深走一層可以談?wù)勏旅鎺讉€(gè)思路供論文和答辯參考用數(shù)據(jù)庫(kù)的唯一約束兜底。比如給表加一個(gè)唯一索引包含venue_id,book_date,start_time,end_time, 如果兩條同一時(shí)段的訂單同時(shí)插入數(shù)據(jù)庫(kù)直接報(bào)重復(fù)鍵錯(cuò)誤再在業(yè)務(wù)層捕獲這個(gè)錯(cuò)誤就形成保單機(jī)制。使用Redis分布式鎖把“檢查沖突”和“寫入訂單”放到鎖內(nèi)執(zhí)行。但注意如果題目環(huán)境沒(méi)裝Redis這條只能作為設(shè)計(jì)說(shuō)明寫不能作為實(shí)際運(yùn)行方案。把訂單狀態(tài)更細(xì)分比如“已鎖定時(shí)段”和“已支付訂單”分開(kāi)。鎖定的超時(shí)釋放等支付成功后再轉(zhuǎn)成正式訂單。我建議在論文里寫明自己采用的方案、方案的局限性和更優(yōu)方案這比通篇只寫“我用了什么”要更有深度。5.4 展示項(xiàng)目時(shí)不可忽視的資料整理代碼寫完了項(xiàng)目跑通了這一步才算真正到“文稿”環(huán)節(jié)。很多開(kāi)發(fā)能力不錯(cuò)的同學(xué)項(xiàng)目演示時(shí)十分鐘就講完了答辯老師一臉茫然最后只給個(gè)及格分非?？上?。演示建議按這樣的順序來(lái)先講項(xiàng)目背景和需求帶出你的功能模塊圖再講數(shù)據(jù)庫(kù)設(shè)計(jì)展示ER圖和每張表的設(shè)計(jì)理由然后進(jìn)入系統(tǒng)實(shí)操演示按“用戶注冊(cè) - 瀏覽場(chǎng)地 - 預(yù)約 - 支付 - 后臺(tái)管理”這條線走一遍演示的同時(shí)說(shuō)出你設(shè)計(jì)的亮點(diǎn)比如時(shí)間沖突檢測(cè)、訂單防超賣機(jī)制。數(shù)據(jù)庫(kù)設(shè)計(jì)盡量畫一張規(guī)范的表結(jié)構(gòu)關(guān)系圖也就是ER圖不用追求花哨把表關(guān)鍵字段和連接關(guān)系畫清楚就行。這張圖在答辯時(shí)幾乎是必問(wèn)的。代碼部分我不建議貼大段代碼而是準(zhǔn)備兩張關(guān)鍵截圖比如沖突檢測(cè)SQL和事務(wù)代碼的截圖講清楚這兩段代碼對(duì)應(yīng)什么業(yè)務(wù)這樣時(shí)間分配更合理老師也更容易抓到重點(diǎn)。結(jié)尾這個(gè)項(xiàng)目做下來(lái)我個(gè)人最大的體會(huì)是畢業(yè)設(shè)計(jì)拼的從來(lái)不是誰(shuí)的技術(shù)更炫而是誰(shuí)的基本功更扎實(shí)、業(yè)務(wù)理解更透徹。一個(gè)預(yù)約系統(tǒng)能把用戶登錄、場(chǎng)地管理、訂單狀態(tài)流轉(zhuǎn)、沖突檢測(cè)這些基礎(chǔ)模塊寫得干凈利落比硬塞一堆用不上的高深框架更有說(shuō)服力。而且這類系統(tǒng)的業(yè)務(wù)模式很通用——會(huì)議室預(yù)約、實(shí)驗(yàn)室預(yù)約、自習(xí)室占座其實(shí)都是同一套骨架換皮學(xué)會(huì)了一個(gè)后面遇到類似項(xiàng)目都能快速上手。最后再分享一個(gè)小建議結(jié)構(gòu)差不多的話可以給前臺(tái)加一個(gè)簡(jiǎn)單的數(shù)據(jù)統(tǒng)計(jì)頁(yè)比如“本周熱門場(chǎng)地排行”用一條group by查一下哪個(gè)場(chǎng)地的訂單最多前端再用一個(gè)小圖表展示出來(lái)。這個(gè)功能代碼量不大但能讓整個(gè)系統(tǒng)的完整度和答辯觀感上一個(gè)大臺(tái)階。祝你順利。