看到基于flask-django這種題目的時(shí)候不少同學(xué)第一反應(yīng)是:這倆框架是不是得二選一?或者怕寫(xiě)成用Django做了個(gè)主頁(yè)、用Flask做了個(gè)登錄頁(yè)的縫合怪。其實(shí)這類(lèi)設(shè)計(jì)題目真正想考察的是你能不能理解兩個(gè)Web框架各自的能力邊界并且用一套合理的架構(gòu)讓它們協(xié)作完成一個(gè)完整業(yè)務(wù)。這個(gè)校園個(gè)人閑置物品換購(gòu)平臺(tái)我當(dāng)初從需求分析到部署上線完整走了一遍坑踩了不少但做完之后對(duì)Python Web開(kāi)發(fā)的理解確實(shí)上了一個(gè)臺(tái)階。這篇文章我會(huì)把整套設(shè)計(jì)思路、核心數(shù)據(jù)表結(jié)構(gòu)、雙框架協(xié)作方式、關(guān)鍵代碼實(shí)現(xiàn)以及部署階段遇到的真實(shí)問(wèn)題全部梳理出來(lái)。不管你是要做課程設(shè)計(jì)、畢業(yè)設(shè)計(jì)還是單純想練手兩個(gè)主流Python框架這篇都值得看完。1. 雙框架并存的核心思路:主業(yè)務(wù)收斂、輔助功能外放先直接說(shuō)結(jié)論:一個(gè)項(xiàng)目里同時(shí)出現(xiàn)Flask和Django絕不是讓它們做重復(fù)的事而是讓每個(gè)框架去做自己最擅長(zhǎng)的事。1.1 Django和Flask的能力邊界Django自帶ORM、Admin后臺(tái)、用戶(hù)認(rèn)證體系、表單處理、CSRF防護(hù)這種全家桶特性非常適合承載業(yè)務(wù)主鏈路。對(duì)于校園閑置物品換購(gòu)平臺(tái)來(lái)說(shuō)用戶(hù)注冊(cè)登錄、物品發(fā)布、訂單交易、后臺(tái)審核這些核心模塊用Django來(lái)做能省掉大量重復(fù)造輪子的工作而且數(shù)據(jù)模型和數(shù)據(jù)庫(kù)遷移都通過(guò)Django ORM統(tǒng)一管理代碼維護(hù)成本低。Flask則是一個(gè)輕量級(jí)框架它不替你做任何決定但勝在靈活、啟動(dòng)快、寫(xiě)小服務(wù)非常順手。在這個(gè)項(xiàng)目里我把推薦接口、數(shù)據(jù)統(tǒng)計(jì)聚合、圖片壓縮處理這類(lèi)相對(duì)獨(dú)立的輔助功能放到了Flask側(cè)。這類(lèi)功能的特點(diǎn)是:邏輯相對(duì)獨(dú)立、調(diào)用頻率可能很高、不影響主交易流程即使某個(gè)接口掛了也不能拖垮用戶(hù)下單。1.2 雙框架協(xié)作的三種常見(jiàn)模式我見(jiàn)過(guò)不少團(tuán)隊(duì)做這類(lèi)雙框架項(xiàng)目拆法大致有三種:協(xié)作模式實(shí)現(xiàn)方式適用場(chǎng)景優(yōu)缺點(diǎn)方式A:共享數(shù)據(jù)庫(kù)獨(dú)立服務(wù)Django跑主站Flask跑API子服務(wù)兩者連同一個(gè)MySQL通過(guò)HTTP接口互相調(diào)用課程設(shè)計(jì)、畢業(yè)設(shè)計(jì)也是本文采用的方案架構(gòu)清晰、容易演示但要注意兩個(gè)框架訪問(wèn)同一批表時(shí)的模型一致性問(wèn)題方式B:主進(jìn)程嵌入用werkzeug的DispatcherMiddleware把Flask應(yīng)用作為Django的子應(yīng)用掛載只想演示同時(shí)使用了兩個(gè)框架時(shí)用來(lái)交差部署簡(jiǎn)單但兩個(gè)框架的session、中間件會(huì)互相干擾后期難維護(hù)方式C:完全微服務(wù)化各自獨(dú)立數(shù)據(jù)庫(kù)通過(guò)REST API松耦合通信分布式結(jié)課項(xiàng)目演示效果好但數(shù)據(jù)一致性難保證工作量也大我最終選了方式A。理由很現(xiàn)實(shí):課程設(shè)計(jì)和畢設(shè)的評(píng)審老師最看重的是業(yè)務(wù)閉環(huán)也就是用戶(hù)能發(fā)布物品、能下單、能完成換購(gòu)。共享一個(gè)MySQL能保證交易的強(qiáng)一致性Flask只負(fù)責(zé)讀多寫(xiě)少的輔助接口就算Flask掛了Django站點(diǎn)的核心功能也不受影響。這其實(shí)是真實(shí)企業(yè)里主業(yè)務(wù)收斂、輔助功能外放思想的一個(gè)簡(jiǎn)化版答辯的時(shí)候這樣講非常加分。1.3 為什么推薦先設(shè)計(jì)架構(gòu)而不是先寫(xiě)代碼很多同學(xué)拿到題目第一件事就是django-admin startproject然后就開(kāi)始寫(xiě)models。我的建議是反過(guò)來(lái)先花半天時(shí)間把這個(gè)平臺(tái)到底有哪些角色、哪些核心流程、哪些狀態(tài)想清楚。你可以問(wèn)自己三個(gè)問(wèn)題:誰(shuí)是系統(tǒng)用戶(hù)?學(xué)生、管理員還可能有什么?最核心的流程是什么?發(fā)布物品、發(fā)起換購(gòu)、確認(rèn)交換、互相評(píng)價(jià)。哪些功能寫(xiě)進(jìn)Django哪些拆給Flask?根據(jù)依賴(lài)關(guān)系劃分而不是按頁(yè)面劃分。想清楚這三個(gè)問(wèn)題后面寫(xiě)代碼就是照?qǐng)D施工而不是邊寫(xiě)邊改。這個(gè)項(xiàng)目里我最深刻的體會(huì)就是:前期架構(gòu)多花的時(shí)間后期至少能省三倍。2. 校園換購(gòu)平臺(tái)的需求本質(zhì):不是簡(jiǎn)單二手交易閑置物品換購(gòu)聽(tīng)起來(lái)和閑魚(yú)、轉(zhuǎn)轉(zhuǎn)差不多但落在校園場(chǎng)景里需求邏輯其實(shí)有明顯區(qū)別。搞清楚這些數(shù)據(jù)庫(kù)表設(shè)計(jì)才有的放矢。2.1 校園場(chǎng)景的三個(gè)核心差異第一,用戶(hù)身份天然可信。注冊(cè)必須綁定學(xué)校域名郵箱或?qū)W號(hào)這意味著平臺(tái)內(nèi)交易雙方的違約成本更高不需要像閑魚(yú)那樣做復(fù)雜的芝麻信用體系。第二,交易以線下自提為主。大學(xué)生活動(dòng)范圍高度集中宿舍區(qū)、教學(xué)樓、食堂就是天然的交貨點(diǎn)。所以系統(tǒng)不需要物流模塊但要記錄交易地點(diǎn)偏好比如只限本校圖書(shū)館自提。第三,換購(gòu)包含了物物交換和補(bǔ)差價(jià)。這是這個(gè)項(xiàng)目和普通二手交易平臺(tái)最大的區(qū)別。用戶(hù)發(fā)布物品時(shí)除了標(biāo)價(jià)還可以寫(xiě)明想交換什么比如用一臺(tái)Kindle換一副降噪耳機(jī)可以補(bǔ)差價(jià)50元。這意味著訂單表的設(shè)計(jì)不能只有買(mǎi)家、賣(mài)家、金額三個(gè)字段。2.2 核心角色與功能邊界我把系統(tǒng)拆成前臺(tái)、后臺(tái)、輔助服務(wù)三塊:角色核心功能所屬框架普通學(xué)生注冊(cè)登錄、瀏覽物品、發(fā)布閑置、發(fā)起換購(gòu)、留言詢(xún)問(wèn)、確認(rèn)收貨、評(píng)價(jià)Django系統(tǒng)管理員審核物品、處理舉報(bào)、用戶(hù)封禁、數(shù)據(jù)統(tǒng)計(jì)Django Admin Flask統(tǒng)計(jì)接口輔助服務(wù)物品推薦、瀏覽量統(tǒng)計(jì)、圖片壓縮、Excel導(dǎo)出Flask功能邊界定了之后頁(yè)面結(jié)構(gòu)就清楚了。前臺(tái)總共沒(méi)幾個(gè)頁(yè)面:首頁(yè)(物品流)、物品詳情、發(fā)布頁(yè)、個(gè)人中心、訂單列表、站內(nèi)信。管理后臺(tái)直接用Django Admin改一改就夠用不需要額外寫(xiě)。2.3 交易狀態(tài)機(jī):整個(gè)業(yè)務(wù)最核心的部分換購(gòu)流程不是簡(jiǎn)單的下單-付款-發(fā)貨-收貨因?yàn)榇嬖陔p方交換物品的情況狀態(tài)機(jī)必須多幾條分支。我自己項(xiàng)目里的狀態(tài)流轉(zhuǎn)是這樣設(shè)計(jì)的:用戶(hù)A發(fā)布物品X,狀態(tài)為在售。用戶(hù)B發(fā)起購(gòu)買(mǎi)或換購(gòu)請(qǐng)求物品X變?yōu)榻灰字型瑫r(shí)生成一條訂單記錄。雙方約定時(shí)間地點(diǎn)線下驗(yàn)貨。雙方都在系統(tǒng)中點(diǎn)擊確認(rèn)交換或確認(rèn)收貨訂單變?yōu)橐淹瓿?。如果任何一方在交易中超時(shí)未確認(rèn)可以申請(qǐng)取消訂單變?yōu)橐讶∠锲稾自動(dòng)回到在售。單獨(dú)把換購(gòu)拎出來(lái)說(shuō):當(dāng)B提出我想用物品Y換你的X時(shí)系統(tǒng)要同時(shí)鎖定X和Y兩件物品直到雙方確認(rèn)完成或者取消。這個(gè)雙向鎖定邏輯容易漏寫(xiě)業(yè)務(wù)代碼里一定要同時(shí)處理兩個(gè)物品的狀態(tài)。3. 數(shù)據(jù)庫(kù)設(shè)計(jì):換購(gòu)業(yè)務(wù)的核心表長(zhǎng)什么樣選型上我用了MySQL 8.0原因無(wú)他校園網(wǎng)環(huán)境里MySQL最通用后面查資料、找問(wèn)題都容易。Django側(cè)用ORM管理表結(jié)構(gòu)Flask側(cè)通過(guò)SQLAlchemy讀取同一批表。3.1 用戶(hù)表與擴(kuò)展資料表Django自帶的auth_user不要直接改而是建一張profile表一對(duì)一關(guān)聯(lián)。需要存的就是學(xué)號(hào)、學(xué)校郵箱、宿舍區(qū)域、信用分、頭像路徑。class Profile(models.Model): user models.OneToOneField(User, on_deletemodels.CASCADE, related_nameprofile) student_id models.CharField(max_length20, uniqueTrue, verbose_name學(xué)號(hào)) campus_email models.EmailField(uniqueTrue, verbose_name校園郵箱) dorm_area models.CharField(max_length50, blankTrue, verbose_name宿舍區(qū)域) credit_score models.IntegerField(default100, verbose_name信用分) avatar models.ImageField(upload_toavatars/, blankTrue)為什么不直接在User上加字段?因?yàn)镈jango的User模型被Admin、認(rèn)證、session到處引用直接改字典字段容易在后續(xù)升級(jí)或第三方庫(kù)適配時(shí)報(bào)錯(cuò)。一對(duì)一的Profile幾乎是所有Django項(xiàng)目的標(biāo)準(zhǔn)做法。3.2 物品表:狀態(tài)和換購(gòu)意向是靈魂物品表是整個(gè)平臺(tái)的流量核心字段設(shè)計(jì)直接影響后續(xù)的檢索和交易。class Item(models.Model): STATUS_CHOICES [ (on_sale, 在售), (trading, 交易中), (sold, 已售出), (off_shelf, 已下架), ] title models.CharField(max_length100) category models.ForeignKey(Category, on_deletemodels.SET_NULL, nullTrue) description models.TextField() price models.DecimalField(max_digits8, decimal_places2) want_exchange models.CharField(max_length200, blankTrue, verbose_name想換的物品) condition_level models.IntegerField(choices[(i, f{i}成新) for i in range(1, 11)]) image models.ImageField(upload_toitems/) owner models.ForeignKey(User, on_deletemodels.CASCADE, related_nameitems) status models.CharField(max_length20, choicesSTATUS_CHOICES, defaulton_sale) view_count models.IntegerField(default0) created_at models.DateTimeField(auto_now_addTrue)這里有一個(gè)值得說(shuō)的細(xì)節(jié):condition_level我用了0到10的成新度而不是幾乎全新/輕微使用痕跡這樣的模糊描述。原因很簡(jiǎn)單:成新度便于后期用SQL做排序和篩選比如只看九成新以上的物品文本字段就沒(méi)法高效查。3.3 訂單表:換購(gòu)和購(gòu)買(mǎi)共用一張表我見(jiàn)過(guò)很多項(xiàng)目把購(gòu)買(mǎi)訂單和換購(gòu)訂單分成兩張表,這是個(gè)坑。因?yàn)閾Q購(gòu)本質(zhì)上就是雙方互為買(mǎi)家和賣(mài)家的交易拆成兩張表后查詢(xún)我參與過(guò)的所有交易就變得非常痛苦。正確的做法是用一張order表通過(guò)判斷exchange_item字段是否為空來(lái)區(qū)分交易類(lèi)型:字段類(lèi)型說(shuō)明id主鍵訂單號(hào)itemFK主物品buyerFK發(fā)起交易的人sellerFK物品發(fā)布者exchange_itemFK可空若為換購(gòu)則指向買(mǎi)家提供的物品priceDecimal成交價(jià)或補(bǔ)差價(jià)statusCharFieldpending / confirmed / completed / cancelledcreated_at / updated_atDateTime記錄時(shí)間關(guān)鍵邏輯是:如果exchange_item不為空那么這筆訂單成交時(shí)buyer的exchange_item狀態(tài)必須變?yōu)閟old同時(shí)item狀態(tài)變?yōu)閟old。這兩個(gè)更新必須放在同一個(gè)數(shù)據(jù)庫(kù)事務(wù)里否則會(huì)出現(xiàn)A以為換成功了、B的物品還掛著賣(mài)的數(shù)據(jù)錯(cuò)亂。3.4 留言、舉報(bào)、評(píng)價(jià)表這三張表結(jié)構(gòu)都比較簡(jiǎn)單。留言表關(guān)聯(lián)物品和用戶(hù);舉報(bào)表關(guān)聯(lián)被舉報(bào)的物品或留言;評(píng)價(jià)表關(guān)聯(lián)訂單買(mǎi)家和賣(mài)家各自只能評(píng)價(jià)一次用order_id reviewer_id做聯(lián)合唯一約束。這些都屬于快速迭代的表先建起來(lái)后續(xù)有需求再加字段就行。數(shù)據(jù)庫(kù)設(shè)計(jì)這塊我的實(shí)際經(jīng)驗(yàn)是:不要想著一步到位建出完美表結(jié)構(gòu)先讓核心交易閉環(huán)跑通再根據(jù)實(shí)際頁(yè)面反饋補(bǔ)索引和字段。這個(gè)項(xiàng)目里我最開(kāi)始沒(méi)給item.status加索引結(jié)果數(shù)據(jù)量到幾千條時(shí)首頁(yè)查詢(xún)明顯變慢后來(lái)才補(bǔ)上。對(duì)課程設(shè)計(jì)級(jí)別的數(shù)據(jù)量來(lái)說(shuō)這一步不做也沒(méi)事但知道了對(duì)答辯有好處。4. Django主站:從注冊(cè)登錄到訂單流轉(zhuǎn)的實(shí)現(xiàn)Django側(cè)承載了平臺(tái)的全部寫(xiě)操作我按用戶(hù)-物品-訂單-后臺(tái)四條線來(lái)講。4.1 校園身份驗(yàn)證:注冊(cè)時(shí)攔截非校園郵箱校園平臺(tái)最大的特色是身份可信所以注冊(cè)環(huán)節(jié)要攔住校外人。實(shí)現(xiàn)方式就是在UserCreationForm的子類(lèi)里重寫(xiě)clean_email強(qiáng)制郵箱后綴為學(xué)校域名。class CampusUserCreationForm(UserCreationForm): email forms.EmailField(requiredTrue) def clean_email(self): email self.cleaned_data[email].lower() if not email.endswith(your-university.edu.cn): raise forms.ValidationError(請(qǐng)使用校園郵箱注冊(cè)) return email這里的your-university.edu.cn替換成你自己的學(xué)校域名即可。另一個(gè)可選的驗(yàn)證是讓用戶(hù)填學(xué)號(hào)再和管理員維護(hù)的學(xué)號(hào)表比對(duì)不過(guò)課程設(shè)計(jì)階段用郵箱后綴就夠用了。4.2 物品發(fā)布的圖片處理物品發(fā)布頁(yè)用ModelForm綁定Item模型圖片上傳這塊有幾個(gè)容易踩的坑。第一個(gè)是默認(rèn)的ImageField一次只支持一張圖想支持多圖就得建一個(gè)ItemImage子表;第二個(gè)是用戶(hù)上傳的原圖動(dòng)輒幾兆直接存服務(wù)器既浪費(fèi)空間又拖慢頁(yè)面加載。我的做法是在保存時(shí)用Pillow把圖片壓縮兩份:一份是列表頁(yè)用的縮略圖(例如400x300裁剪)一份是詳情頁(yè)用的原圖(限制最大邊1600px)。上傳邏輯寫(xiě)在form.save()里重寫(xiě):def save(self, commitTrue): item super().save(commitFalse) if self.cleaned_data.get(image): img Image.open(self.cleaned_data[image]) img.thumbnail((1600, 1600)) # 壓縮后保存到 MEDIA_ROOT并重新賦值路徑 if commit: item.save() return item這段代碼的核心意圖是:不要在模板里做任何圖片縮放全部在服務(wù)端生成好物理文件。Django模板層雖然也能做縮略圖但那是在每次請(qǐng)求時(shí)動(dòng)態(tài)處理的高并發(fā)下CPU直接被打滿(mǎn)。4.3 訂單狀態(tài)機(jī)的事務(wù)控制當(dāng)用戶(hù)B對(duì)物品X發(fā)起換購(gòu)時(shí)要同時(shí)做三件事:創(chuàng)建訂單、把X的狀態(tài)改為交易中、把B的物品Y的狀態(tài)也改為交易中。這三個(gè)寫(xiě)操作必須在一個(gè)原子事務(wù)里用Django的transaction.atomic包起來(lái)。from django.db import transaction transaction.atomic def create_exchange_order(item_x, item_y, buyer, price_diff): order Order.objects.create( itemitem_x, exchange_itemitem_y, buyerbuyer, selleritem_x.owner, priceprice_diff, statuspending, ) item_x.status trading item_x.save() item_y.status trading item_y.save() return order是否要用select_for_update()加行鎖?如果只是課程設(shè)計(jì)數(shù)據(jù)量小、并發(fā)低不加也能跑。但如果你在答辯時(shí)想展示自己對(duì)并發(fā)問(wèn)題的理解這是絕佳素材。select_for_update()會(huì)在數(shù)據(jù)庫(kù)層面鎖定這兩件物品的行防止兩個(gè)用戶(hù)同時(shí)發(fā)起換購(gòu)導(dǎo)致?tīng)顟B(tài)錯(cuò)亂。item_x Item.objects.select_for_update().get(pkitem_x_pk) item_y Item.objects.select_for_update().get(pkitem_y_pk)這里要提醒一句:select_for_update()必須在事務(wù)內(nèi)使用也就是說(shuō)調(diào)用這個(gè)查詢(xún)的函數(shù)要被transaction.atomic包裹否則鎖會(huì)在查詢(xún)后立刻釋放起不到作用。4.4 用Django Admin做管理后臺(tái)管理后臺(tái)我?guī)缀鯖](méi)有額外寫(xiě)頁(yè)面全部靠Django Admin定制。核心配置就是把Item、Order、Report注冊(cè)進(jìn)去并定制列表展示字段:admin.register(Item) class ItemAdmin(admin.ModelAdmin): list_display (title, owner, price, status, created_at) list_filter (status, category) search_fields (title, owner__username) actions [force_off_shelf] admin.action(description強(qiáng)制下架選中物品) def force_off_shelf(self, request, queryset): queryset.update(statusoff_shelf)actions自定義操作在處理舉報(bào)時(shí)非常管用:管理員在舉報(bào)列表里看到被舉報(bào)物品勾選、下拉選擇強(qiáng)制下架、執(zhí)行三步搞定。不需要寫(xiě)任何前端代碼。5. Flask輔助服務(wù):推薦接口和統(tǒng)計(jì)看板怎么落地Django把主要業(yè)務(wù)包圓了那Flask在項(xiàng)目里到底干什么?我這邊定了兩個(gè)明確的活:推薦接口和統(tǒng)計(jì)看板。這兩塊邏輯簡(jiǎn)單、讀多寫(xiě)少、和主流程解耦非常適合用Flask起一個(gè)輕量服務(wù)。5.1 Flask推薦接口:基于瀏覽記錄的簡(jiǎn)單協(xié)同過(guò)濾推薦這塊不用整復(fù)雜的機(jī)器學(xué)習(xí)模型課程設(shè)計(jì)階段做看過(guò)這個(gè)物品的人還在看同類(lèi)物品就夠了。算法原理很簡(jiǎn)單:根據(jù)用戶(hù)在ItemViewLog表里的瀏覽記錄找出瀏覽過(guò)當(dāng)前物品的所有用戶(hù);再查這些用戶(hù)還瀏覽過(guò)哪些同分類(lèi)的物品;按出現(xiàn)次數(shù)倒序取前6個(gè)排除用戶(hù)已擁有的物品。app.route(/api/recommend/int:item_id) def recommend(item_id): item db.session.get(Item, item_id) viewers [v.user_id for v in db.session.query(ItemViewLog).filter_by(item_iditem_id)] candidates {} for uid in viewers: for vlog in db.session.query(ItemViewLog).filter_by(user_iduid).all(): if vlog.item_id ! item_id: candidates[vlog.item_id] candidates.get(vlog.item_id, 0) 1 ranked sorted(candidates.items(), keylambda x: x[1], reverseTrue)[:6] return jsonify([{item_id: k} for k, _ in ranked])這段代碼本身沒(méi)什么技術(shù)含量但它在架構(gòu)上定義了Flask負(fù)責(zé)計(jì)算、Django負(fù)責(zé)展示的協(xié)作模式。前端頁(yè)面通過(guò)fetch(/api/recommend/3)拿到推薦列表再渲染物品卡片主站代碼保持干凈。5.2 統(tǒng)計(jì)看板:給管理員看的輕量報(bào)表第二個(gè)Flask接口是統(tǒng)計(jì)看板。我需要幾組數(shù)據(jù):每日發(fā)布物品數(shù)、當(dāng)前在售物品分類(lèi)占比、熱門(mén)物品Top10。直接在Flask里用SQLAlchemy聚合查詢(xún)?nèi)缓蠓祷豃SON前端用Chart.js渲染圖表。app.route(/api/stats/category) def stats_category(): rows db.session.query(Item.category_id, func.count(Item.id)).group_by(Item.category_id).all() return jsonify([{category_id: cid, count: cnt} for cid, cnt in rows])這個(gè)統(tǒng)計(jì)接口如果也塞進(jìn)Django里代碼量和路由復(fù)雜度都會(huì)增加。放在Flask這邊整個(gè)Django項(xiàng)目只需要在Admin后臺(tái)里嵌一個(gè)iframe或?qū)懸粋€(gè)fetch調(diào)用就能展示圖表。5.3 雙框架共享同一個(gè)MySQL的模型一致性問(wèn)題這是整個(gè)項(xiàng)目里最隱蔽的坑。Django的ORM會(huì)自動(dòng)給模型加字段和約束比如多對(duì)多關(guān)系會(huì)生成中間表在某些情況下還有局部索引。Flask的SQLAlchemy模型是從零手工寫(xiě)的兩邊字段定義稍有出入查詢(xún)結(jié)果就可能出問(wèn)題輕則查不到數(shù)據(jù)重則SQLalchemy報(bào)字段不存在。我的經(jīng)驗(yàn)是:以Django的模型為準(zhǔn)Flask側(cè)只做只讀查詢(xún)的模型定義字段精簡(jiǎn)到只定義要用到的部分并且不允許Flask側(cè)做任何寫(xiě)操作。比如Item表在Flask側(cè)只需要定義id、title、category_id、price、status、view_count這幾個(gè)字段因?yàn)橥扑]和統(tǒng)計(jì)只用到這些。這樣兩邊模型的字段交集很小出錯(cuò)的概率就低。還有一個(gè)細(xì)節(jié):created_at字段在Flasks側(cè)定義時(shí)必須加上timezoneTrue否則查出來(lái)的時(shí)間會(huì)比實(shí)際時(shí)間慢8小時(shí)。這個(gè)問(wèn)題我排查了很久最后發(fā)現(xiàn)是Django啟用了USE_TZTrueMySQL里存的是UTC時(shí)間SQLAlchemy默認(rèn)按本地時(shí)間解析兩邊時(shí)區(qū)沒(méi)有對(duì)齊。5.4 Flask服務(wù)的獨(dú)立部署Flask服務(wù)最終是作為一個(gè)獨(dú)立進(jìn)程跑的。開(kāi)發(fā)環(huán)境直接python app.py就行部署時(shí)我用Gunicorn來(lái)啟動(dòng)和Django那邊的uWSGI區(qū)分開(kāi)。這樣兩個(gè)服務(wù)互不干擾Flask掛了重啟FlaskDjango掛了重啟Django。gunicorn -w 2 -b 127.0.0.1:5001 app:app日志單獨(dú)寫(xiě)到flask_app.log方便排查問(wèn)題。6. 開(kāi)發(fā)到部署階段的真實(shí)踩坑清單這部分是全文含金量最高的地方。以下每一條我都實(shí)際遇到過(guò)不給結(jié)論直接給排查思路。6.1 Python版本和Django版本之間的兼容性先檢查服務(wù)器上的Python版本再選Django版本。Django 4.2要求Python 3.10以上如果服務(wù)器是3.8裝新版Django直接報(bào)語(yǔ)法錯(cuò)誤。我一開(kāi)始在本地Windows上用Python 3.12開(kāi)發(fā)一切正常部署到Linux服務(wù)器發(fā)現(xiàn)系統(tǒng)自帶的Python是3.8最后鎖定方案是Django 4.1.7 Flask 2.3兼容性最穩(wěn)。提示:做項(xiàng)目前先確定團(tuán)隊(duì)或?qū)嶒?yàn)室服務(wù)器的Python版本python3 --version一看便知不要想當(dāng)然裝最新版。6.2 Pillow擴(kuò)展庫(kù)裝不上的問(wèn)題圖片處理依賴(lài)Pillow在純凈系統(tǒng)上經(jīng)常裝失敗。報(bào)錯(cuò)信息通常是RequiredDependencyException: zlib或者jpeg。原因很直白:系統(tǒng)缺底層圖片庫(kù)。解決方式:# Ubuntu/Debian sudo apt-get install libjpeg-dev zlib1g-dev pip install Pillow6.3 圖片上傳后頁(yè)面404本地開(kāi)發(fā)時(shí)MEDIA_URL和MEDIA_ROOT配置正確圖片能顯示。部署到Nginx后所有圖片路徑全部404。原因是Django本身不提供靜態(tài)文件服務(wù)Nginx需要把包括/media/和/static/在內(nèi)的路徑直接代理到服務(wù)器的物理目錄。Nginx配置里加一段:location /media/ { alias /var/www/project/media/; }這個(gè)坑幾乎人人都會(huì)踩因?yàn)檫@屬于Nginx配置不屬于Django代碼教程里很少寫(xiě)清楚。6.4 表結(jié)構(gòu)改來(lái)改去的遷移災(zāi)難開(kāi)發(fā)過(guò)程中我多次修改Item模型導(dǎo)致遷移文件堆積數(shù)據(jù)庫(kù)狀態(tài)和模型不同步的怪問(wèn)題時(shí)有出現(xiàn)。后來(lái)養(yǎng)成一個(gè)習(xí)慣:每次改模型前先python manage.py makemigrations --dry-run看看即將生成的遷移操作是否符合預(yù)期再真正執(zhí)行。如果已經(jīng)亂套了怎么辦?我的經(jīng)驗(yàn)是別硬修遷移文件直接重置:python manage.py migrate app_name zero python manage.py makemigrations python manage.py migrate但前提是能接受清空該app的數(shù)據(jù)。開(kāi)發(fā)階段無(wú)所謂如果是接近答辯的數(shù)據(jù),就不要這么干。6.5 換購(gòu)并發(fā)導(dǎo)致的狀態(tài)錯(cuò)亂有次測(cè)試時(shí)發(fā)現(xiàn),兩個(gè)同學(xué)同時(shí)點(diǎn)擊換購(gòu)按鈕,同一件物品生成了兩筆訂單。原因就是查詢(xún)物品狀態(tài)和創(chuàng)建訂單不在一個(gè)事務(wù)里,也沒(méi)有加行鎖。修復(fù)方案前面已經(jīng)說(shuō)了:select_for_update()加transaction.atomic。這是一個(gè)非常好的答辯回答題目,面試官問(wèn)到如何防止超賣(mài)時(shí),你拿這個(gè)項(xiàng)目里真實(shí)修過(guò)的bug舉例,說(shuō)服力遠(yuǎn)超背書(shū)。6.6 Django時(shí)區(qū)與MySQL時(shí)區(qū)不一致前面提到Flask側(cè)查時(shí)間差8小時(shí),其實(shí)Django側(cè)也遇到過(guò)。解決方案是:# settings.py USE_TZ True TIME_ZONE Asia/Shanghai這樣Django在讀寫(xiě)MySQL時(shí)會(huì)自動(dòng)把UTC時(shí)間轉(zhuǎn)換為東八區(qū)。Flask側(cè)則是手動(dòng)datetime.now(timezone.utc)或者直接查詢(xún)時(shí)加上convert_tz。6.7 雙服務(wù)部署時(shí)Nginx的upstream配置兩個(gè)服務(wù)同時(shí)跑,前端要同時(shí)訪問(wèn)Django的/路徑和Flask的/api/路徑,靠Nginx路由區(qū)分:upstream django_backend { server 127.0.0.1:8000; } upstream flask_backend { server 127.0.0.1:5001; } server { listen 80; server_name your-domain.com; location /api/ { proxy_pass http://flask_backend; } location / { proxy_pass http://django_backend; } }這樣一個(gè)域名同時(shí)跑兩個(gè)Python Web應(yīng)用,演示的時(shí)候不用來(lái)回切換端口,交互體驗(yàn)也自然。6.8 頁(yè)面模板和靜態(tài)資源的重復(fù)加載最后是一個(gè)容易被忽略的性能問(wèn)題。Django的模板是每次請(qǐng)求都渲染一遍,如果有高頻頁(yè)面(比如首頁(yè)物品流),建議加一層緩存。最簡(jiǎn)單的做法是Django的cache_page裝飾器緩存首頁(yè)60秒:from django.views.decorators.cache import cache_page urlpatterns [ path(, cache_page(60)(views.index), nameindex), ]加完緩存后,首頁(yè)壓力大幅下降,Flask推薦接口那邊也輕松不少。7. 答辯演示和后續(xù)擴(kuò)展的建議做完項(xiàng)目到真正演示還有一段距離。我見(jiàn)過(guò)實(shí)力不錯(cuò)但演示翻車(chē)的,也見(jiàn)過(guò)功能一般但演示節(jié)奏極好的?；趯?shí)際經(jīng)驗(yàn)分享幾點(diǎn)。7.1 演示前準(zhǔn)備好種子數(shù)據(jù)和錄屏不要現(xiàn)場(chǎng)發(fā)布物品、現(xiàn)場(chǎng)拍圖。提前把一個(gè)品類(lèi)下放滿(mǎn)十幾件物品,圖片用真實(shí)拍的照片而非占位圖,這樣評(píng)委打開(kāi)首頁(yè)時(shí)視覺(jué)效果好很多。同理,推薦接口的演示也別用空數(shù)據(jù)庫(kù)去測(cè),先在ItemViewLog里造好一批瀏覽記錄,否則推薦結(jié)果永遠(yuǎn)為空。錄屏軟件開(kāi)好,萬(wàn)一現(xiàn)場(chǎng)網(wǎng)絡(luò)不穩(wěn)定或者服務(wù)沒(méi)起來(lái),放錄屏照樣能講完。7.2 講清楚框架邊界比講功能更重要答辯時(shí)評(píng)委最常問(wèn)的就是:你為什么要用Flask,Django不能做推薦接口嗎? 這時(shí)候你把第1節(jié)的架構(gòu)圖往白板上一畫(huà),說(shuō)明寫(xiě)操作集中在Django、讀密集的輔助服務(wù)放Flask、共享數(shù)據(jù)庫(kù)保證一致性,評(píng)委立刻知道你理解架構(gòu)設(shè)計(jì),而不是只會(huì)堆功能。7.3 后續(xù)可以擴(kuò)展的三個(gè)方向這個(gè)項(xiàng)目做完后,想進(jìn)一步延伸可以考慮三條線:給物品加全文搜索,用Django的SearchVector或者接入Elasticsearch,解決物品多了之后分類(lèi)篩選不好用的問(wèn)題;把推薦服務(wù)升級(jí)成基于用戶(hù)行為排序的算法,比如根據(jù)分類(lèi)偏好加權(quán),不改變架構(gòu),只改Flask側(cè)的計(jì)算邏輯;加Redis緩存熱點(diǎn)數(shù)據(jù),首頁(yè)物品流和推薦結(jié)果都緩存到Redis,進(jìn)一步減輕數(shù)據(jù)庫(kù)壓力。我自己做這個(gè)項(xiàng)目的最大體會(huì)是:技術(shù)難點(diǎn)不在某個(gè)框架的API上,而在如何讓兩個(gè)框架各司其職、協(xié)同不打架。把這個(gè)問(wèn)題想透,你就能從跟著教程敲代碼進(jìn)階到真正理解Web應(yīng)用怎么搭。希望這篇能幫你少走幾個(gè)彎路。