簡(jiǎn)介這是一套基于Python Django框架開(kāi)發(fā)的完整電商商城項(xiàng)目源碼面向Web后端初學(xué)者與Django進(jìn)階開(kāi)發(fā)者可用于學(xué)習(xí)典型B2C商城的核心業(yè)務(wù)邏輯與工程實(shí)踐。資源包含403個(gè)文件主體為53個(gè)Python后端代碼文件含models、views、urls等模塊、11個(gè)HTML模板頁(yè)、8個(gè)CSS樣式文件如proList.css、detail.css、login.css等體現(xiàn)多頁(yè)面布局、以及293張商品圖片素材整體壓縮包33.44MB結(jié)構(gòu)清晰覆蓋用戶認(rèn)證、商品展示、購(gòu)物車、訂單管理等關(guān)鍵功能模塊。已有3684人下載學(xué)習(xí)適合通過(guò)真實(shí)項(xiàng)目理解Django MTV架構(gòu)、ORM建模、模板渲染、靜態(tài)資源組織及前后端協(xié)同開(kāi)發(fā)流程是開(kāi)展課程設(shè)計(jì)、畢業(yè)設(shè)計(jì)或技術(shù)面試準(zhǔn)備的實(shí)用參考范例。1. 項(xiàng)目概述一個(gè)Django商城項(xiàng)目的核心價(jià)值最近在整理硬盤翻出來(lái)一個(gè)幾年前用Django寫的商城項(xiàng)目源碼打包成了商城項(xiàng)目源碼.zip。這個(gè)項(xiàng)目雖然不是什么驚天動(dòng)地的架構(gòu)但麻雀雖小五臟俱全從用戶注冊(cè)登錄到商品下單支付再到后臺(tái)管理整個(gè)電商的核心鏈路都跑通了。對(duì)于想從零開(kāi)始理解一個(gè)Web應(yīng)用是如何構(gòu)建特別是想深入Django這個(gè)“大而全”框架的朋友來(lái)說(shuō)這個(gè)源碼包的價(jià)值可能比看十篇教程都來(lái)得實(shí)在。Django在國(guó)內(nèi)Web開(kāi)發(fā)領(lǐng)域的應(yīng)用非常廣泛尤其是在需要快速構(gòu)建穩(wěn)健后臺(tái)管理系統(tǒng)的場(chǎng)景下它的ORM、Admin、表單和認(rèn)證系統(tǒng)能幫你省下大量重復(fù)造輪子的時(shí)間。這個(gè)項(xiàng)目就是一個(gè)典型的例子它沒(méi)有追求最新最炫的技術(shù)棧而是扎扎實(shí)實(shí)地用Django的核心組件解決了一個(gè)商城系統(tǒng)的基本問(wèn)題。無(wú)論你是剛學(xué)完P(guān)ython語(yǔ)法想找個(gè)實(shí)戰(zhàn)項(xiàng)目練手還是已經(jīng)有一定基礎(chǔ)想看看一個(gè)完整項(xiàng)目的代碼組織邏輯這份源碼都能提供一個(gè)清晰的參考。2. 項(xiàng)目整體架構(gòu)與設(shè)計(jì)思路拆解2.1 技術(shù)選型與架構(gòu)模式這個(gè)項(xiàng)目采用了經(jīng)典的MVC在Django中更準(zhǔn)確地說(shuō)是MTVModel-Template-View架構(gòu)模式。選擇Django而非其他框架如Flask或FastAPI核心考量在于其“開(kāi)箱即用”的特性。對(duì)于一個(gè)商城系統(tǒng)用戶認(rèn)證、后臺(tái)管理、表單處理、數(shù)據(jù)庫(kù)ORM都是剛需Django內(nèi)置的這些組件成熟穩(wěn)定能讓我們把精力集中在業(yè)務(wù)邏輯而非基礎(chǔ)設(shè)施上。后端框架自然是Django版本鎖定在3.2 LTS這是一個(gè)長(zhǎng)期支持版本在穩(wěn)定性和社區(qū)支持上找到了很好的平衡點(diǎn)。數(shù)據(jù)庫(kù)選擇了MySQL 5.7/8.0考慮到商城業(yè)務(wù)涉及較多的事務(wù)和關(guān)聯(lián)查詢關(guān)系型數(shù)據(jù)庫(kù)依然是可靠的選擇。前端沒(méi)有采用前后端分離的復(fù)雜架構(gòu)而是使用了Django原生的模板引擎Django Templates配合Bootstrap 5來(lái)構(gòu)建頁(yè)面。這種選擇對(duì)于中小型、以內(nèi)容展示和表單交互為主的商城項(xiàng)目來(lái)說(shuō)開(kāi)發(fā)效率極高避免了分離部署、接口聯(lián)調(diào)等額外復(fù)雜度。靜態(tài)資源使用Whitenoise中間件在本地和生產(chǎn)環(huán)境提供高效服務(wù)。項(xiàng)目結(jié)構(gòu)清晰遵循了Django的最佳實(shí)踐。根目錄下除了標(biāo)準(zhǔn)的manage.py和配置文件主要應(yīng)用App按功能模塊劃分users: 處理用戶注冊(cè)、登錄、個(gè)人中心、收貨地址管理。goods: 核心的商品模塊包括商品分類、品牌、SPU標(biāo)準(zhǔn)產(chǎn)品單元、SKU庫(kù)存量單位模型以及商品列表、詳情頁(yè)的展示邏輯。orders: 訂單模塊涵蓋購(gòu)物車、訂單創(chuàng)建、狀態(tài)流轉(zhuǎn)、支付回調(diào)集成模擬支付和訂單管理。payments: 支付模塊抽象了支付網(wǎng)關(guān)接口目前實(shí)現(xiàn)了支付寶沙箱和微信支付模擬接口便于理解支付流程。utils: 存放公共工具函數(shù)如自定義的裝飾器、驗(yàn)證碼生成、短信發(fā)送模擬客戶端等。2.2 核心數(shù)據(jù)模型設(shè)計(jì)解析數(shù)據(jù)模型是任何應(yīng)用的基石商城系統(tǒng)的模型設(shè)計(jì)尤其關(guān)鍵。在這個(gè)項(xiàng)目中我重點(diǎn)設(shè)計(jì)了幾個(gè)核心模型并充分考慮了擴(kuò)展性。首先是用戶模型UserProfile。我沒(méi)有直接使用Django內(nèi)置的AbstractUser進(jìn)行簡(jiǎn)單擴(kuò)展而是采用了與內(nèi)置User模型一對(duì)一關(guān)聯(lián)OneToOneField的方式。這樣做的好處是既可以利用Django強(qiáng)大的原生認(rèn)證系統(tǒng)auth模塊又可以為商城用戶定制大量額外字段如昵稱、頭像、性別、生日、默認(rèn)收貨地址等而不會(huì)污染原始的auth_user表結(jié)構(gòu)。這種設(shè)計(jì)在需要頻繁升級(jí)Django版本或與其他使用標(biāo)準(zhǔn)用戶模型的App集成時(shí)靈活性更高。商品模型的設(shè)計(jì)是另一個(gè)重點(diǎn)采用了電商領(lǐng)域常見(jiàn)的SPUSKU模式。GoodsSPU表定義了一個(gè)標(biāo)準(zhǔn)產(chǎn)品的抽象信息如商品名稱、副標(biāo)題、商品描述、所屬分類和品牌。GoodsSKU表則定義了具體的銷售屬性如顏色、尺寸、規(guī)格以及獨(dú)立的價(jià)格、庫(kù)存、銷量和上下架狀態(tài)。一個(gè)SPU對(duì)應(yīng)多個(gè)SKU。這種設(shè)計(jì)將商品的基本信息與銷售屬性解耦既能高效管理商品公共信息又能靈活應(yīng)對(duì)多規(guī)格商品的庫(kù)存和定價(jià)。分類GoodsCategory采用了自關(guān)聯(lián)parent_category字段實(shí)現(xiàn)無(wú)限級(jí)分類并通過(guò)db_indexTrue為頻繁查詢的字段建立索引。訂單模型OrderInfo和訂單商品模型OrderGoods構(gòu)成了訂單系統(tǒng)的核心。OrderInfo記錄了訂單的宏觀信息訂單號(hào)唯一、用戶、總金額、支付方式、訂單狀態(tài)使用choices選項(xiàng)定義如“待支付”、“待發(fā)貨”、“待收貨”、“已完成”、“已取消”、收貨地址快照等。OrderGoods則是一個(gè)關(guān)聯(lián)表記錄了訂單中每個(gè)SKU商品的購(gòu)買數(shù)量、成交單價(jià)下單時(shí)快照與商品實(shí)時(shí)價(jià)格解耦和評(píng)價(jià)狀態(tài)。這種設(shè)計(jì)確保了訂單數(shù)據(jù)的不可變性即使用戶后來(lái)修改了收貨地址或商品價(jià)格發(fā)生了變化歷史訂單信息依然保持不變。注意在模型字段設(shè)計(jì)時(shí)對(duì)于金額類字段如商品價(jià)格、訂單總價(jià)務(wù)必使用DecimalField并指定精確的max_digits總位數(shù)和decimal_places小數(shù)位數(shù)例如max_digits10, decimal_places2。絕對(duì)不要使用FloatField因?yàn)楦↑c(diǎn)數(shù)在計(jì)算和存儲(chǔ)時(shí)可能存在精度丟失問(wèn)題這在金融相關(guān)的業(yè)務(wù)中是致命的。3. 核心功能模塊的詳細(xì)實(shí)現(xiàn)與實(shí)操要點(diǎn)3.1 用戶系統(tǒng)從注冊(cè)登錄到個(gè)人中心用戶模塊是流量的入口。注冊(cè)功能除了常規(guī)的用戶名、密碼、手機(jī)號(hào)驗(yàn)證我還集成了圖形驗(yàn)證碼和短信驗(yàn)證碼模擬來(lái)防止惡意注冊(cè)。驗(yàn)證碼的生成使用Pillow庫(kù)繪制并將驗(yàn)證碼文本存入Redis或Session中用于校驗(yàn)。短信服務(wù)則對(duì)接了一個(gè)模擬接口在實(shí)際部署時(shí)可以輕松替換為阿里云、騰訊云等提供的短信服務(wù)SDK。登錄功能直接使用了Django內(nèi)置的authenticate()和login()函數(shù)安全可靠。但有一個(gè)關(guān)鍵細(xì)節(jié)在登錄視圖View中我不僅校驗(yàn)用戶名密碼還檢查了用戶是否被激活is_active以及是否被后臺(tái)管理員禁用。這為后續(xù)可能需要的用戶管理提供了鉤子。登錄成功后使用Django的login_required裝飾器來(lái)保護(hù)需要登錄才能訪問(wèn)的視圖例如個(gè)人中心、收貨地址管理頁(yè)面。個(gè)人中心頁(yè)面展示了用戶的基本信息、訂單概覽和收貨地址列表。收貨地址管理實(shí)現(xiàn)了增刪改查全套操作并允許用戶設(shè)置一個(gè)默認(rèn)地址。在創(chuàng)建或編輯地址時(shí)前端通過(guò)三級(jí)聯(lián)動(dòng)選擇省市區(qū)這里我預(yù)先將全國(guó)行政區(qū)劃數(shù)據(jù)導(dǎo)入到了一個(gè)單獨(dú)的Area模型中通過(guò)Ajax異步加載實(shí)現(xiàn)無(wú)刷新聯(lián)動(dòng)提升了用戶體驗(yàn)。3.2 商品展示系統(tǒng)列表、詳情與搜索商品列表頁(yè)是商城的門面。視圖View中我首先處理了查詢參數(shù)分類ID、排序方式按價(jià)格、銷量、上新、頁(yè)碼。通過(guò)Django ORM的select_related和prefetch_related方法我有效地避免了在模板中渲染商品時(shí)因外鍵關(guān)聯(lián)而產(chǎn)生的“N1查詢問(wèn)題”。例如在獲取商品列表時(shí)一次性通過(guò)select_related(category, spu)將分類和SPU信息關(guān)聯(lián)查詢出來(lái)而不是在循環(huán)中逐條查詢。商品詳情頁(yè)除了展示SKU的詳細(xì)信息、圖片輪播、規(guī)格參數(shù)外最關(guān)鍵的是庫(kù)存判斷。當(dāng)用戶選擇不同規(guī)格如顏色、尺寸時(shí)前端通過(guò)Ajax請(qǐng)求后端后端根據(jù)SKU ID實(shí)時(shí)查詢庫(kù)存并返回。庫(kù)存數(shù)量是電商系統(tǒng)的生命線所有涉及庫(kù)存增減的操作如下單、取消訂單、后臺(tái)修改都必須放在數(shù)據(jù)庫(kù)事務(wù)中處理并使用F()表達(dá)式進(jìn)行原子操作防止超賣。例如在用戶下單時(shí)from django.db import transaction, models with transaction.atomic(): # 1. 創(chuàng)建訂單保存點(diǎn) sid transaction.savepoint() try: # 2. 查詢SKU并判斷庫(kù)存使用select_for_update加行鎖防止并發(fā)修改 sku GoodsSKU.objects.select_for_update().get(idsku_id, is_launchedTrue) if sku.stock buy_count: transaction.savepoint_rollback(sid) return JsonResponse({code: 400, errmsg: 庫(kù)存不足}) # 3. 使用F表達(dá)式原子更新庫(kù)存和銷量 GoodsSKU.objects.filter(idsku_id).update( stockmodels.F(stock) - buy_count, salesmodels.F(sales) buy_count ) # 4. 創(chuàng)建訂單記錄... transaction.savepoint_commit(sid) except Exception as e: transaction.savepoint_rollback(sid) # 記錄日志并返回錯(cuò)誤搜索功能基于Django的Q對(duì)象實(shí)現(xiàn)簡(jiǎn)單的多條件過(guò)濾。對(duì)于更復(fù)雜的全文搜索需求項(xiàng)目預(yù)留了接口可以方便地集成像django-haystackWhoosh或Elasticsearch這樣的專業(yè)搜索引擎。3.3 購(gòu)物車與訂單流程的完整實(shí)現(xiàn)購(gòu)物車設(shè)計(jì)采用了混合方案用戶未登錄時(shí)購(gòu)物車數(shù)據(jù)存儲(chǔ)在瀏覽器的localStorage中用戶登錄后則同步到服務(wù)器端的數(shù)據(jù)庫(kù)Cart表中。這樣做既保證了未登錄用戶的體驗(yàn)又實(shí)現(xiàn)了登錄后數(shù)據(jù)的持久化和多端同步。購(gòu)物車表Cart很簡(jiǎn)單主要字段是用戶、SKU、商品數(shù)量和添加時(shí)間。訂單流程是電商最核心、最復(fù)雜的鏈路我將其拆解為幾個(gè)清晰的步驟并在視圖函數(shù)中嚴(yán)格校驗(yàn)每一步訂單確認(rèn)頁(yè)用戶從購(gòu)物車選擇商品進(jìn)入。視圖需要校驗(yàn)所選SKU是否有效、庫(kù)存是否充足、用戶是否有默認(rèn)收貨地址。這里會(huì)計(jì)算商品總價(jià)、運(yùn)費(fèi)生成一個(gè)訂單總金額的預(yù)覽。所有價(jià)格信息都是從數(shù)據(jù)庫(kù)實(shí)時(shí)查詢并計(jì)算的確保準(zhǔn)確性。訂單創(chuàng)建用戶提交訂單。這是整個(gè)系統(tǒng)里對(duì)數(shù)據(jù)一致性和事務(wù)性要求最高的地方。我使用了Django的transaction.atomic()裝飾器來(lái)確保以下操作在一個(gè)數(shù)據(jù)庫(kù)事務(wù)中完成從購(gòu)物車中取出選中的商品。遍歷每個(gè)商品使用select_for_update()鎖定SKU行再次檢查庫(kù)存。使用F()表達(dá)式原子性地減少庫(kù)存、增加銷量。生成唯一的訂單號(hào)采用“時(shí)間戳用戶ID隨機(jī)數(shù)”的算法。創(chuàng)建OrderInfo主訂單記錄和多個(gè)OrderGoods子訂單記錄。將購(gòu)物車中對(duì)應(yīng)的商品項(xiàng)刪除。 任何一步失敗整個(gè)事務(wù)都會(huì)回滾庫(kù)存和銷量數(shù)據(jù)保持不變保證了數(shù)據(jù)的強(qiáng)一致性。訂單支付訂單創(chuàng)建成功后跳轉(zhuǎn)到支付選擇頁(yè)。項(xiàng)目集成了支付寶和微信支付的模擬流程。以支付寶為例視圖會(huì)調(diào)用支付寶提供的Python SDK生成一個(gè)包含訂單號(hào)、金額、商品描述等信息的支付請(qǐng)求參數(shù)前端使用這些參數(shù)跳轉(zhuǎn)到支付寶的支付頁(yè)面或喚起手機(jī)支付寶App。支付成功后支付寶會(huì)異步通知回調(diào)我們指定的一個(gè)后端接口/payments/alipay/notify/。這個(gè)回調(diào)接口的處理至關(guān)重要必須驗(yàn)證支付寶傳來(lái)的簽名確保通知的真實(shí)性然后根據(jù)通知中的訂單號(hào)更新本地訂單狀態(tài)為“已支付”最后返回一個(gè)success字符串給支付寶否則支付寶會(huì)認(rèn)為通知失敗而反復(fù)重試。訂單狀態(tài)管理用戶可以在個(gè)人中心查看訂單列表和詳情。后臺(tái)管理員則可以通過(guò)Django Admin或自定義的管理后臺(tái)操作訂單狀態(tài)發(fā)貨、完成、取消等。每次狀態(tài)變更都應(yīng)記錄日志并可以考慮通過(guò)消息隊(duì)列異步發(fā)送通知如短信、郵件給用戶。實(shí)操心得在開(kāi)發(fā)支付回調(diào)接口時(shí)一定要做好日志記錄將支付寶/微信支付回調(diào)過(guò)來(lái)的所有參數(shù)無(wú)論是成功還是失敗都詳細(xì)記錄下來(lái)。因?yàn)橹Ц董h(huán)境復(fù)雜網(wǎng)絡(luò)抖動(dòng)、用戶中途關(guān)閉頁(yè)面等都可能導(dǎo)致問(wèn)題。有了完整的日志當(dāng)用戶投訴“付了款但訂單沒(méi)更新”時(shí)你才能快速定位是支付平臺(tái)的通知沒(méi)發(fā)出來(lái)還是我們的接口處理失敗了。此外回調(diào)接口的代碼必須做冪等處理即同一條支付成功的通知即使因?yàn)榫W(wǎng)絡(luò)原因被重復(fù)調(diào)用多次最終結(jié)果也應(yīng)該是訂單只被標(biāo)記為支付成功一次避免重復(fù)給用戶加積分或發(fā)貨。4. 后臺(tái)管理系統(tǒng)的快速搭建與深度定制Django Admin是這個(gè)項(xiàng)目的一大亮點(diǎn)它幾乎零代碼就為我們生成了一個(gè)功能強(qiáng)大的商品和訂單管理后臺(tái)。但默認(rèn)的Admin往往不能滿足實(shí)際業(yè)務(wù)需求需要進(jìn)行深度定制。4.1 基礎(chǔ)模型注冊(cè)與列表優(yōu)化首先在各自App的admin.py文件中使用admin.site.register(YourModel)進(jìn)行注冊(cè)。但很快你會(huì)發(fā)現(xiàn)默認(rèn)的列表頁(yè)只顯示對(duì)象的字符串表示信息量很少。這時(shí)可以通過(guò)定義ModelAdmin類來(lái)定制from django.contrib import admin from .models import GoodsSKU admin.register(GoodsSKU) class GoodsSKUAdmin(admin.ModelAdmin): # 列表頁(yè)顯示的字段 list_display [id, name, spu, category, price, stock, sales, is_launched] # 支持直接編輯的字段無(wú)需進(jìn)入詳情頁(yè) list_editable [price, stock, is_launched] # 右側(cè)過(guò)濾器 list_filter [category, is_launched, create_time] # 搜索框支持的字段 search_fields [name, spu__name, id] # 每頁(yè)顯示數(shù)量 list_per_page 50這樣管理員就能在一個(gè)頁(yè)面里快速瀏覽、搜索、篩選和編輯大量商品SKU了。4.2 復(fù)雜表單與內(nèi)聯(lián)編輯對(duì)于商品SPUGoodsSPU它下面有多個(gè)SKU我們希望在編輯SPU的同時(shí)能直接編輯或新增其關(guān)聯(lián)的SKU。這就要用到TabularInline或StackedInline。class GoodsSKUInline(admin.TabularInline): model GoodsSKU extra 1 # 默認(rèn)顯示一個(gè)空白的SKU表單 fields [name, price, stock, sales, spec] admin.register(GoodsSPU) class GoodsSPUAdmin(admin.ModelAdmin): inlines [GoodsSKUInline] # ... 其他配置現(xiàn)在在SPU的編輯頁(yè)面下方會(huì)以一個(gè)表格的形式列出所有關(guān)聯(lián)的SKU并可以直接修改或新增管理效率大大提升。4.3 自定義Action與批量操作后臺(tái)經(jīng)常需要執(zhí)行批量操作比如將選中的商品批量上架或下架。Django Admin可以很方便地定義自定義Action。def make_launched(modeladmin, request, queryset): queryset.update(is_launchedTrue) make_launched.short_description 批量上架選中的商品 def make_unlaunched(modeladmin, request, queryset): queryset.update(is_launchedFalse) make_unlaunched.short_description 批量下架選中的商品 class GoodsSKUAdmin(admin.ModelAdmin): actions [make_launched, make_unlaunched] # ... 其他配置這樣管理員在商品列表頁(yè)勾選多個(gè)商品后就可以從Action下拉菜單中執(zhí)行批量操作。4.4 字段重寫與富文本編輯器集成商品描述通常需要富文本編輯。Django Admin默認(rèn)是普通文本框我們可以集成第三方編輯器比如django-ckeditor。安裝配置后只需在ModelAdmin中重寫對(duì)應(yīng)字段的form即可from django import forms from ckeditor.widgets import CKEditorWidget class GoodsSPUAdminForm(forms.ModelForm): description forms.CharField(widgetCKEditorWidget()) class Meta: model GoodsSPU fields __all__ class GoodsSPUAdmin(admin.ModelAdmin): form GoodsSPUAdminForm現(xiàn)在SPU的描述字段就變成了一個(gè)功能強(qiáng)大的富文本編輯器。5. 項(xiàng)目部署、性能優(yōu)化與安全加固實(shí)錄5.1 從開(kāi)發(fā)到生產(chǎn)關(guān)鍵配置遷移開(kāi)發(fā)時(shí)我們使用Django自帶的開(kāi)發(fā)服務(wù)器和SQLite但生產(chǎn)環(huán)境完全不同。首先在settings.py中通過(guò)環(huán)境變量區(qū)分不同配置。關(guān)鍵改動(dòng)包括數(shù)據(jù)庫(kù)切換到MySQL或PostgreSQL配置連接池如使用django-db-connections。密鑰與調(diào)試SECRET_KEY必須從環(huán)境變量讀取絕對(duì)不能硬編碼在代碼中。DEBUG必須設(shè)置為False。靜態(tài)文件使用python manage.py collectstatic收集所有靜態(tài)文件到指定目錄如/static/然后通過(guò)Nginx直接代理或者使用白名單中間件Whitenoise對(duì)于中小流量項(xiàng)目足夠。Allowed Hosts必須設(shè)置ALLOWED_HOSTS [你的域名, 你的服務(wù)器IP]否則Django會(huì)拒絕服務(wù)。中間件生產(chǎn)環(huán)境需要添加安全相關(guān)的中間件如SecurityMiddleware自動(dòng)添加安全頭部、SessionMiddleware配置為使用數(shù)據(jù)庫(kù)或Redis緩存存儲(chǔ)Session。5.2 性能優(yōu)化實(shí)戰(zhàn)技巧隨著商品和用戶量增長(zhǎng)性能瓶頸會(huì)逐漸暴露。以下是我在實(shí)踐中總結(jié)的幾個(gè)優(yōu)化點(diǎn)數(shù)據(jù)庫(kù)查詢優(yōu)化這是最常見(jiàn)的瓶頸。持續(xù)使用django-debug-toolbar監(jiān)控頁(yè)面產(chǎn)生的SQL查詢。堅(jiān)決杜絕N1查詢善用select_related用于一對(duì)一、多對(duì)一正向關(guān)聯(lián)和prefetch_related用于多對(duì)多、一對(duì)多反向關(guān)聯(lián)。對(duì)于復(fù)雜的聚合查詢考慮使用annotate和aggregate在數(shù)據(jù)庫(kù)層面完成計(jì)算。緩存策略Django提供了強(qiáng)大的緩存框架。我將以下內(nèi)容納入了緩存全站緩存對(duì)于變化不頻繁的頁(yè)面如商品詳情頁(yè)在商品信息更新時(shí)手動(dòng)清除緩存可以使用CacheMiddleware進(jìn)行全頁(yè)面緩存。片段緩存在模板中使用{% cache 300 sidebar %}...{% endcache %}緩存頁(yè)面中某個(gè)部分如商品分類導(dǎo)航欄。數(shù)據(jù)緩存使用from django.core.cache import cacheAPI緩存昂貴的查詢結(jié)果如首頁(yè)的熱銷商品排行榜。緩存后端可以配置為Redis或Memcached。靜態(tài)文件與媒體文件務(wù)必使用CDN分發(fā)靜態(tài)文件CSS, JS, 圖片。用戶上傳的媒體文件商品圖、用戶頭像建議存儲(chǔ)到對(duì)象存儲(chǔ)服務(wù)如阿里云OSS、騰訊云COS它們帶寬大、成本低、有圖片處理能力縮略圖、水印。5.3 安全加固清單安全無(wú)小事尤其是涉及支付和用戶數(shù)據(jù)的商城系統(tǒng)。CSRF保護(hù)Django默認(rèn)已開(kāi)啟確保所有POST表單都包含{% csrf_token %}。XSS防護(hù)Django模板默認(rèn)自動(dòng)轉(zhuǎn)義HTML標(biāo)簽。但如果某些字段需要富文本在渲染時(shí)必須使用|safe過(guò)濾器并確保輸入時(shí)已經(jīng)過(guò)清洗如使用bleach庫(kù)。SQL注入堅(jiān)持使用Django ORM或參數(shù)化查詢基本可以免疫。敏感信息密碼必須使用make_password哈希存儲(chǔ)絕對(duì)禁止明文。數(shù)據(jù)庫(kù)連接密碼、第三方API密鑰等必須通過(guò)環(huán)境變量配置。文件上傳限制上傳文件的類型通過(guò)MIME類型和后綴名雙重校驗(yàn)、大小并對(duì)圖片進(jìn)行重命名如使用UUID防止用戶上傳惡意文件或通過(guò)路徑遍歷攻擊服務(wù)器。權(quán)限控制除了前端的登錄檢查后端每個(gè)視圖函數(shù)都要進(jìn)行權(quán)限校驗(yàn)。使用login_required、permission_required裝飾器或自定義裝飾器檢查用戶角色。5.4 常見(jiàn)問(wèn)題與排查技巧實(shí)錄在開(kāi)發(fā)和維護(hù)這個(gè)項(xiàng)目的過(guò)程中我踩過(guò)不少坑也總結(jié)了一些排查問(wèn)題的經(jīng)驗(yàn)。問(wèn)題一靜態(tài)文件在開(kāi)發(fā)環(huán)境正常部署后404。排查首先檢查settings.py中的STATIC_URL和STATIC_ROOT配置。STATIC_ROOT是執(zhí)行collectstatic后文件收集的目錄需要確保Nginx或Apache的配置正確指向了這個(gè)目錄或者STATICFILES_DIRS配置正確。使用python manage.py findstatic css/style.css命令可以查找Django認(rèn)為的靜態(tài)文件路徑。解決對(duì)于使用Nginx的情況在配置文件中添加一個(gè)location塊location /static/ { alias /path/to/your/static_root/; }。確保Nginx用戶對(duì)該目錄有讀取權(quán)限。問(wèn)題二使用F()表達(dá)式更新后從數(shù)據(jù)庫(kù)重新取出的值好像沒(méi)變排查這是一個(gè)常見(jiàn)的誤解。F()表達(dá)式更新是在數(shù)據(jù)庫(kù)層面進(jìn)行的原子操作但更新后當(dāng)前Python內(nèi)存中的模型實(shí)例對(duì)象obj的字段值并不會(huì)自動(dòng)刷新。解決如果需要獲取更新后的值必須從數(shù)據(jù)庫(kù)重新加載該對(duì)象obj.refresh_from_db()。問(wèn)題三支付回調(diào)接口被重復(fù)調(diào)用導(dǎo)致訂單狀態(tài)異常更新。排查檢查支付回調(diào)接口的日志看是否收到了多條內(nèi)容相同的POST請(qǐng)求。這通常是支付平臺(tái)的網(wǎng)絡(luò)重試機(jī)制導(dǎo)致的。解決實(shí)現(xiàn)接口的冪等性。在回調(diào)處理邏輯的最開(kāi)始根據(jù)支付平臺(tái)傳過(guò)來(lái)的唯一交易號(hào)如支付寶的trade_no去查詢本地是否已存在處理成功的記錄。如果已存在直接返回成功響應(yīng)不再執(zhí)行后續(xù)的訂單更新邏輯。可以在數(shù)據(jù)庫(kù)中為這個(gè)交易號(hào)建立唯一索引從數(shù)據(jù)庫(kù)層面防止重復(fù)記錄。問(wèn)題四后臺(tái)Admin操作速度很慢特別是有關(guān)聯(lián)數(shù)據(jù)的列表頁(yè)。排查使用django-debug-toolbar查看該Admin頁(yè)面生成的SQL很可能是因?yàn)樵诹斜眄?yè)顯示外鍵字段如list_display [spu]時(shí)每條記錄都去單獨(dú)查詢了一次關(guān)聯(lián)表。解決在自定義的ModelAdmin中重寫get_queryset方法使用select_related提前加載關(guān)聯(lián)數(shù)據(jù)def get_queryset(self, request): return super().get_queryset(request).select_related(spu, category)。這個(gè)Django商城項(xiàng)目源碼就像一本涵蓋了需求分析、設(shè)計(jì)、編碼、調(diào)試和部署思考的實(shí)戰(zhàn)筆記。它可能沒(méi)有用到最前沿的微服務(wù)或云原生架構(gòu)但其中對(duì)業(yè)務(wù)邏輯的梳理、對(duì)數(shù)據(jù)一致性的處理、對(duì)常見(jiàn)問(wèn)題的規(guī)避方案都是構(gòu)建一個(gè)可靠Web應(yīng)用的通用經(jīng)驗(yàn)。代碼是死的但解決問(wèn)題的思路是活的。希望你在閱讀和運(yùn)行這份代碼時(shí)能更關(guān)注“為什么這么設(shè)計(jì)”而不僅僅是“怎么實(shí)現(xiàn)”。當(dāng)你理解了背后的權(quán)衡與考量也就具備了獨(dú)立設(shè)計(jì)和開(kāi)發(fā)更復(fù)雜系統(tǒng)的能力。本文還有配套的精品資源點(diǎn)擊獲取