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