崙?zhàn)：從后端設(shè)計(jì)到前端聯(lián)調(diào))
如果你正打算做一個(gè)電商類(lèi)的購(gòu)物小程序又不想把前后端拆得太開(kāi)、來(lái)回折騰那 Python Flask uni-app 這套組合我實(shí)測(cè)下來(lái)很適合。我最近完整做了一個(gè)商城購(gòu)物平臺(tái)的電商小程序從數(shù)據(jù)庫(kù)設(shè)計(jì)、后端接口到前端頁(yè)面全部自己寫(xiě)。標(biāo)題里那幾個(gè)關(guān)鍵詞——flask、uniapp、vue、pycharm、django其實(shí)是我當(dāng)初做技術(shù)選型時(shí)反復(fù)對(duì)比過(guò)的內(nèi)容。這篇文章把整個(gè)設(shè)計(jì)和實(shí)現(xiàn)過(guò)程拆開(kāi)講包括為什么最后選了 Flask在 PyCharm 里怎么搭環(huán)境uni-app 里的 Vue 語(yǔ)法怎么和小程序頁(yè)面綁定以及聯(lián)調(diào)上線后踩到的各種坑。這項(xiàng)目不是玩具 Demo而是能跑完“登錄-逛商品-加購(gòu)物車(chē)-下單-模擬支付-訂單查詢(xún)”完整閉環(huán)的真實(shí)產(chǎn)物適合正在寫(xiě)畢業(yè)設(shè)計(jì)、個(gè)人作品集或者第一款獨(dú)立小程序的人參考。1. 項(xiàng)目整體設(shè)計(jì)與技術(shù)選型1.1 為什么選了 Flask 而不是 Django這個(gè)項(xiàng)目的標(biāo)題里同時(shí)出現(xiàn)了 flask 和 django說(shuō)明很多人跟我一樣在選擇 Python 后端框架時(shí)糾結(jié)過(guò)。Django 確實(shí)自帶 Admin 后臺(tái)、ORM、遷移工具看起來(lái)“開(kāi)箱即用”但對(duì)于一個(gè)電商小程序后端來(lái)說(shuō)它的問(wèn)題也很明顯太重了。Django 的項(xiàng)目結(jié)構(gòu)默認(rèn)幫你分好了 app你還沒(méi)寫(xiě)業(yè)務(wù)代碼就要先理解 settings、urls、models、admin、middleware 這些概念。而 Flask 只做一件事用路由接收請(qǐng)求返回 JSON。剩下的數(shù)據(jù)庫(kù)、登錄鑒權(quán)、參數(shù)校驗(yàn)全部可以通過(guò)第三方擴(kuò)展按需組合。商城購(gòu)物平臺(tái)的核心是 API不是后臺(tái)管理頁(yè)面。小程序端不需要后端渲染 HTML只需要后端穩(wěn)定地吐出 JSON。Flask 配合 Flask-SQLAlchemy、Flask-JWT-Extended、Flask-CORS 這幾個(gè)庫(kù)已經(jīng)能覆蓋項(xiàng)目 95% 的需求。開(kāi)發(fā)時(shí)用 PyCharm 建一個(gè)虛擬環(huán)境裝依賴(lài)、啟動(dòng)服務(wù)、打斷點(diǎn)調(diào)試整個(gè)流程非常輕量。如果用 Django前期要處理的東西至少多一倍而實(shí)際用到的那部分核心能力Flask 完全夠用。我并不是說(shuō) Django 不好而是“項(xiàng)目適合什么”更重要。如果你要做一個(gè)大型內(nèi)容管理系統(tǒng)后臺(tái)功能復(fù)雜那 Django 是更好的選擇但如果目標(biāo)明確是給小程序提供 APIFlask 的學(xué)習(xí)成本和交付速度都有明顯優(yōu)勢(shì)。我在這套項(xiàng)目里用 Flask 寫(xiě)了接近四十個(gè)接口從用戶(hù)登錄、商品列表到訂單提交代碼結(jié)構(gòu)依然很清爽。如果你的項(xiàng)目也需要快速迭代Flask 更合適。1.2 uni-app 和 Vue 的關(guān)系以及為什么能一套代碼出小程序uni-app 本身是基于 Vue 語(yǔ)法的跨端框架項(xiàng)目里寫(xiě)的export default { data() { return {} }, methods: {} }和 Vue 單文件組件的寫(xiě)法幾乎一致。所以標(biāo)題里出現(xiàn)“vue”并不奇怪因?yàn)樵谛〕绦蚨藢?xiě) uni-app本質(zhì)上就是在用 Vue 的語(yǔ)法組織頁(yè)面邏輯。唯一不同的是模板部分uni-app 把 Vue 的div換成了小程序和 App 都能識(shí)別的內(nèi)置組件比如view、text、image、scroll-view數(shù)據(jù)綁定仍然用的是{{ }}和v-for。選擇 uni-app 的主要原因是可以只寫(xiě)一套代碼同時(shí)發(fā)布到微信小程序、支付寶小程序、H5 甚至原生 App。電商項(xiàng)目最怕的是單獨(dú)維護(hù)一個(gè)小程序端再維護(hù)一個(gè) H5 端如果你還想要 App工作量直接翻三倍。uni-app 把這一層跨端差異封裝掉了普通頁(yè)面的開(kāi)發(fā)體驗(yàn)和寫(xiě) Vue 幾乎一致。對(duì)于我這種以技術(shù)實(shí)現(xiàn)為主的人來(lái)說(shuō)不需要去記小程序原生那套繁瑣的setData規(guī)則開(kāi)發(fā)效率提高很多。而且在 PyCharm 里做后端再用 HBuilderX 或 VS Code 寫(xiě) uni-app正好符合標(biāo)題里“pycharm”這個(gè)關(guān)鍵詞的使用場(chǎng)景PyCharm 管 Python 后端前端編輯器管 Vue 文件。兩個(gè)窗口并行調(diào)試后端斷點(diǎn)打進(jìn)去看請(qǐng)求數(shù)據(jù)前端控制臺(tái)看渲染結(jié)果排查問(wèn)題非常直觀。2. 商城核心需求拆解與數(shù)據(jù)庫(kù)設(shè)計(jì)2.1 四大核心模塊的數(shù)據(jù)表結(jié)構(gòu)電商小程序看著功能多拆開(kāi)以后核心就是用戶(hù)、商品、購(gòu)物車(chē)、訂單四大模塊。我設(shè)計(jì)表結(jié)構(gòu)時(shí)沒(méi)有過(guò)度設(shè)計(jì)能拆的表拆掉能省的字段省掉。用戶(hù)表存id、openid、nickname、avatar、phone其中openid是登錄憑證用唯一索引防止重復(fù)綁定。商品表存id、title、subtitle、cover_url、price、stock、category_id、status、sales價(jià)格字段用Numeric(10, 2)絕對(duì)不用浮點(diǎn)數(shù)不然算金額會(huì)出現(xiàn)小數(shù)點(diǎn)后面莫名其妙的誤差。分類(lèi)表就兩個(gè)字段id和name再加一個(gè)sort控制排序。購(gòu)物車(chē)表比較關(guān)鍵它關(guān)聯(lián)的是用戶(hù)和商品user_id、goods_id、quantity、selected另外加了一個(gè)唯一約束(user_id, goods_id)保證同一個(gè)用戶(hù)同一件商品只會(huì)有一行記錄再次加入購(gòu)物車(chē)就做數(shù)量累加。訂單表字段最多order_no、user_id、total_amount、status、address_snapshot、create_time、pay_time。訂單項(xiàng)表則存每個(gè)訂單里的商品快照order_id、goods_id、title、cover_url、price、quantity。這里要特別強(qiáng)調(diào)訂單項(xiàng)必須做“快照”。用戶(hù)下單之后商品標(biāo)題和價(jià)格可能會(huì)被后臺(tái)修改如果訂單詳情直接去關(guān)聯(lián)商品表那用戶(hù)看到的過(guò)去訂單信息就會(huì)變。把標(biāo)題、圖片、單價(jià)原樣復(fù)制到訂單項(xiàng)表里才是電商系統(tǒng)該有的做法。地址也一樣用戶(hù)地址可以隨便改但每筆訂單要保留下單那一刻的地址完整字段不然售后對(duì)賬會(huì)非常麻煩。2.2 用戶(hù)登錄與 JWT 無(wú)狀態(tài)鑒權(quán)小程序端的登錄不能直接用賬號(hào)密碼因?yàn)橛脩?hù)打開(kāi)小程序后要的是“一鍵登錄”。我的方案是前端調(diào)用小程序提供的uni.login獲取臨時(shí) code把 code 傳給后端后端拿著 code 去交換 openid然后創(chuàng)建或更新用戶(hù)記錄最后簽發(fā)一個(gè) JWT token 返回給前端。這個(gè)流程聽(tīng)起來(lái)繞但它是小程序生態(tài)的標(biāo)準(zhǔn)做法核心目的就是讓服務(wù)端拿到的不是用戶(hù)自己填的密碼而是平臺(tái)校驗(yàn)過(guò)的身份憑證。JWT 的好處是不用存儲(chǔ) session服務(wù)端不需要維護(hù)一張會(huì)話表。flask-jwt-extended生成 token 后前端把它存在uni.setStorageSync里之后每次請(qǐng)求在 header 中帶上Authorization: Bearer token后端通過(guò)jwt_required()裝飾器就能拿到當(dāng)前用戶(hù) ID。比如購(gòu)物車(chē)、訂單這些接口都依賴(lài)用戶(hù)身份我只需要在函數(shù)里寫(xiě)get_jwt_identity()就能獲取user_id干凈利落。使用 JWT 也有一個(gè)必須注意的點(diǎn)token 一旦簽發(fā)在有效期內(nèi)是吊銷(xiāo)不了的。所以我把有效期設(shè)置成了 7 天同時(shí)在用戶(hù)表中維護(hù)了一個(gè)token_version字段當(dāng)用戶(hù)修改密碼或者被管理員禁用時(shí)token_version加一重新簽發(fā)的 token 里包含新的版本號(hào)后端在每次請(qǐng)求時(shí)比較版本號(hào)是否一致不通過(guò)就直接返回 401。這種方法既保留 JWT 無(wú)狀態(tài)的優(yōu)勢(shì)又解決了“用戶(hù)被踢下線”的實(shí)際需求。3. Flask 后端 API 的實(shí)現(xiàn)細(xì)節(jié)3.1 項(xiàng)目目錄結(jié)構(gòu)與藍(lán)圖劃分很多新手寫(xiě) Flask 喜歡把所有路由寫(xiě)在一個(gè)app.py里接口少的時(shí)候還行電商這種規(guī)模的項(xiàng)目一上去文件就失控了。我實(shí)際用的是包結(jié)構(gòu)把不同模塊用藍(lán)圖Blueprint拆開(kāi)。項(xiàng)目目錄長(zhǎng)這樣shop_api/ ├── app.py # 入口文件注冊(cè)所有藍(lán)圖 ├── config.py # 配置項(xiàng) ├── extensions.py # 擴(kuò)展對(duì)象初始化 ├── models/ │ ├── __init__.py │ ├── user.py │ ├── goods.py │ ├── cart.py │ └── order.py ├── apis/ │ ├── __init__.py │ ├── auth.py # 登錄相關(guān) │ ├── goods.py # 商品、分類(lèi) │ ├── cart.py # 購(gòu)物車(chē) │ └── order.py # 訂單、支付模擬 ├── utils/ │ ├── response.py # 統(tǒng)一返回格式 │ └── decorators.py # 自定義裝飾器 └── requirements.txt入口文件只負(fù)責(zé)創(chuàng)建app、加載配置、初始化擴(kuò)展、注冊(cè)藍(lán)圖。藍(lán)圖里每個(gè)模塊的 URL 前綴都獨(dú)立比如購(gòu)物車(chē)藍(lán)圖統(tǒng)一掛在/api/cart下面接口路徑就自然形成了/api/cart/list、/api/cart/add。這樣后期加模塊不會(huì)相互影響團(tuán)隊(duì)協(xié)作時(shí)各寫(xiě)各的藍(lán)圖文件沖突也少。統(tǒng)一響應(yīng)格式也很有必要。我用的結(jié)構(gòu)是{code: 0, message: success, data: {}}。成功時(shí) code 為 0失敗時(shí) code 為具體錯(cuò)誤碼比如 1001 表示 token 失效1002 表示商品庫(kù)存不足。前端封裝了請(qǐng)求攔截器后只需要判斷 code 是不是 0不用去解析 HTTP 狀態(tài)碼和自定義 message 的混合體異常提示也能直接透?jìng)鹘o用戶(hù)。3.2 商品列表、搜索與詳情接口設(shè)計(jì)商品列表接口不要一上來(lái)就把所有字段都返回用戶(hù)在小程序端只需要卡片所需的標(biāo)題、圖片、價(jià)格、銷(xiāo)量。所以我用 Flask-SQLAlchemy 的查詢(xún)按分類(lèi)、關(guān)鍵詞、銷(xiāo)量、價(jià)格排序輸出的時(shí)候手工構(gòu)造字典而不是直接序列化模型對(duì)象。這樣能避免把stock、status這些內(nèi)部字段也暴露給前端減少安全性問(wèn)題。商品搜索我用的是LIKE模糊匹配。電商小程序的并發(fā)量不會(huì)太大這個(gè)方案是夠用的。如果以后數(shù)據(jù)量大了再上全文檢索引擎也不遲。接口設(shè)計(jì)上支持page和size參數(shù)返回total、items、has_more小程序端滾動(dòng)到底部加載下一頁(yè)用戶(hù)體驗(yàn)會(huì)好很多。商品詳情接口需要注意瀏覽數(shù)和銷(xiāo)量展示。我在商品表里設(shè)計(jì)了sales字段只有訂單支付成功后才累加。商品詳情頁(yè)的瀏覽量我選擇不加字段記錄因?yàn)轭l繁更新瀏覽量會(huì)拖垮數(shù)據(jù)庫(kù)。如果后續(xù)真的需要我會(huì)用緩存做異步累加而不是每次訪問(wèn)都去 UPDATE 一次。3.3 下單與庫(kù)存扣減事務(wù)和條件更新的正確姿勢(shì)下單是整個(gè)系統(tǒng)最核心、最容易出錯(cuò)的環(huán)節(jié)。我的實(shí)現(xiàn)嚴(yán)格按下面幾步執(zhí)行校驗(yàn)商品是否存在、是否上架。根據(jù)購(gòu)物車(chē)?yán)锏墓催x商品計(jì)算出訂單總金額。按商品維度依次扣減庫(kù)存?？蹨p成功則創(chuàng)建訂單和訂單項(xiàng)扣減失敗則整體回滾。清空對(duì)應(yīng)購(gòu)物車(chē)記錄返回訂單號(hào)。扣庫(kù)存不能先查 stock判斷大于等于購(gòu)買(mǎi)數(shù)量后再 UPDATE因?yàn)椴l(fā)請(qǐng)求下兩個(gè)用戶(hù)可能同時(shí)查到庫(kù)存為 1然后同時(shí)通過(guò)判斷最終把庫(kù)存扣成負(fù)數(shù)。我用的是一個(gè)帶條件的 UPDATE在數(shù)據(jù)庫(kù)層面保證原子性result db.session.execute( db.update(Goods) .where(Goods.id goods_id, Goods.stock quantity) .values(stockGoods.stock - quantity) ) if result.rowcount 0: raise StockNotEnough(goods_id)rowcount如果等于 0說(shuō)明要么商品不存在要么庫(kù)存不足這里直接拋出異常再由外層的事務(wù)裝飾器回滾。把關(guān)鍵判斷交給數(shù)據(jù)庫(kù)而不是 Python 進(jìn)程這是防止超賣(mài)的基本原則。同時(shí)我還要說(shuō)明下單不一定會(huì)支付所以下單時(shí)扣減的是“可售庫(kù)存”支付后如果超時(shí)未支付需要定時(shí)任務(wù)把庫(kù)存加回去。這個(gè)項(xiàng)目里我用了一個(gè)簡(jiǎn)單的定時(shí)清理邏輯每隔一段時(shí)間把超過(guò) 30 分鐘未支付且未取消的訂單取消并回補(bǔ)庫(kù)存。整個(gè)下單流程用db.session.commit()一次性提交任何一步異常都調(diào)用db.session.rollback()。我建議在開(kāi)發(fā)時(shí)寫(xiě)一個(gè)測(cè)試腳本開(kāi) 20 個(gè)線程同時(shí)搶購(gòu)最后一件商品跑完庫(kù)存剛好為 0且只有 1 筆訂單創(chuàng)建成功這是驗(yàn)證并發(fā)安全最直接的方式。4. uni-app 前端開(kāi)發(fā)實(shí)戰(zhàn)4.1 初始化工程與 pages 目錄規(guī)劃用 HBuilderX 創(chuàng)建 uni-app 項(xiàng)目時(shí)我習(xí)慣選擇“默認(rèn)模板”然后手動(dòng)刪除多余的東西。項(xiàng)目結(jié)構(gòu)里最重要的就是pages.json和pages目錄。pages.json負(fù)責(zé)注冊(cè)頁(yè)面路徑、設(shè)置 tabBar 和窗口樣式。因?yàn)槭巧坛琴?gòu)物平臺(tái)我設(shè)了四個(gè)底部 tab首頁(yè)、分類(lèi)、購(gòu)物車(chē)、我的對(duì)應(yīng)四個(gè)頁(yè)面目錄。其余頁(yè)面按照業(yè)務(wù)模塊拆pages/ ├── index/ # 首頁(yè) ├── category/ # 分類(lèi)頁(yè) ├── goods/ # 商品詳情 ├── cart/ # 購(gòu)物車(chē) ├── order/ # 訂單列表、確認(rèn)訂單 ├── pay/ # 模擬支付 └── user/ # 個(gè)人中心、登錄這樣規(guī)劃的好處是頁(yè)面路由和目錄一一對(duì)應(yīng)找文件時(shí)不需要猜。uni-app 的項(xiàng)目里每個(gè)頁(yè)面就是一組.vue文件我在pages.json中給每個(gè)頁(yè)面配置了navigationBarTitleText確保小程序頂部標(biāo)題不會(huì)被默認(rèn)值占位。我習(xí)慣把公共樣式放到uni.scss比如主題色、價(jià)格顏色、邊框變量。小程序里不能直接用var()做主題切換提前把顏色變量統(tǒng)一起來(lái)后面改主色調(diào)就不用全項(xiàng)目搜索替換了。這個(gè)習(xí)慣幫我在老板突然說(shuō)“換個(gè)品牌色”時(shí)省了不少時(shí)間。4.2 封裝請(qǐng)求工具與 token 注入小程序不像瀏覽器沒(méi)有 axios但uni.request已經(jīng)是一個(gè)封裝好的 API。我在此基礎(chǔ)上再包了一層request.js統(tǒng)一處理 baseURL、超時(shí)、token 注入、錯(cuò)誤提示。核心代碼如下const BASE_URL http://localhost:5000/api export function request(options) { return new Promise((resolve, reject) { uni.request({ url: BASE_URL options.url, method: options.method || GET, data: options.data || {}, header: { Content-Type: application/json, Authorization: Bearer uni.getStorageSync(token) }, success(res) { if (res.data.code 0) { resolve(res.data.data) } else { uni.showToast({ title: res.data.message, icon: none }) reject(res.data) } }, fail(err) { uni.showToast({ title: 網(wǎng)絡(luò)異常, icon: none }) reject(err) } }) }) }這里有個(gè)問(wèn)題容易踩開(kāi)發(fā)階段后端跑在 PyCharm 的本地 Flask 服務(wù)上瀏覽器調(diào)試 H5 端可以但真機(jī)預(yù)覽小程序時(shí)localhost指向的是手機(jī)自己根本訪問(wèn)不到電腦上的服務(wù)。我的辦法是開(kāi)發(fā)時(shí)使用電腦的局域網(wǎng) IP比如http://192.168.1.100:5000/api。同時(shí)在小程序開(kāi)發(fā)者工具中勾選“不校驗(yàn)合法域名”等到上線前再改寫(xiě)成正式的 HTTPS 域名。token 失效的處理也很重要。當(dāng)接口返回 code 為 1001 時(shí)request.js需要清掉本地 token然后跳轉(zhuǎn)到登錄頁(yè)面。我一開(kāi)始沒(méi)寫(xiě)這個(gè)邏輯結(jié)果 token 過(guò)期后用戶(hù)一直停留在失敗頁(yè)面體驗(yàn)特別差。加上這個(gè)處理之后用戶(hù)只要重新走一次登錄流程就能繼續(xù)使用。4.3 首頁(yè)、商品詳情與購(gòu)物車(chē)的聯(lián)動(dòng)首頁(yè)我用了搜索框、分類(lèi)側(cè)邊欄、商品卡片流結(jié)合的方式。頂部搜索關(guān)鍵詞變化時(shí)調(diào)用商品搜索接口分類(lèi)切換時(shí)重新請(qǐng)求當(dāng)前分類(lèi)的商品列表。為了減少請(qǐng)求次數(shù)我用的是觸底分頁(yè)加載每次加載 10 條滾動(dòng)到底部觸發(fā)下一頁(yè)。商品詳情頁(yè)的關(guān)鍵是“立即購(gòu)買(mǎi)”和“加入購(gòu)物車(chē)”兩個(gè)操作。點(diǎn)擊加入購(gòu)物車(chē)時(shí)前端只做兩件事把商品 ID 和數(shù)量傳給后端購(gòu)物車(chē)接口如果成功就彈出一個(gè)小 toast并且更新底部 tabBar 的購(gòu)物車(chē)角標(biāo)。角標(biāo)數(shù)量邏輯我通過(guò)uni.$emit(cartUpdated)全局通知其他頁(yè)面監(jiān)聽(tīng)這個(gè)事件后重新獲取購(gòu)物車(chē)數(shù)量避免出現(xiàn)加購(gòu)成功后首頁(yè)角標(biāo)還是舊的這種尷尬。購(gòu)物車(chē)頁(yè)交互是最繁瑣的。每行有一個(gè)復(fù)選框控制選中狀態(tài)底部欄顯示已選商品總價(jià)和結(jié)算按鈕。我維護(hù)一個(gè)selectedMap對(duì)象來(lái)記錄每件商品的選中狀態(tài)選中變化時(shí)重新計(jì)算總價(jià)。后端也支持批量刪除和修改數(shù)量所有操作都返回最新的列表和總價(jià)前端直接用返回?cái)?shù)據(jù)刷新視圖不自己做本地計(jì)算。這樣可以避免本地?cái)?shù)據(jù)和后端不一致的問(wèn)題。下單入口我做了區(qū)分從購(gòu)物車(chē)結(jié)算提交的是購(gòu)物車(chē)選中的商品從詳情頁(yè)立即購(gòu)買(mǎi)提交的是單件商品。所以確認(rèn)訂單頁(yè)需要接受兩種來(lái)源我統(tǒng)一在頁(yè)面參數(shù)中帶上from字段值為cart或buy。后端下單接口也接收這個(gè)來(lái)源如果是buy就直接用請(qǐng)求里的商品列表如果是cart就去讀取購(gòu)物車(chē)選中項(xiàng)。這個(gè)設(shè)計(jì)看起來(lái)簡(jiǎn)單但能把兩個(gè)業(yè)務(wù)場(chǎng)景統(tǒng)一成一套接口不用復(fù)制代碼。5. PyCharm 開(kāi)發(fā)環(huán)境與前后端聯(lián)調(diào)5.1 用 PyCharm 管理 Flask 虛擬環(huán)境與依賴(lài)導(dǎo)出在 PyCharm 中新建 Flask 項(xiàng)目時(shí)我建議先創(chuàng)建一個(gè)獨(dú)立的虛擬環(huán)境不要用系統(tǒng) Python 的全局解釋器。因?yàn)椴煌?xiàng)目依賴(lài)版本經(jīng)常沖突尤其是 Flask 和 SQLAlchemy 的版本組合全局安裝容易出現(xiàn)“A 項(xiàng)目能跑B 項(xiàng)目跑不起來(lái)”的情況。PyCharm 在File - Settings - Project - Python Interpreter里可以選擇虛擬環(huán)境路徑創(chuàng)建后左下角會(huì)顯示當(dāng)前使用的解釋器。依賴(lài)管理我推薦兩條命令pip install flask flask-sqlalchemy flask-jwt-extended flask-cors pymysql pip freeze requirements.txtfreeze出來(lái)的文件在上服務(wù)器時(shí)直接執(zhí)行pip install -r requirements.txt就能復(fù)現(xiàn)環(huán)境。不過(guò)我習(xí)慣再手動(dòng)檢查一遍requirements.txt把那些和項(xiàng)目無(wú)關(guān)的傳遞依賴(lài)清理掉保證環(huán)境干凈。PyCharm 里調(diào)試 Flask 非常順手。給入口文件app.py配置一個(gè) Run Configuration設(shè)置環(huán)境變量FLASK_ENVdevelopment啟動(dòng)后接口地址是http://127.0.0.1:5000。在視圖函數(shù)里打上斷點(diǎn)再用小程序的模擬器去請(qǐng)求接口請(qǐng)求會(huì)在斷點(diǎn)處停住你可以看到 Flask 接收到的 JSON 數(shù)據(jù)和數(shù)據(jù)庫(kù)查詢(xún)結(jié)果。這種調(diào)試方式比靠print猜來(lái)猜去高效得多。5.2 前端聯(lián)調(diào)域名白名單、真機(jī)調(diào)試與跨域聯(lián)調(diào)過(guò)程中最頭疼的問(wèn)題不是代碼邏輯而是網(wǎng)絡(luò)環(huán)境。小程序生產(chǎn)環(huán)境要求所有請(qǐng)求域名必須是 HTTPS并且在后臺(tái)配置白名單。開(kāi)發(fā)階段自然沒(méi)這個(gè)條件解決方法是在微信開(kāi)發(fā)者工具的“詳情-本地設(shè)置”中勾選“不校驗(yàn)合法域名、web-view業(yè)務(wù)域名、TLS 版本以及 HTTPS 證書(shū)”。這樣就能用本地 Flask 的 HTTP 服務(wù)調(diào)試。但注意這個(gè)設(shè)置只對(duì)開(kāi)發(fā)者工具生效真機(jī)預(yù)覽時(shí)還是要用局域網(wǎng) IP并且手機(jī)和電腦處于同一個(gè) WiFi 下。如果你用 HBuilderX 運(yùn)行到微信開(kāi)發(fā)者工具HBuilderX 會(huì)生成一個(gè)臨時(shí)小程序項(xiàng)目路徑。這里有一個(gè)容易忽略的地方每次修改代碼后要在 HBuilderX 里重新運(yùn)行或點(diǎn)擊刷新開(kāi)發(fā)者工具才能拿到最新代碼。我一開(kāi)始改了.vue文件發(fā)現(xiàn)小程序沒(méi)變化還以為沒(méi)保存成功后來(lái)才發(fā)現(xiàn)是 HBuilderX 沒(méi)有重新編譯到微信開(kāi)發(fā)者工具目錄。跨域問(wèn)題主要出現(xiàn)在 H5 端。瀏覽器里uni.request請(qǐng)求 Flask 時(shí)Fe服務(wù)器和前端不是同一個(gè)源瀏覽器會(huì)攔截響應(yīng)。解決辦法是在 Flask 中啟用 CORS我使用flask-corsfrom flask_cors import CORS CORS(app, resources{r/api/*: {origins: *}})加了這一行后H5 端的聯(lián)調(diào)就正常了。小程序端本身不存在瀏覽器跨域限制所以不需要關(guān)心 CORS但也因此更需要注意請(qǐng)求異常時(shí)的錯(cuò)誤處理因?yàn)樾〕绦虻腻e(cuò)誤提示不像瀏覽器控制臺(tái)那么詳細(xì)。6. 部署上線與常見(jiàn)問(wèn)題排查6.1 服務(wù)器部署 Flask 的注意點(diǎn)本地開(kāi)發(fā)用 Flask 自帶服務(wù)器上線可不能繼續(xù)用它。我用的是 Gunicorn 作為 WSGI 服務(wù)Ubuntu 服務(wù)器上配合 Nginx 反向代理。啟動(dòng)命令大概是gunicorn -w 4 -b 0.0.0.0:8000 app:app-w 4表示 4 個(gè) worker 進(jìn)程。在 PyCharm 中寫(xiě)的入口app:app前一個(gè)是文件名后一個(gè)是被創(chuàng)建的Flask實(shí)例變量名。Gunicorn 不能跑在 Windows所以部署時(shí)切到 Linux 環(huán)境。如果你用的是 Windows 服務(wù)器可以考慮 Waitress但我個(gè)人還是推薦 Linux 加 Nginx。Nginx 做的事情有兩件一是把 80/443 端口的請(qǐng)求轉(zhuǎn)發(fā)給 Gunicorn 的 8000 端口二是有需要時(shí)直接托管靜態(tài)資源。在小程序場(chǎng)景中圖片和商品圖我建議單獨(dú)用對(duì)象存儲(chǔ)服務(wù)不放在應(yīng)用服務(wù)器里否則帶寬和存儲(chǔ)都會(huì)成為瓶頸。數(shù)據(jù)庫(kù)我單獨(dú)使用一個(gè)云數(shù)據(jù)庫(kù)實(shí)例不會(huì)和應(yīng)用搶內(nèi)存。部署后一定要檢查數(shù)據(jù)庫(kù)連接池。Flask-SQLAlchemy 默認(rèn)連接池不算大高并發(fā)下容易出現(xiàn)TimeoutError。我設(shè)置SQLALCHEMY_POOL_PRE_PINGTrue可以讓連接失效時(shí)自動(dòng)重連這個(gè)參數(shù)解決了我曾經(jīng)在長(zhǎng)時(shí)間運(yùn)行后接口假死的問(wèn)題。6.2 高頻報(bào)錯(cuò)排查實(shí)錄我在整個(gè)開(kāi)發(fā)過(guò)程中整理了下面幾個(gè)高頻報(bào)錯(cuò)它們幾乎每個(gè)都是新手必踩的坑。第一個(gè)是“數(shù)據(jù)庫(kù)時(shí)間比本地時(shí)間少 8 小時(shí)”。Flask 里的datetime.now()默認(rèn)讀取服務(wù)器時(shí)區(qū)如果服務(wù)器是 UTC后端返回的create_time就是 UTC 時(shí)間。前端直接把時(shí)間字符串展示出來(lái)就會(huì)出現(xiàn)訂單時(shí)間比用戶(hù)看到的時(shí)間少 8 小時(shí)。我的解決辦法是在后端統(tǒng)一使用本地時(shí)區(qū)比如在config.py中設(shè)置TIMEZONE Asia/Shanghai并且在返回時(shí)間字段前統(tǒng)一做時(shí)區(qū)轉(zhuǎn)換讓前端拿到的直接就是東八區(qū)的時(shí)間字符串不做二次轉(zhuǎn)換。第二個(gè)是“JSON 序列化 Decimal 失敗”。價(jià)格字段是NumericFlask 的默認(rèn) JSON encoder 不認(rèn)識(shí)Decimal對(duì)象直接用jsonify返回會(huì)報(bào)TypeError。我的解決方法是寫(xiě)一個(gè)自定義 JSON Encoder把Decimal轉(zhuǎn)換成字符串確保精度不丟失。前端計(jì)算金額時(shí)也不要用浮點(diǎn)數(shù)我是在后端返回字符串后由前端通過(guò)parseInt和parseFloat在顯示層處理核心金額計(jì)算始終交給后端。from flask.json import JSONEncoder from decimal import Decimal class CustomJSONEncoder(JSONEncoder): def default(self, obj): if isinstance(obj, Decimal): return str(obj) return super().default(obj) app.json_encoder CustomJSONEncoder第三個(gè)是“前端加了購(gòu)物車(chē)但角標(biāo)不更新”。原因是最先寫(xiě)的代碼只是在加購(gòu)成功后uni.showToast沒(méi)有通知其他頁(yè)面刷新。后來(lái)我引入了uni.$emit(cartUpdated)在首頁(yè)和購(gòu)物車(chē)頁(yè)用uni.$on(cartUpdated, function() { ... })接收事件問(wèn)題就解決了。不過(guò)要注意頁(yè)面卸載時(shí)要用uni.$off解綁事件否則會(huì)重復(fù)監(jiān)聽(tīng)導(dǎo)致多次請(qǐng)求。第四個(gè)是“并發(fā)下單導(dǎo)致庫(kù)存扣成負(fù)數(shù)”。我一開(kāi)始用的是先查詢(xún)?cè)俑潞髞?lái)改成條件 UPDATE 后問(wèn)題徹底消失。這里再?gòu)?qiáng)調(diào)一遍高性能場(chǎng)景下的并發(fā)安全不能靠 Python 代碼判斷要充分利用數(shù)據(jù)庫(kù)的行鎖和原子操作。6.3 上線前的安全自檢清單電商項(xiàng)目只要上線就涉及資金和用戶(hù)數(shù)據(jù)安全。我給自己列了幾條鐵律你可以直接抄走。第一小程序前端絕對(duì)不能放密鑰。任何 AppSecret、支付秘鑰、數(shù)據(jù)庫(kù)連接串都只能保存在后端環(huán)境變量里。小程序代碼可以被反編譯只要前端出現(xiàn)明文密鑰基本等于把后臺(tái)拱手送人。第二Flask 必須關(guān)閉debug。我在config.py里區(qū)分生產(chǎn)環(huán)境和開(kāi)發(fā)環(huán)境生產(chǎn)環(huán)境下DEBUGFalse同時(shí)設(shè)置SECRET_KEY為環(huán)境變量讀取的值不寫(xiě)死在代碼里。第三所有涉及金額的接口后端必須重新算價(jià)。前端傳過(guò)來(lái)的商品 ID 和數(shù)量可以信但價(jià)格不能信。下單接口要從數(shù)據(jù)庫(kù)讀取當(dāng)前商品價(jià)格乘以數(shù)量得到總金額然后再創(chuàng)建訂單。如果拿前端傳過(guò)來(lái)的價(jià)格直接入庫(kù)用戶(hù)改一下請(qǐng)求里的字段就能用 0.01 元買(mǎi)到商城里的商品。這是最典型也最致命的漏洞。第四用戶(hù)輸入不能直接拼接進(jìn) SQL。Flask-SQLAlchemy 的 ORM 默認(rèn)參數(shù)化查詢(xún)相對(duì)安全但是使用原生 SQL 時(shí)要格外小心。商品搜索里的關(guān)鍵詞參數(shù)一律通過(guò)text()綁定參數(shù)的方式傳值不直接字符串拼接。第五做支付回調(diào)時(shí)一定要驗(yàn)簽。這個(gè)項(xiàng)目雖然只是模擬支付但我也按真實(shí)標(biāo)準(zhǔn)預(yù)留了回調(diào)接口。如果接真實(shí)支付回調(diào)通知里哪怕只有一個(gè)字段對(duì)不上簽名也要直接拒收。任何人只要知道你的回調(diào)地址就能偽造支付成功通知。6.4 做完這個(gè)項(xiàng)目后的幾點(diǎn)經(jīng)驗(yàn)沉淀這是我前后端獨(dú)立完成的第一個(gè)完整電商系統(tǒng)最大的體會(huì)是選型不是越火越好而是越貼合場(chǎng)景越好。Flask 搭配 uni-app讓我用最少的心智負(fù)擔(dān)完成了一個(gè)可以跑通完整閉環(huán)的小程序。另一個(gè)感觸是很多問(wèn)題看起來(lái)是技術(shù)問(wèn)題實(shí)際上是沒(méi)有先想清楚流程。比如庫(kù)存扣減為什么要用條件更新訂單金額為什么必須后端算地址為什么必須做快照這些都不是代碼本身而是業(yè)務(wù)規(guī)則約束下的必然選擇。最后分享一個(gè)小技巧開(kāi)發(fā)時(shí)一定要把后端返回的 JSON 結(jié)構(gòu)固定下來(lái)。我在項(xiàng)目開(kāi)始前先寫(xiě)了一個(gè)接口文檔規(guī)定好 code、message、data 的格式前端和后端完全按這個(gè)文檔并行開(kāi)發(fā)后面聯(lián)調(diào)幾乎沒(méi)有扯皮。如果你也想做類(lèi)似的項(xiàng)目建議把下單、庫(kù)存、支付這三個(gè)環(huán)節(jié)先按最笨的方式實(shí)現(xiàn)跑通后再優(yōu)化千萬(wàn)不要一上來(lái)就追求“分布式”“高并發(fā)”先把單體閉環(huán)做扎實(shí)比什么都強(qiáng)。 Flask + uni-app 電商小程序?qū)崙?zhàn)：從后端設(shè)計(jì)到前端聯(lián)調(diào)
如果你正打算做一個(gè)電商類(lèi)的購(gòu)物小程序又不想把前后端拆得太開(kāi)、來(lái)回折騰那 Python Flask uni-app 這套組合我實(shí)測(cè)下來(lái)很適合。我最近完整做了一個(gè)商城購(gòu)物平臺(tái)的電商小程序從數(shù)據(jù)庫(kù)設(shè)計(jì)、后端接口到前端頁(yè)面全部自己寫(xiě)。標(biāo)題里那幾個(gè)關(guān)鍵詞——flask、uniapp、vue、pycharm、django其實(shí)是我當(dāng)初做技術(shù)選型時(shí)反復(fù)對(duì)比過(guò)的內(nèi)容。這篇文章把整個(gè)設(shè)計(jì)和實(shí)現(xiàn)過(guò)程拆開(kāi)講包括為什么最后選了 Flask在 PyCharm 里怎么搭環(huán)境uni-app 里的 Vue 語(yǔ)法怎么和小程序頁(yè)面綁定以及聯(lián)調(diào)上線后踩到的各種坑。這項(xiàng)目不是玩具 Demo而是能跑完“登錄-逛商品-加購(gòu)物車(chē)-下單-模擬支付-訂單查詢(xún)”完整閉環(huán)的真實(shí)產(chǎn)物適合正在寫(xiě)畢業(yè)設(shè)計(jì)、個(gè)人作品集或者第一款獨(dú)立小程序的人參考。1. 項(xiàng)目整體設(shè)計(jì)與技術(shù)選型1.1 為什么選了 Flask 而不是 Django這個(gè)項(xiàng)目的標(biāo)題里同時(shí)出現(xiàn)了 flask 和 django說(shuō)明很多人跟我一樣在選擇 Python 后端框架時(shí)糾結(jié)過(guò)。Django 確實(shí)自帶 Admin 后臺(tái)、ORM、遷移工具看起來(lái)“開(kāi)箱即用”但對(duì)于一個(gè)電商小程序后端來(lái)說(shuō)它的問(wèn)題也很明顯太重了。Django 的項(xiàng)目結(jié)構(gòu)默認(rèn)幫你分好了 app你還沒(méi)寫(xiě)業(yè)務(wù)代碼就要先理解 settings、urls、models、admin、middleware 這些概念。而 Flask 只做一件事用路由接收請(qǐng)求返回 JSON。剩下的數(shù)據(jù)庫(kù)、登錄鑒權(quán)、參數(shù)校驗(yàn)全部可以通過(guò)第三方擴(kuò)展按需組合。商城購(gòu)物平臺(tái)的核心是 API不是后臺(tái)管理頁(yè)面。小程序端不需要后端渲染 HTML只需要后端穩(wěn)定地吐出 JSON。Flask 配合 Flask-SQLAlchemy、Flask-JWT-Extended、Flask-CORS 這幾個(gè)庫(kù)已經(jīng)能覆蓋項(xiàng)目 95% 的需求。開(kāi)發(fā)時(shí)用 PyCharm 建一個(gè)虛擬環(huán)境裝依賴(lài)、啟動(dòng)服務(wù)、打斷點(diǎn)調(diào)試整個(gè)流程非常輕量。如果用 Django前期要處理的東西至少多一倍而實(shí)際用到的那部分核心能力Flask 完全夠用。我并不是說(shuō) Django 不好而是“項(xiàng)目適合什么”更重要。如果你要做一個(gè)大型內(nèi)容管理系統(tǒng)后臺(tái)功能復(fù)雜那 Django 是更好的選擇但如果目標(biāo)明確是給小程序提供 APIFlask 的學(xué)習(xí)成本和交付速度都有明顯優(yōu)勢(shì)。我在這套項(xiàng)目里用 Flask 寫(xiě)了接近四十個(gè)接口從用戶(hù)登錄、商品列表到訂單提交代碼結(jié)構(gòu)依然很清爽。如果你的項(xiàng)目也需要快速迭代Flask 更合適。1.2 uni-app 和 Vue 的關(guān)系以及為什么能一套代碼出小程序uni-app 本身是基于 Vue 語(yǔ)法的跨端框架項(xiàng)目里寫(xiě)的export default { data() { return {} }, methods: {} }和 Vue 單文件組件的寫(xiě)法幾乎一致。所以標(biāo)題里出現(xiàn)“vue”并不奇怪因?yàn)樵谛〕绦蚨藢?xiě) uni-app本質(zhì)上就是在用 Vue 的語(yǔ)法組織頁(yè)面邏輯。唯一不同的是模板部分uni-app 把 Vue 的div換成了小程序和 App 都能識(shí)別的內(nèi)置組件比如view、text、image、scroll-view數(shù)據(jù)綁定仍然用的是{{ }}和v-for。選擇 uni-app 的主要原因是可以只寫(xiě)一套代碼同時(shí)發(fā)布到微信小程序、支付寶小程序、H5 甚至原生 App。電商項(xiàng)目最怕的是單獨(dú)維護(hù)一個(gè)小程序端再維護(hù)一個(gè) H5 端如果你還想要 App工作量直接翻三倍。uni-app 把這一層跨端差異封裝掉了普通頁(yè)面的開(kāi)發(fā)體驗(yàn)和寫(xiě) Vue 幾乎一致。對(duì)于我這種以技術(shù)實(shí)現(xiàn)為主的人來(lái)說(shuō)不需要去記小程序原生那套繁瑣的setData規(guī)則開(kāi)發(fā)效率提高很多。而且在 PyCharm 里做后端再用 HBuilderX 或 VS Code 寫(xiě) uni-app正好符合標(biāo)題里“pycharm”這個(gè)關(guān)鍵詞的使用場(chǎng)景PyCharm 管 Python 后端前端編輯器管 Vue 文件。兩個(gè)窗口并行調(diào)試后端斷點(diǎn)打進(jìn)去看請(qǐng)求數(shù)據(jù)前端控制臺(tái)看渲染結(jié)果排查問(wèn)題非常直觀。2. 商城核心需求拆解與數(shù)據(jù)庫(kù)設(shè)計(jì)2.1 四大核心模塊的數(shù)據(jù)表結(jié)構(gòu)電商小程序看著功能多拆開(kāi)以后核心就是用戶(hù)、商品、購(gòu)物車(chē)、訂單四大模塊。我設(shè)計(jì)表結(jié)構(gòu)時(shí)沒(méi)有過(guò)度設(shè)計(jì)能拆的表拆掉能省的字段省掉。用戶(hù)表存id、openid、nickname、avatar、phone其中openid是登錄憑證用唯一索引防止重復(fù)綁定。商品表存id、title、subtitle、cover_url、price、stock、category_id、status、sales價(jià)格字段用Numeric(10, 2)絕對(duì)不用浮點(diǎn)數(shù)不然算金額會(huì)出現(xiàn)小數(shù)點(diǎn)后面莫名其妙的誤差。分類(lèi)表就兩個(gè)字段id和name再加一個(gè)sort控制排序。購(gòu)物車(chē)表比較關(guān)鍵它關(guān)聯(lián)的是用戶(hù)和商品user_id、goods_id、quantity、selected另外加了一個(gè)唯一約束(user_id, goods_id)保證同一個(gè)用戶(hù)同一件商品只會(huì)有一行記錄再次加入購(gòu)物車(chē)就做數(shù)量累加。訂單表字段最多order_no、user_id、total_amount、status、address_snapshot、create_time、pay_time。訂單項(xiàng)表則存每個(gè)訂單里的商品快照order_id、goods_id、title、cover_url、price、quantity。這里要特別強(qiáng)調(diào)訂單項(xiàng)必須做“快照”。用戶(hù)下單之后商品標(biāo)題和價(jià)格可能會(huì)被后臺(tái)修改如果訂單詳情直接去關(guān)聯(lián)商品表那用戶(hù)看到的過(guò)去訂單信息就會(huì)變。把標(biāo)題、圖片、單價(jià)原樣復(fù)制到訂單項(xiàng)表里才是電商系統(tǒng)該有的做法。地址也一樣用戶(hù)地址可以隨便改但每筆訂單要保留下單那一刻的地址完整字段不然售后對(duì)賬會(huì)非常麻煩。2.2 用戶(hù)登錄與 JWT 無(wú)狀態(tài)鑒權(quán)小程序端的登錄不能直接用賬號(hào)密碼因?yàn)橛脩?hù)打開(kāi)小程序后要的是“一鍵登錄”。我的方案是前端調(diào)用小程序提供的uni.login獲取臨時(shí) code把 code 傳給后端后端拿著 code 去交換 openid然后創(chuàng)建或更新用戶(hù)記錄最后簽發(fā)一個(gè) JWT token 返回給前端。這個(gè)流程聽(tīng)起來(lái)繞但它是小程序生態(tài)的標(biāo)準(zhǔn)做法核心目的就是讓服務(wù)端拿到的不是用戶(hù)自己填的密碼而是平臺(tái)校驗(yàn)過(guò)的身份憑證。JWT 的好處是不用存儲(chǔ) session服務(wù)端不需要維護(hù)一張會(huì)話表。flask-jwt-extended生成 token 后前端把它存在uni.setStorageSync里之后每次請(qǐng)求在 header 中帶上Authorization: Bearer token后端通過(guò)jwt_required()裝飾器就能拿到當(dāng)前用戶(hù) ID。比如購(gòu)物車(chē)、訂單這些接口都依賴(lài)用戶(hù)身份我只需要在函數(shù)里寫(xiě)get_jwt_identity()就能獲取user_id干凈利落。使用 JWT 也有一個(gè)必須注意的點(diǎn)token 一旦簽發(fā)在有效期內(nèi)是吊銷(xiāo)不了的。所以我把有效期設(shè)置成了 7 天同時(shí)在用戶(hù)表中維護(hù)了一個(gè)token_version字段當(dāng)用戶(hù)修改密碼或者被管理員禁用時(shí)token_version加一重新簽發(fā)的 token 里包含新的版本號(hào)后端在每次請(qǐng)求時(shí)比較版本號(hào)是否一致不通過(guò)就直接返回 401。這種方法既保留 JWT 無(wú)狀態(tài)的優(yōu)勢(shì)又解決了“用戶(hù)被踢下線”的實(shí)際需求。3. Flask 后端 API 的實(shí)現(xiàn)細(xì)節(jié)3.1 項(xiàng)目目錄結(jié)構(gòu)與藍(lán)圖劃分很多新手寫(xiě) Flask 喜歡把所有路由寫(xiě)在一個(gè)app.py里接口少的時(shí)候還行電商這種規(guī)模的項(xiàng)目一上去文件就失控了。我實(shí)際用的是包結(jié)構(gòu)把不同模塊用藍(lán)圖Blueprint拆開(kāi)。項(xiàng)目目錄長(zhǎng)這樣shop_api/ ├── app.py # 入口文件注冊(cè)所有藍(lán)圖 ├── config.py # 配置項(xiàng) ├── extensions.py # 擴(kuò)展對(duì)象初始化 ├── models/ │ ├── __init__.py │ ├── user.py │ ├── goods.py │ ├── cart.py │ └── order.py ├── apis/ │ ├── __init__.py │ ├── auth.py # 登錄相關(guān) │ ├── goods.py # 商品、分類(lèi) │ ├── cart.py # 購(gòu)物車(chē) │ └── order.py # 訂單、支付模擬 ├── utils/ │ ├── response.py # 統(tǒng)一返回格式 │ └── decorators.py # 自定義裝飾器 └── requirements.txt入口文件只負(fù)責(zé)創(chuàng)建app、加載配置、初始化擴(kuò)展、注冊(cè)藍(lán)圖。藍(lán)圖里每個(gè)模塊的 URL 前綴都獨(dú)立比如購(gòu)物車(chē)藍(lán)圖統(tǒng)一掛在/api/cart下面接口路徑就自然形成了/api/cart/list、/api/cart/add。這樣后期加模塊不會(huì)相互影響團(tuán)隊(duì)協(xié)作時(shí)各寫(xiě)各的藍(lán)圖文件沖突也少。統(tǒng)一響應(yīng)格式也很有必要。我用的結(jié)構(gòu)是{code: 0, message: success, data: {}}。成功時(shí) code 為 0失敗時(shí) code 為具體錯(cuò)誤碼比如 1001 表示 token 失效1002 表示商品庫(kù)存不足。前端封裝了請(qǐng)求攔截器后只需要判斷 code 是不是 0不用去解析 HTTP 狀態(tài)碼和自定義 message 的混合體異常提示也能直接透?jìng)鹘o用戶(hù)。3.2 商品列表、搜索與詳情接口設(shè)計(jì)商品列表接口不要一上來(lái)就把所有字段都返回用戶(hù)在小程序端只需要卡片所需的標(biāo)題、圖片、價(jià)格、銷(xiāo)量。所以我用 Flask-SQLAlchemy 的查詢(xún)按分類(lèi)、關(guān)鍵詞、銷(xiāo)量、價(jià)格排序輸出的時(shí)候手工構(gòu)造字典而不是直接序列化模型對(duì)象。這樣能避免把stock、status這些內(nèi)部字段也暴露給前端減少安全性問(wèn)題。商品搜索我用的是LIKE模糊匹配。電商小程序的并發(fā)量不會(huì)太大這個(gè)方案是夠用的。如果以后數(shù)據(jù)量大了再上全文檢索引擎也不遲。接口設(shè)計(jì)上支持page和size參數(shù)返回total、items、has_more小程序端滾動(dòng)到底部加載下一頁(yè)用戶(hù)體驗(yàn)會(huì)好很多。商品詳情接口需要注意瀏覽數(shù)和銷(xiāo)量展示。我在商品表里設(shè)計(jì)了sales字段只有訂單支付成功后才累加。商品詳情頁(yè)的瀏覽量我選擇不加字段記錄因?yàn)轭l繁更新瀏覽量會(huì)拖垮數(shù)據(jù)庫(kù)。如果后續(xù)真的需要我會(huì)用緩存做異步累加而不是每次訪問(wèn)都去 UPDATE 一次。3.3 下單與庫(kù)存扣減事務(wù)和條件更新的正確姿勢(shì)下單是整個(gè)系統(tǒng)最核心、最容易出錯(cuò)的環(huán)節(jié)。我的實(shí)現(xiàn)嚴(yán)格按下面幾步執(zhí)行校驗(yàn)商品是否存在、是否上架。根據(jù)購(gòu)物車(chē)?yán)锏墓催x商品計(jì)算出訂單總金額。按商品維度依次扣減庫(kù)存?？蹨p成功則創(chuàng)建訂單和訂單項(xiàng)扣減失敗則整體回滾。清空對(duì)應(yīng)購(gòu)物車(chē)記錄返回訂單號(hào)。扣庫(kù)存不能先查 stock判斷大于等于購(gòu)買(mǎi)數(shù)量后再 UPDATE因?yàn)椴l(fā)請(qǐng)求下兩個(gè)用戶(hù)可能同時(shí)查到庫(kù)存為 1然后同時(shí)通過(guò)判斷最終把庫(kù)存扣成負(fù)數(shù)。我用的是一個(gè)帶條件的 UPDATE在數(shù)據(jù)庫(kù)層面保證原子性result db.session.execute( db.update(Goods) .where(Goods.id goods_id, Goods.stock quantity) .values(stockGoods.stock - quantity) ) if result.rowcount 0: raise StockNotEnough(goods_id)rowcount如果等于 0說(shuō)明要么商品不存在要么庫(kù)存不足這里直接拋出異常再由外層的事務(wù)裝飾器回滾。把關(guān)鍵判斷交給數(shù)據(jù)庫(kù)而不是 Python 進(jìn)程這是防止超賣(mài)的基本原則。同時(shí)我還要說(shuō)明下單不一定會(huì)支付所以下單時(shí)扣減的是“可售庫(kù)存”支付后如果超時(shí)未支付需要定時(shí)任務(wù)把庫(kù)存加回去。這個(gè)項(xiàng)目里我用了一個(gè)簡(jiǎn)單的定時(shí)清理邏輯每隔一段時(shí)間把超過(guò) 30 分鐘未支付且未取消的訂單取消并回補(bǔ)庫(kù)存。整個(gè)下單流程用db.session.commit()一次性提交任何一步異常都調(diào)用db.session.rollback()。我建議在開(kāi)發(fā)時(shí)寫(xiě)一個(gè)測(cè)試腳本開(kāi) 20 個(gè)線程同時(shí)搶購(gòu)最后一件商品跑完庫(kù)存剛好為 0且只有 1 筆訂單創(chuàng)建成功這是驗(yàn)證并發(fā)安全最直接的方式。4. uni-app 前端開(kāi)發(fā)實(shí)戰(zhàn)4.1 初始化工程與 pages 目錄規(guī)劃用 HBuilderX 創(chuàng)建 uni-app 項(xiàng)目時(shí)我習(xí)慣選擇“默認(rèn)模板”然后手動(dòng)刪除多余的東西。項(xiàng)目結(jié)構(gòu)里最重要的就是pages.json和pages目錄。pages.json負(fù)責(zé)注冊(cè)頁(yè)面路徑、設(shè)置 tabBar 和窗口樣式。因?yàn)槭巧坛琴?gòu)物平臺(tái)我設(shè)了四個(gè)底部 tab首頁(yè)、分類(lèi)、購(gòu)物車(chē)、我的對(duì)應(yīng)四個(gè)頁(yè)面目錄。其余頁(yè)面按照業(yè)務(wù)模塊拆pages/ ├── index/ # 首頁(yè) ├── category/ # 分類(lèi)頁(yè) ├── goods/ # 商品詳情 ├── cart/ # 購(gòu)物車(chē) ├── order/ # 訂單列表、確認(rèn)訂單 ├── pay/ # 模擬支付 └── user/ # 個(gè)人中心、登錄這樣規(guī)劃的好處是頁(yè)面路由和目錄一一對(duì)應(yīng)找文件時(shí)不需要猜。uni-app 的項(xiàng)目里每個(gè)頁(yè)面就是一組.vue文件我在pages.json中給每個(gè)頁(yè)面配置了navigationBarTitleText確保小程序頂部標(biāo)題不會(huì)被默認(rèn)值占位。我習(xí)慣把公共樣式放到uni.scss比如主題色、價(jià)格顏色、邊框變量。小程序里不能直接用var()做主題切換提前把顏色變量統(tǒng)一起來(lái)后面改主色調(diào)就不用全項(xiàng)目搜索替換了。這個(gè)習(xí)慣幫我在老板突然說(shuō)“換個(gè)品牌色”時(shí)省了不少時(shí)間。4.2 封裝請(qǐng)求工具與 token 注入小程序不像瀏覽器沒(méi)有 axios但uni.request已經(jīng)是一個(gè)封裝好的 API。我在此基礎(chǔ)上再包了一層request.js統(tǒng)一處理 baseURL、超時(shí)、token 注入、錯(cuò)誤提示。核心代碼如下const BASE_URL http://localhost:5000/api export function request(options) { return new Promise((resolve, reject) { uni.request({ url: BASE_URL options.url, method: options.method || GET, data: options.data || {}, header: { Content-Type: application/json, Authorization: Bearer uni.getStorageSync(token) }, success(res) { if (res.data.code 0) { resolve(res.data.data) } else { uni.showToast({ title: res.data.message, icon: none }) reject(res.data) } }, fail(err) { uni.showToast({ title: 網(wǎng)絡(luò)異常, icon: none }) reject(err) } }) }) }這里有個(gè)問(wèn)題容易踩開(kāi)發(fā)階段后端跑在 PyCharm 的本地 Flask 服務(wù)上瀏覽器調(diào)試 H5 端可以但真機(jī)預(yù)覽小程序時(shí)localhost指向的是手機(jī)自己根本訪問(wèn)不到電腦上的服務(wù)。我的辦法是開(kāi)發(fā)時(shí)使用電腦的局域網(wǎng) IP比如http://192.168.1.100:5000/api。同時(shí)在小程序開(kāi)發(fā)者工具中勾選“不校驗(yàn)合法域名”等到上線前再改寫(xiě)成正式的 HTTPS 域名。token 失效的處理也很重要。當(dāng)接口返回 code 為 1001 時(shí)request.js需要清掉本地 token然后跳轉(zhuǎn)到登錄頁(yè)面。我一開(kāi)始沒(méi)寫(xiě)這個(gè)邏輯結(jié)果 token 過(guò)期后用戶(hù)一直停留在失敗頁(yè)面體驗(yàn)特別差。加上這個(gè)處理之后用戶(hù)只要重新走一次登錄流程就能繼續(xù)使用。4.3 首頁(yè)、商品詳情與購(gòu)物車(chē)的聯(lián)動(dòng)首頁(yè)我用了搜索框、分類(lèi)側(cè)邊欄、商品卡片流結(jié)合的方式。頂部搜索關(guān)鍵詞變化時(shí)調(diào)用商品搜索接口分類(lèi)切換時(shí)重新請(qǐng)求當(dāng)前分類(lèi)的商品列表。為了減少請(qǐng)求次數(shù)我用的是觸底分頁(yè)加載每次加載 10 條滾動(dòng)到底部觸發(fā)下一頁(yè)。商品詳情頁(yè)的關(guān)鍵是“立即購(gòu)買(mǎi)”和“加入購(gòu)物車(chē)”兩個(gè)操作。點(diǎn)擊加入購(gòu)物車(chē)時(shí)前端只做兩件事把商品 ID 和數(shù)量傳給后端購(gòu)物車(chē)接口如果成功就彈出一個(gè)小 toast并且更新底部 tabBar 的購(gòu)物車(chē)角標(biāo)。角標(biāo)數(shù)量邏輯我通過(guò)uni.$emit(cartUpdated)全局通知其他頁(yè)面監(jiān)聽(tīng)這個(gè)事件后重新獲取購(gòu)物車(chē)數(shù)量避免出現(xiàn)加購(gòu)成功后首頁(yè)角標(biāo)還是舊的這種尷尬。購(gòu)物車(chē)頁(yè)交互是最繁瑣的。每行有一個(gè)復(fù)選框控制選中狀態(tài)底部欄顯示已選商品總價(jià)和結(jié)算按鈕。我維護(hù)一個(gè)selectedMap對(duì)象來(lái)記錄每件商品的選中狀態(tài)選中變化時(shí)重新計(jì)算總價(jià)。后端也支持批量刪除和修改數(shù)量所有操作都返回最新的列表和總價(jià)前端直接用返回?cái)?shù)據(jù)刷新視圖不自己做本地計(jì)算。這樣可以避免本地?cái)?shù)據(jù)和后端不一致的問(wèn)題。下單入口我做了區(qū)分從購(gòu)物車(chē)結(jié)算提交的是購(gòu)物車(chē)選中的商品從詳情頁(yè)立即購(gòu)買(mǎi)提交的是單件商品。所以確認(rèn)訂單頁(yè)需要接受兩種來(lái)源我統(tǒng)一在頁(yè)面參數(shù)中帶上from字段值為cart或buy。后端下單接口也接收這個(gè)來(lái)源如果是buy就直接用請(qǐng)求里的商品列表如果是cart就去讀取購(gòu)物車(chē)選中項(xiàng)。這個(gè)設(shè)計(jì)看起來(lái)簡(jiǎn)單但能把兩個(gè)業(yè)務(wù)場(chǎng)景統(tǒng)一成一套接口不用復(fù)制代碼。5. PyCharm 開(kāi)發(fā)環(huán)境與前后端聯(lián)調(diào)5.1 用 PyCharm 管理 Flask 虛擬環(huán)境與依賴(lài)導(dǎo)出在 PyCharm 中新建 Flask 項(xiàng)目時(shí)我建議先創(chuàng)建一個(gè)獨(dú)立的虛擬環(huán)境不要用系統(tǒng) Python 的全局解釋器。因?yàn)椴煌?xiàng)目依賴(lài)版本經(jīng)常沖突尤其是 Flask 和 SQLAlchemy 的版本組合全局安裝容易出現(xiàn)“A 項(xiàng)目能跑B 項(xiàng)目跑不起來(lái)”的情況。PyCharm 在File - Settings - Project - Python Interpreter里可以選擇虛擬環(huán)境路徑創(chuàng)建后左下角會(huì)顯示當(dāng)前使用的解釋器。依賴(lài)管理我推薦兩條命令pip install flask flask-sqlalchemy flask-jwt-extended flask-cors pymysql pip freeze requirements.txtfreeze出來(lái)的文件在上服務(wù)器時(shí)直接執(zhí)行pip install -r requirements.txt就能復(fù)現(xiàn)環(huán)境。不過(guò)我習(xí)慣再手動(dòng)檢查一遍requirements.txt把那些和項(xiàng)目無(wú)關(guān)的傳遞依賴(lài)清理掉保證環(huán)境干凈。PyCharm 里調(diào)試 Flask 非常順手。給入口文件app.py配置一個(gè) Run Configuration設(shè)置環(huán)境變量FLASK_ENVdevelopment啟動(dòng)后接口地址是http://127.0.0.1:5000。在視圖函數(shù)里打上斷點(diǎn)再用小程序的模擬器去請(qǐng)求接口請(qǐng)求會(huì)在斷點(diǎn)處停住你可以看到 Flask 接收到的 JSON 數(shù)據(jù)和數(shù)據(jù)庫(kù)查詢(xún)結(jié)果。這種調(diào)試方式比靠print猜來(lái)猜去高效得多。5.2 前端聯(lián)調(diào)域名白名單、真機(jī)調(diào)試與跨域聯(lián)調(diào)過(guò)程中最頭疼的問(wèn)題不是代碼邏輯而是網(wǎng)絡(luò)環(huán)境。小程序生產(chǎn)環(huán)境要求所有請(qǐng)求域名必須是 HTTPS并且在后臺(tái)配置白名單。開(kāi)發(fā)階段自然沒(méi)這個(gè)條件解決方法是在微信開(kāi)發(fā)者工具的“詳情-本地設(shè)置”中勾選“不校驗(yàn)合法域名、web-view業(yè)務(wù)域名、TLS 版本以及 HTTPS 證書(shū)”。這樣就能用本地 Flask 的 HTTP 服務(wù)調(diào)試。但注意這個(gè)設(shè)置只對(duì)開(kāi)發(fā)者工具生效真機(jī)預(yù)覽時(shí)還是要用局域網(wǎng) IP并且手機(jī)和電腦處于同一個(gè) WiFi 下。如果你用 HBuilderX 運(yùn)行到微信開(kāi)發(fā)者工具HBuilderX 會(huì)生成一個(gè)臨時(shí)小程序項(xiàng)目路徑。這里有一個(gè)容易忽略的地方每次修改代碼后要在 HBuilderX 里重新運(yùn)行或點(diǎn)擊刷新開(kāi)發(fā)者工具才能拿到最新代碼。我一開(kāi)始改了.vue文件發(fā)現(xiàn)小程序沒(méi)變化還以為沒(méi)保存成功后來(lái)才發(fā)現(xiàn)是 HBuilderX 沒(méi)有重新編譯到微信開(kāi)發(fā)者工具目錄。跨域問(wèn)題主要出現(xiàn)在 H5 端。瀏覽器里uni.request請(qǐng)求 Flask 時(shí)Fe服務(wù)器和前端不是同一個(gè)源瀏覽器會(huì)攔截響應(yīng)。解決辦法是在 Flask 中啟用 CORS我使用flask-corsfrom flask_cors import CORS CORS(app, resources{r/api/*: {origins: *}})加了這一行后H5 端的聯(lián)調(diào)就正常了。小程序端本身不存在瀏覽器跨域限制所以不需要關(guān)心 CORS但也因此更需要注意請(qǐng)求異常時(shí)的錯(cuò)誤處理因?yàn)樾〕绦虻腻e(cuò)誤提示不像瀏覽器控制臺(tái)那么詳細(xì)。6. 部署上線與常見(jiàn)問(wèn)題排查6.1 服務(wù)器部署 Flask 的注意點(diǎn)本地開(kāi)發(fā)用 Flask 自帶服務(wù)器上線可不能繼續(xù)用它。我用的是 Gunicorn 作為 WSGI 服務(wù)Ubuntu 服務(wù)器上配合 Nginx 反向代理。啟動(dòng)命令大概是gunicorn -w 4 -b 0.0.0.0:8000 app:app-w 4表示 4 個(gè) worker 進(jìn)程。在 PyCharm 中寫(xiě)的入口app:app前一個(gè)是文件名后一個(gè)是被創(chuàng)建的Flask實(shí)例變量名。Gunicorn 不能跑在 Windows所以部署時(shí)切到 Linux 環(huán)境。如果你用的是 Windows 服務(wù)器可以考慮 Waitress但我個(gè)人還是推薦 Linux 加 Nginx。Nginx 做的事情有兩件一是把 80/443 端口的請(qǐng)求轉(zhuǎn)發(fā)給 Gunicorn 的 8000 端口二是有需要時(shí)直接托管靜態(tài)資源。在小程序場(chǎng)景中圖片和商品圖我建議單獨(dú)用對(duì)象存儲(chǔ)服務(wù)不放在應(yīng)用服務(wù)器里否則帶寬和存儲(chǔ)都會(huì)成為瓶頸。數(shù)據(jù)庫(kù)我單獨(dú)使用一個(gè)云數(shù)據(jù)庫(kù)實(shí)例不會(huì)和應(yīng)用搶內(nèi)存。部署后一定要檢查數(shù)據(jù)庫(kù)連接池。Flask-SQLAlchemy 默認(rèn)連接池不算大高并發(fā)下容易出現(xiàn)TimeoutError。我設(shè)置SQLALCHEMY_POOL_PRE_PINGTrue可以讓連接失效時(shí)自動(dòng)重連這個(gè)參數(shù)解決了我曾經(jīng)在長(zhǎng)時(shí)間運(yùn)行后接口假死的問(wèn)題。6.2 高頻報(bào)錯(cuò)排查實(shí)錄我在整個(gè)開(kāi)發(fā)過(guò)程中整理了下面幾個(gè)高頻報(bào)錯(cuò)它們幾乎每個(gè)都是新手必踩的坑。第一個(gè)是“數(shù)據(jù)庫(kù)時(shí)間比本地時(shí)間少 8 小時(shí)”。Flask 里的datetime.now()默認(rèn)讀取服務(wù)器時(shí)區(qū)如果服務(wù)器是 UTC后端返回的create_time就是 UTC 時(shí)間。前端直接把時(shí)間字符串展示出來(lái)就會(huì)出現(xiàn)訂單時(shí)間比用戶(hù)看到的時(shí)間少 8 小時(shí)。我的解決辦法是在后端統(tǒng)一使用本地時(shí)區(qū)比如在config.py中設(shè)置TIMEZONE Asia/Shanghai并且在返回時(shí)間字段前統(tǒng)一做時(shí)區(qū)轉(zhuǎn)換讓前端拿到的直接就是東八區(qū)的時(shí)間字符串不做二次轉(zhuǎn)換。第二個(gè)是“JSON 序列化 Decimal 失敗”。價(jià)格字段是NumericFlask 的默認(rèn) JSON encoder 不認(rèn)識(shí)Decimal對(duì)象直接用jsonify返回會(huì)報(bào)TypeError。我的解決方法是寫(xiě)一個(gè)自定義 JSON Encoder把Decimal轉(zhuǎn)換成字符串確保精度不丟失。前端計(jì)算金額時(shí)也不要用浮點(diǎn)數(shù)我是在后端返回字符串后由前端通過(guò)parseInt和parseFloat在顯示層處理核心金額計(jì)算始終交給后端。from flask.json import JSONEncoder from decimal import Decimal class CustomJSONEncoder(JSONEncoder): def default(self, obj): if isinstance(obj, Decimal): return str(obj) return super().default(obj) app.json_encoder CustomJSONEncoder第三個(gè)是“前端加了購(gòu)物車(chē)但角標(biāo)不更新”。原因是最先寫(xiě)的代碼只是在加購(gòu)成功后uni.showToast沒(méi)有通知其他頁(yè)面刷新。后來(lái)我引入了uni.$emit(cartUpdated)在首頁(yè)和購(gòu)物車(chē)頁(yè)用uni.$on(cartUpdated, function() { ... })接收事件問(wèn)題就解決了。不過(guò)要注意頁(yè)面卸載時(shí)要用uni.$off解綁事件否則會(huì)重復(fù)監(jiān)聽(tīng)導(dǎo)致多次請(qǐng)求。第四個(gè)是“并發(fā)下單導(dǎo)致庫(kù)存扣成負(fù)數(shù)”。我一開(kāi)始用的是先查詢(xún)?cè)俑潞髞?lái)改成條件 UPDATE 后問(wèn)題徹底消失。這里再?gòu)?qiáng)調(diào)一遍高性能場(chǎng)景下的并發(fā)安全不能靠 Python 代碼判斷要充分利用數(shù)據(jù)庫(kù)的行鎖和原子操作。6.3 上線前的安全自檢清單電商項(xiàng)目只要上線就涉及資金和用戶(hù)數(shù)據(jù)安全。我給自己列了幾條鐵律你可以直接抄走。第一小程序前端絕對(duì)不能放密鑰。任何 AppSecret、支付秘鑰、數(shù)據(jù)庫(kù)連接串都只能保存在后端環(huán)境變量里。小程序代碼可以被反編譯只要前端出現(xiàn)明文密鑰基本等于把后臺(tái)拱手送人。第二Flask 必須關(guān)閉debug。我在config.py里區(qū)分生產(chǎn)環(huán)境和開(kāi)發(fā)環(huán)境生產(chǎn)環(huán)境下DEBUGFalse同時(shí)設(shè)置SECRET_KEY為環(huán)境變量讀取的值不寫(xiě)死在代碼里。第三所有涉及金額的接口后端必須重新算價(jià)。前端傳過(guò)來(lái)的商品 ID 和數(shù)量可以信但價(jià)格不能信。下單接口要從數(shù)據(jù)庫(kù)讀取當(dāng)前商品價(jià)格乘以數(shù)量得到總金額然后再創(chuàng)建訂單。如果拿前端傳過(guò)來(lái)的價(jià)格直接入庫(kù)用戶(hù)改一下請(qǐng)求里的字段就能用 0.01 元買(mǎi)到商城里的商品。這是最典型也最致命的漏洞。第四用戶(hù)輸入不能直接拼接進(jìn) SQL。Flask-SQLAlchemy 的 ORM 默認(rèn)參數(shù)化查詢(xún)相對(duì)安全但是使用原生 SQL 時(shí)要格外小心。商品搜索里的關(guān)鍵詞參數(shù)一律通過(guò)text()綁定參數(shù)的方式傳值不直接字符串拼接。第五做支付回調(diào)時(shí)一定要驗(yàn)簽。這個(gè)項(xiàng)目雖然只是模擬支付但我也按真實(shí)標(biāo)準(zhǔn)預(yù)留了回調(diào)接口。如果接真實(shí)支付回調(diào)通知里哪怕只有一個(gè)字段對(duì)不上簽名也要直接拒收。任何人只要知道你的回調(diào)地址就能偽造支付成功通知。6.4 做完這個(gè)項(xiàng)目后的幾點(diǎn)經(jīng)驗(yàn)沉淀這是我前后端獨(dú)立完成的第一個(gè)完整電商系統(tǒng)最大的體會(huì)是選型不是越火越好而是越貼合場(chǎng)景越好。Flask 搭配 uni-app讓我用最少的心智負(fù)擔(dān)完成了一個(gè)可以跑通完整閉環(huán)的小程序。另一個(gè)感觸是很多問(wèn)題看起來(lái)是技術(shù)問(wèn)題實(shí)際上是沒(méi)有先想清楚流程。比如庫(kù)存扣減為什么要用條件更新訂單金額為什么必須后端算地址為什么必須做快照這些都不是代碼本身而是業(yè)務(wù)規(guī)則約束下的必然選擇。最后分享一個(gè)小技巧開(kāi)發(fā)時(shí)一定要把后端返回的 JSON 結(jié)構(gòu)固定下來(lái)。我在項(xiàng)目開(kāi)始前先寫(xiě)了一個(gè)接口文檔規(guī)定好 code、message、data 的格式前端和后端完全按這個(gè)文檔并行開(kāi)發(fā)后面聯(lián)調(diào)幾乎沒(méi)有扯皮。如果你也想做類(lèi)似的項(xiàng)目建議把下單、庫(kù)存、支付這三個(gè)環(huán)節(jié)先按最笨的方式實(shí)現(xiàn)跑通后再優(yōu)化千萬(wàn)不要一上來(lái)就追求“分布式”“高并發(fā)”先把單體閉環(huán)做扎實(shí)比什么都強(qiáng)。