最近整理項(xiàng)目代碼時(shí)翻到一套之前花了兩周時(shí)間搭出來的“寵物之家”系統(tǒng)技術(shù)棧是 Flask 做后端Vue 做前端頁面開發(fā)環(huán)境用 PyCharm。這個(gè)項(xiàng)目在同類里非常典型寵物領(lǐng)養(yǎng)、臨時(shí)寄養(yǎng)、后臺(tái)管理、用戶登錄注冊(cè)全都是老生常談但又繞不開的功能。很多人拿到這種題目第一反應(yīng)是套個(gè)管理系統(tǒng)模板但真要從零把一個(gè)可演示、可部署的完整系統(tǒng)寫出來里面還是有不少值得說的細(xì)節(jié)。這篇博文我就拿這個(gè)項(xiàng)目當(dāng)例子從需求拆解、技術(shù)選型、數(shù)據(jù)庫設(shè)計(jì)、核心接口、前端聯(lián)調(diào)到部署避坑完整串一遍。先說一下項(xiàng)目的真實(shí)定位它不是一個(gè)大廠級(jí)別的中臺(tái)就是一個(gè)單體應(yīng)用后端 Flask 提供 REST API前端 Vue 寫單頁頁面數(shù)據(jù)庫用的 SQLite 做開發(fā)環(huán)境、上線再切 MySQL。這個(gè)組合在課程設(shè)計(jì)、個(gè)人作品集、小團(tuán)隊(duì)內(nèi)部工具里出現(xiàn)的頻率非常高原因也很簡(jiǎn)單——能跑、能改、能演示還不重。接下來按模塊拆開講。1. 項(xiàng)目盤點(diǎn)與需求拆解1.1 寵物之家在解決什么業(yè)務(wù)問題寵物之家解決的是兩個(gè)看起來相似、但邏輯上要分開的場(chǎng)景領(lǐng)養(yǎng)和寄養(yǎng)。領(lǐng)養(yǎng)場(chǎng)景里平臺(tái)是信息撮合方。有寵物來源方通常是救助站、個(gè)人送養(yǎng)人把寵物信息發(fā)布出來有領(lǐng)養(yǎng)意向的用戶瀏覽寵物列表看中之后提交領(lǐng)養(yǎng)申請(qǐng)管理員在后臺(tái)對(duì)申請(qǐng)做審核審核通過后寵物狀態(tài)改成“已領(lǐng)養(yǎng)”。這個(gè)流程看著簡(jiǎn)單但狀態(tài)處理很考驗(yàn)設(shè)計(jì)。比如寵物一旦被別人提交了申請(qǐng)就不能繼續(xù)出現(xiàn)在“可領(lǐng)養(yǎng)”列表里了否則兩個(gè)人同時(shí)申請(qǐng)同一只寵物后臺(tái)審核就會(huì)打架。寄養(yǎng)場(chǎng)景則更像一個(gè)服務(wù)預(yù)約流程。寵物主人因?yàn)槌霾睢⒙糜蔚仍驔]法照顧寵物就在平臺(tái)上下一個(gè)寄養(yǎng)訂單選擇寄養(yǎng)開始和結(jié)束日期系統(tǒng)根據(jù)時(shí)長(zhǎng)算費(fèi)用管理員確認(rèn)后訂單進(jìn)入“寄養(yǎng)中”狀態(tài)寄養(yǎng)結(jié)束后訂單完成。這里面涉及日期重疊校驗(yàn)、訂單狀態(tài)流轉(zhuǎn)、費(fèi)用計(jì)算邏輯比領(lǐng)養(yǎng)復(fù)雜一點(diǎn)。這兩個(gè)場(chǎng)景合在一起就是寵物之家的全部核心。剩下的是用戶管理、內(nèi)容管理這類周邊功能本質(zhì)上都是給這兩個(gè)主流程服務(wù)的。1.2 角色、權(quán)限與核心功能邊界系統(tǒng)里我設(shè)計(jì)了三種角色普通用戶、管理員、訪客。訪客不是一種持久角色只是為了描述“未登錄狀態(tài)下的瀏覽行為”。角色主要能力典型操作訪客瀏覽寵物列表、查看寵物詳情打開首頁看寵物不登錄也能看普通用戶注冊(cè)登錄后提交領(lǐng)養(yǎng)申請(qǐng)、創(chuàng)建寄養(yǎng)訂單、管理個(gè)人資料申請(qǐng)領(lǐng)養(yǎng)“布丁”、給自家貓預(yù)約7天寄養(yǎng)管理員管理寵物信息、審核領(lǐng)養(yǎng)申請(qǐng)、處理寄養(yǎng)訂單、管理用戶上架新寵物、通過/駁回領(lǐng)養(yǎng)申請(qǐng)、確認(rèn)寄養(yǎng)訂單權(quán)限邊界這件事我在開發(fā)時(shí)就強(qiáng)調(diào)了一點(diǎn)前端菜單隱藏只是體驗(yàn)問題后端接口必須再做一次鑒權(quán)。很多人前端的“刪除按鈕”用v-ifrole admin控制但后端的/api/pet/delete接口誰都能直接調(diào)。這種漏洞在演示時(shí)可能沒事答辯或外包驗(yàn)收時(shí)一問就露餡。所以后端每個(gè)接口我都在路由裝飾器層做了角色校驗(yàn)管理員接口除了要登錄還要檢查 token 里的角色字段。這個(gè)細(xì)節(jié)放在第三章詳細(xì)講。2. 技術(shù)選型Flask 作為后端Vue 作為前端2.1 為什么用 Flask 而不是 Django項(xiàng)目標(biāo)題里同時(shí)出現(xiàn)了 Flask 和 Django很容易讓人困惑。實(shí)際項(xiàng)目里我選的是 Flask原因很現(xiàn)實(shí)這個(gè)系統(tǒng)規(guī)模不大Flask 的輕量?jī)?yōu)勢(shì)能讓我把每個(gè)模塊的邏輯都寫得很清楚。具體展開說一下兩者差異。Django 自帶 ORM、Admin 后臺(tái)、Form 校驗(yàn)、遷移工具功能完整但是“完整”的另一面是“重”。你建一個(gè)模型之后Django 自動(dòng)幫你生成一套后臺(tái)看起來省事可對(duì)自定義業(yè)務(wù)邏輯比較強(qiáng)的場(chǎng)景反而不順手。比如領(lǐng)養(yǎng)申請(qǐng)這個(gè)流程狀態(tài)流轉(zhuǎn)和審核操作被我塞了比較多的自定義判斷Django Admin 默認(rèn)的增刪改查頁面要改很多配置才能貼合業(yè)務(wù)。Flask 不一樣它只提供基礎(chǔ)的路由、請(qǐng)求上下文剩下的一切由你自己拼裝代碼里面的每一個(gè)判斷都清清楚楚調(diào)試時(shí)路徑也短出錯(cuò)更容易定位。另外一個(gè)考慮因素是學(xué)習(xí)曲線。Flask 的代碼從app Flask(__name__)開始寫一個(gè)接口只要幾行入門成本低。這個(gè)項(xiàng)目如果給一個(gè)剛開始接觸前后端分離的人看Flask 的后端代碼比 Django 更容易看懂因?yàn)閿?shù)據(jù)流是肉眼可見的。2.2 前后端分離架構(gòu)怎么落地前后端分離聽起來高級(jí)實(shí)際上就是把“界面展示”和“業(yè)務(wù)邏輯”拆到兩個(gè)進(jìn)程里。前端 Vue 跑在 8080 端口負(fù)責(zé)渲染頁面、收集用戶操作、發(fā)請(qǐng)求后端 Flask 跑在 5000 端口只處理 API 請(qǐng)求并返回 JSON。項(xiàng)目的目錄結(jié)構(gòu)大概長(zhǎng)這樣pet-home/ ├── backend/ │ ├── app.py │ ├── models.py │ ├── auth.py │ ├── api/ │ │ ├── user_api.py │ │ ├── pet_api.py │ │ ├── adoption_api.py │ │ └── foster_api.py │ ├── requirements.txt │ └── config.py └── frontend/ ├── public/ ├── src/ │ ├── api/ │ ├── router/ │ ├── views/ │ └── components/ └── package.json后端不是把所有路由寫在同一個(gè)文件里而是按照業(yè)務(wù)模塊拆成了幾個(gè) Blueprint。這個(gè)拆分很重要不然隨著接口數(shù)量增多app.py會(huì)膨脹到?jīng)]法維護(hù)。開發(fā)階段前端通過代理轉(zhuǎn)發(fā)請(qǐng)求Vue CLI 的vue.config.js里配置一個(gè) devServer.proxy 就能把/api開頭的請(qǐng)求轉(zhuǎn)發(fā)到后端。上線階段則用 Nginx 做反向代理同一個(gè)域名下/指向前端靜態(tài)文件/api指向后端服務(wù)這樣跨域問題也順帶解決了。2.3 PyCharm 下的開發(fā)環(huán)境搭建PyCharm 配合 Flask 項(xiàng)目的體驗(yàn)確實(shí)好主要功勞集中在三塊虛擬環(huán)境管理、代碼補(bǔ)全和調(diào)試器。我建議不要用全局 Python 環(huán)境而是給項(xiàng)目建一個(gè)獨(dú)立的虛擬環(huán)境。PyCharm 里新建項(xiàng)目時(shí)直接選 Virtualenv或者進(jìn)入Settings - Project - Python Interpreter新增一個(gè)。虛擬環(huán)境可以把 Flask、SQLAlchemy、PyJWT 這些依賴隔離在項(xiàng)目目錄內(nèi)換機(jī)器部署時(shí)只需要用pip freeze requirements.txt導(dǎo)出一份依賴列表目標(biāo)機(jī)器上pip install -r requirements.txt就能還原。調(diào)試這塊Flask 自帶 debug 模式能打印錯(cuò)誤堆棧但 PyCharm 的斷點(diǎn)調(diào)試更實(shí)用。在某個(gè) API 函數(shù)里打一個(gè)斷點(diǎn)瀏覽器發(fā)起一次請(qǐng)求PyCharm 會(huì)自動(dòng)把請(qǐng)求攔截住一步一步看變量變化。這種能力在處理登錄鑒權(quán)、狀態(tài)流轉(zhuǎn)類邏輯時(shí)特別好用。3. 核心業(yè)務(wù)模塊的設(shè)計(jì)與實(shí)現(xiàn)3.1 數(shù)據(jù)庫模型設(shè)計(jì)寵物之家涉及四張核心表用戶表、寵物表、領(lǐng)養(yǎng)申請(qǐng)表、寄養(yǎng)訂單表。四張表各自獨(dú)立又通過外鍵關(guān)聯(lián)成一個(gè)閉合的數(shù)據(jù)關(guān)系網(wǎng)。用 Flask-SQLAlchemy 定義模型代碼大致是這樣# models.py from datetime import datetime from flask_sqlalchemy import SQLAlchemy from werkzeug.security import generate_password_hash, check_password_hash db SQLAlchemy() class User(db.Model): __tablename__ user id db.Column(db.Integer, primary_keyTrue) username db.Column(db.String(80), uniqueTrue, nullableFalse) password_hash db.Column(db.String(256), nullableFalse) role db.Column(db.String(20), defaultuser) phone db.Column(db.String(20)) created_at db.Column(db.DateTime, defaultdatetime.utcnow) def set_password(self, password): self.password_hash generate_password_hash(password) def check_password(self, password): return check_password_hash(self.password_hash, password) class Pet(db.Model): __tablename__ pet id db.Column(db.Integer, primary_keyTrue) name db.Column(db.String(80)) species db.Column(db.String(20)) # cat / dog breed db.Column(db.String(50)) age db.Column(db.Integer) status db.Column(db.String(20), defaultavailable) cover_url db.Column(db.String(200)) description db.Column(db.Text) created_at db.Column(db.DateTime, defaultdatetime.utcnow) class Adoption(db.Model): __tablename__ adoption id db.Column(db.Integer, primary_keyTrue) pet_id db.Column(db.Integer, db.ForeignKey(pet.id)) user_id db.Column(db.Integer, db.ForeignKey(user.id)) status db.Column(db.String(20), defaultpending) remark db.Column(db.Text) apply_time db.Column(db.DateTime, defaultdatetime.utcnow) class FosterOrder(db.Model): __tablename__ foster_order id db.Column(db.Integer, primary_keyTrue) pet_id db.Column(db.Integer, db.ForeignKey(pet.id)) owner_id db.Column(db.Integer, db.ForeignKey(user.id)) start_date db.Column(db.Date) end_date db.Column(db.Date) fee db.Column(db.Float, default0.0) status db.Column(db.String(20), defaultpending) note db.Column(db.Text)設(shè)計(jì)時(shí)我重點(diǎn)考慮了兩個(gè)點(diǎn)。第一個(gè)是密碼存儲(chǔ)。密碼絕對(duì)不能明文存進(jìn)數(shù)據(jù)庫。這里用 Werkzeug 的generate_password_hash做加密校驗(yàn)時(shí)用check_password_hash。即使數(shù)據(jù)庫文件泄露攻擊者拿到的也是哈希值不是原始密碼。第二個(gè)是寵物狀態(tài)字段。寵物表里我留了一個(gè)status字段可選值有available可領(lǐng)養(yǎng)、pending申請(qǐng)審核中、adopted已領(lǐng)養(yǎng)、suspend下架。為什么不用布爾值的“是否可領(lǐng)養(yǎng)”因?yàn)闋顟B(tài)之間存在過渡期用戶提交申請(qǐng)之后到管理員審核之前寵物既不能算“可領(lǐng)養(yǎng)”也還沒到“已領(lǐng)養(yǎng)”如果只用一個(gè)布爾字段這個(gè)區(qū)間沒法表達(dá)。多狀態(tài)枚舉字段雖然看著笨但邏輯最清晰。3.2 基于 JWT 的登錄與權(quán)限攔截登錄模塊我選的是 JWT不是傳統(tǒng)的 Session。原因很簡(jiǎn)單前后端分離場(chǎng)景下前端和后端不在同一個(gè)端口Session 依賴 Cookie 的自動(dòng)攜帶配置起來麻煩跨域時(shí)還要處理 CORS 的credentials設(shè)置。JWT 天然適合這種架構(gòu)用戶登錄成功后后端返回一個(gè) token 字符串前端存到本地存儲(chǔ)里每次請(qǐng)求在請(qǐng)求頭帶上Authorization: Bearer token即可。核驗(yàn)邏輯寫成一個(gè)裝飾器# auth.py import jwt from functools import wraps from flask import request, jsonify, g from datetime import datetime, timedelta SECRET_KEY change-me-in-production def generate_token(user): payload { uid: user.id, role: user.role, exp: datetime.utcnow() timedelta(days7) } return jwt.encode(payload, SECRET_KEY, algorithmHS256) def login_required(fn): wraps(fn) def wrapper(*args, **kwargs): token request.headers.get(Authorization, ) if token.startswith(Bearer ): token token[7:] try: payload jwt.decode(token, SECRET_KEY, algorithms[HS256]) g.user_id payload[uid] g.user_role payload[role] except Exception: return jsonify({code: 401, msg: 登錄已失效}), 401 return fn(*args, **kwargs) return wrapper def admin_required(fn): wraps(fn) def wrapper(*args, **kwargs): token request.headers.get(Authorization, ) if token.startswith(Bearer ): token token[7:] try: payload jwt.decode(token, SECRET_KEY, algorithms[HS256]) except Exception: return jsonify({code: 401, msg: 登錄已失效}), 401 if payload.get(role) ! admin: return jsonify({code: 403, msg: 無權(quán)限}), 403 g.user_id payload[uid] g.user_role payload[role] return fn(*args, **kwargs) return wrapperSECRET_KEY在實(shí)際項(xiàng)目里不能寫死在代碼中我上線時(shí)改成了從環(huán)境變量讀取。JWT 有一個(gè)坑要注意它不需要服務(wù)端存儲(chǔ)狀態(tài)所以 token 一旦簽發(fā)在過期之前無法主動(dòng)撤銷。如果遇到安全要求高的場(chǎng)景要么把 token 過期時(shí)間設(shè)短要么加一層服務(wù)端黑名單但那樣反而犧牲了 JWT 的無狀態(tài)優(yōu)勢(shì)取舍要看具體項(xiàng)目級(jí)。3.3 寵物管理與領(lǐng)養(yǎng)申請(qǐng)閉環(huán)寵物管理接口天然分成兩個(gè)角色視角管理員可以增刪改查寵物普通用戶只能看列表和詳情。刪除接口我特意做了軟刪除策略。后來想了想在這個(gè)系統(tǒng)里寵物被刪除通常意味著“下架”而不是“從數(shù)據(jù)庫抹掉”直接DELETE FROM pet WHERE id1會(huì)把歷史申請(qǐng)記錄的外鍵關(guān)系搞斷。所以實(shí)際實(shí)現(xiàn)里我沒有用物理刪除而是把status改成suspend列表接口默認(rèn)過濾掉這些寵物。領(lǐng)養(yǎng)申請(qǐng)閉環(huán)是整套系統(tǒng)里邏輯最繞的一部分。用戶提交申請(qǐng)時(shí)后端要做的檢查按順序來當(dāng)前寵物狀態(tài)必須是available當(dāng)前用戶之前沒有對(duì)這只寵物提交過通過審核的申請(qǐng)創(chuàng)建申請(qǐng)記錄同時(shí)把寵物狀態(tài)改為pending前兩步是為了防并發(fā)兩個(gè)用戶同時(shí)看到一只可領(lǐng)養(yǎng)的寵物都點(diǎn)了申請(qǐng)按鈕如果后端不檢查就產(chǎn)生了兩條申請(qǐng)記錄。雖然實(shí)際教學(xué)中并發(fā)量很小但這個(gè)邏輯該有還得有。管理員審核時(shí)接口接收adoption_id和審核結(jié)果。通過則把對(duì)應(yīng)寵物改成adopted并駁回這只寵物的其他pending申請(qǐng)拒絕則把寵物改回available。這里面就是一個(gè)事務(wù)操作我用 Flask-SQLAlchemy 的db.session包了整個(gè)過程中間任何一步出錯(cuò)就回滾保證數(shù)據(jù)庫不會(huì)出現(xiàn)“寵物已經(jīng)領(lǐng)養(yǎng)但申請(qǐng)記錄還是待審核”這種矛盾狀態(tài)。# adoption_api.py 簡(jiǎn)化版 app.route(/api/adoption/int:adoption_id/review, methods[POST]) admin_required def review_adoption(adoption_id): action request.json.get(action) # approved / rejected adoption Adoption.query.get(adoption_id) if not adoption: return jsonify({code: 404, msg: 申請(qǐng)不存在}), 404 pet Pet.query.get(adoption.pet_id) if action approved: adoption.status approved pet.status adopted # 駁回同寵物其他待審核申請(qǐng) Adoption.query.filter( Adoption.pet_id pet.id, Adoption.status pending, Adoption.id ! adoption.id ).update({status: rejected}) elif action rejected: adoption.status rejected if pet.status pending: pet.status available db.session.commit() return jsonify({code: 0, msg: 處理成功})3.4 寄養(yǎng)預(yù)約與訂單狀態(tài)流轉(zhuǎn)寄養(yǎng)的復(fù)雜度比領(lǐng)養(yǎng)更高因?yàn)樗嗔艘粋€(gè)“時(shí)間段”的維度。寄養(yǎng)訂單表里必須校驗(yàn)起始日期和結(jié)束日期的先后順序還要避免同一只寵物在同一時(shí)間段被預(yù)約兩次。日期重疊的判斷我卡了很久后來理清楚了一個(gè)法則兩條時(shí)間記錄重疊等價(jià)于“新開始時(shí)間 舊結(jié)束時(shí)間 且 新結(jié)束時(shí)間 舊開始時(shí)間”。比如舊訂單是 9 月 1 日到 9 月 7 日新請(qǐng)求如果也是 9 月 1 日至 9 月 7 日重疊如果新請(qǐng)求是 9 月 8 日到 9 月 10 日不重疊。訂單狀態(tài)我設(shè)計(jì)了五個(gè)pending待確認(rèn)、confirmed已確認(rèn)、in_progress寄養(yǎng)中、completed已完成、canceled已取消。狀態(tài)流轉(zhuǎn)的約束規(guī)則寫在業(yè)務(wù)層pending可以被管理員確認(rèn)成confirmed也可以被用戶自己取消成canceledconfirmed在開始日期到達(dá)后系統(tǒng)自動(dòng)或由管理員手動(dòng)改成in_progressin_progress在結(jié)束日期到達(dá)后改成completed只有pending和confirmed狀態(tài)允許用戶取消為了避免狀態(tài)想怎么跳就怎么跳我專門寫了一個(gè)校驗(yàn)函數(shù)每次更新狀態(tài)前檢查當(dāng)前狀態(tài)到目標(biāo)狀態(tài)是否合法。這樣雖然代碼多幾行但防止了接口調(diào)用方傳一個(gè)奇奇怪怪的狀態(tài)過來搞壞數(shù)據(jù)。4. 前端 Vue 集成思路4.1 路由規(guī)劃與頁面結(jié)構(gòu)前端我用 Vue 2 加了 vue-router頁面不多但路由規(guī)劃直接映射了業(yè)務(wù)結(jié)構(gòu)。// router/index.js const routes [ { path: /, name: home, component: () import(../views/HomeView.vue) }, { path: /pets, name: petList, component: () import(../views/PetList.vue) }, { path: /pets/:id, name: petDetail, component: () import(../views/PetDetail.vue) }, { path: /login, name: login, component: () import(../views/LoginView.vue) }, { path: /register, name: register, component: () import(../views/RegisterView.vue) }, { path: /my/adoptions, name: myAdoptions, component: () import(../views/MyAdoptions.vue) }, { path: /my/fosters, name: myFosters, component: () import(../views/MyFosters.vue) }, { path: /admin, name: adminDashboard, component: () import(../views/admin/Dashboard.vue), meta: { role: admin } } ];普通用戶能看到的頁面有寵物列表、詳情、登錄注冊(cè)、我的申請(qǐng)、我的寄養(yǎng)訂單。管理員頁面單獨(dú)放在views/admin目錄路由上加了meta.role標(biāo)記。vue-router 的全局守衛(wèi)里讀取 token 解析后的角色如果不是管理員就重定向到首頁。這個(gè)只是體驗(yàn)層后端接口的權(quán)限校驗(yàn)依然不可省略。4.2 Axios 請(qǐng)求封裝與接口對(duì)接Vue 頁面里如果每個(gè)頁面都直接axios.get(url, { headers })寫重復(fù)代碼會(huì)很多而且 token 還要手動(dòng)塞進(jìn)頭部。我封裝了一個(gè)request.js實(shí)例// api/request.js import axios from axios const request axios.create({ baseURL: process.env.VUE_APP_BASE_URL || /api, timeout: 10000 }) request.interceptors.request.use(config { const token localStorage.getItem(token) if (token) { config.headers.Authorization Bearer ${token} } return config }) request.interceptors.response.use( response response.data, error { if (error.response error.response.status 401) { localStorage.removeItem(token) window.location.href /login } return Promise.reject(error) } ) export default request響應(yīng)攔截器統(tǒng)一處理后端返回的結(jié)構(gòu)。后端約定了一個(gè)固定的返回格式{ code: 0, msg: success, data: {...} }錯(cuò)誤時(shí)code非 0。前端頁面只需要判斷response.code 0再取數(shù)據(jù)不用每個(gè)接口單獨(dú)處理異常結(jié)構(gòu)。4.3 關(guān)鍵頁面實(shí)現(xiàn)細(xì)節(jié)寵物列表頁是普通用戶進(jìn)系統(tǒng)的第一站我用卡片網(wǎng)格展示寵物。每個(gè)卡片包含寵物照片、名字、品種、年齡和當(dāng)前狀態(tài)。狀態(tài)這個(gè)字段需要映射成中文展示available顯示“可領(lǐng)養(yǎng)”pending顯示“審核中”adopted顯示“已領(lǐng)養(yǎng)”。這個(gè)映射我放在前端的公共utils/statusMap.js里避免頁面組件里到處寫重復(fù)的三元判斷。寵物詳情頁比較有意思的地方是“申請(qǐng)領(lǐng)養(yǎng)”按鈕的可點(diǎn)擊條件。按鈕是否可用要同時(shí)滿足三個(gè)條件寵物狀態(tài)是可領(lǐng)養(yǎng)、用戶已經(jīng)登錄、用戶不是管理員。用戶未登錄時(shí)按鈕旁邊顯示“登錄后即可申請(qǐng)”點(diǎn)擊后跳轉(zhuǎn)登錄頁面管理員登錄時(shí)根本不顯示申請(qǐng)按鈕因?yàn)楣芾韱T不會(huì)申請(qǐng)領(lǐng)養(yǎng)自己的平臺(tái)寵物。提交領(lǐng)養(yǎng)申請(qǐng)的表單里我留了一個(gè)必填的備注框引導(dǎo)用戶填寫喂養(yǎng)經(jīng)驗(yàn)、居住環(huán)境等信息。這個(gè)設(shè)計(jì)是學(xué)真實(shí)領(lǐng)養(yǎng)平臺(tái)的目的是輔助后臺(tái)管理員做初步篩選也讓整個(gè)申請(qǐng)流程更像真事。5. 聯(lián)調(diào)、部署與踩坑記錄5.1 跨域問題的三種解法前后端分離開發(fā)中遇到最多的第一個(gè)坑就是跨域。前端跑在 127.0.0.1:8080后端跑在 127.0.0.1:5000瀏覽器默認(rèn)會(huì)攔截前后端不同端口之間的 AJAX 請(qǐng)求。最簡(jiǎn)單的解法是安裝 Flask-Cors 擴(kuò)展初始化時(shí)放開所有跨域限制。這種方式適合本地開發(fā)但不適合上線。上線后接口如果對(duì)任意域開放等于把接口暴露給第三方網(wǎng)頁隨意外調(diào)用存在被刷接口的風(fēng)險(xiǎn)。第二種解法前端開發(fā)環(huán)境用 devServer proxy。Vue CLI 項(xiàng)目在vue.config.js里寫module.exports { devServer: { proxy: { /api: { target: http://127.0.0.1:5000, changeOrigin: true } } } }這樣前端請(qǐng)求/api/pet/list開發(fā)服務(wù)器會(huì)幫它轉(zhuǎn)發(fā)給 5000 端口的后端。瀏覽器里看到的請(qǐng)求地址始終是同源的不會(huì)觸發(fā)跨域限制。第三種解法也就是上線的做法用 Nginx 同時(shí)托管前端靜態(tài)文件和后端反向代理server { listen 80; server_name pet-home.example.com; location / { root /var/www/pet-home/dist; try_files $uri $uri/ /index.html; } location /api/ { proxy_pass http://127.0.0.1:5000/api/; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } }三種方案按開發(fā)階段和上線階段配合使用跨域問題就徹底不存在了。5.2 圖片上傳與靜態(tài)資源處理寵物信息必然要上傳圖片。最開始我把圖片路徑直接存在數(shù)據(jù)庫的cover_url字段里圖片本身存到后端的uploads目錄。開發(fā)時(shí)一切正常上線后遇到一個(gè)問題Nginx 只托管了前端靜態(tài)文件訪問/api走代理但用戶上傳的圖片路徑如/uploads/xxx.jpg沒有匹配到任何 location直接 404。解決辦法是給圖片目錄單獨(dú)加一個(gè) locationlocation /uploads/ { alias /var/www/pet-home/uploads/; }同時(shí)提醒一個(gè)細(xì)節(jié)后端返回的圖片地址不要存成完整的http://127.0.0.1:5000/uploads/xxx.jpg因?yàn)榉?wù)器的 IP 或域名一變前端就全都崩了。正確做法是只存相對(duì)的資源路徑uploads/xxx.jpg前端拼接域名顯示圖片。我這個(gè)項(xiàng)目里統(tǒng)一用了相對(duì)路徑換環(huán)境部署時(shí)省去一大半麻煩。5.3 部署時(shí)常見問題部署到 Linux 服務(wù)器時(shí)有幾個(gè)坑比較隱蔽一一記錄。第一個(gè)是數(shù)據(jù)庫遷移。開發(fā)時(shí)用的 SQLite文件數(shù)據(jù)庫直接復(fù)制數(shù)據(jù)庫文件到服務(wù)器沒問題。但切到 MySQL 之后需要重新建庫、重新配置連接字符串。如果模型改動(dòng)頻繁建議用 Flask-Migrate 管理數(shù)據(jù)庫遷移省得每次手動(dòng)刪表重建。第二個(gè)是 Python 依賴和版本兼容。requirements.txt里最好鎖定版本號(hào)不鎖定的話過幾個(gè)月在新環(huán)境裝依賴可能裝出一個(gè)不兼容的新版本。比如 Flask-SQLAlchemy 2.x 和 3.x 的某些 API 變化會(huì)造成代碼報(bào)錯(cuò)。第三是服務(wù)進(jìn)程存活。上線我用的 gunicorn 做 WSGI 服務(wù)但 gunicorn 進(jìn)程如果掛了就不會(huì)自動(dòng)起來。所以用 systemd 寫了一個(gè)守護(hù)服務(wù)進(jìn)程崩潰后自動(dòng)重啟。這個(gè)方法很老套但確實(shí)管用比定期人工檢查靠譜得多。6. 項(xiàng)目復(fù)盤與可擴(kuò)展方向6.1 維護(hù)心得寵物之家這個(gè)系統(tǒng)代碼量不算大后端大概 2000 多行前端 3000 多行但我維護(hù)了很長(zhǎng)一段時(shí)間中間沒覺得頭疼主要?dú)w功于一開始守住了幾條原則。第一所有接口都按業(yè)務(wù)模塊分組用 Blueprint 劃分不往app.py里堆。第二API 返回格式統(tǒng)一成{ code, msg, data }前端攔截器統(tǒng)一處理。第三狀態(tài)字段都用字符串枚舉表示不藏?cái)?shù)字魔法值。這三條看著是基本功但很多中途爛掉的項(xiàng)目都是在這上面翻的車。6.2 后續(xù)升級(jí)建議如果這個(gè)系統(tǒng)還要繼續(xù)往下走我會(huì)優(yōu)先補(bǔ)三塊線上支付對(duì)接、消息通知、數(shù)據(jù)統(tǒng)計(jì)分析。寄養(yǎng)訂單現(xiàn)在只是算費(fèi)用不收款接個(gè)標(biāo)準(zhǔn)支付接口可以真實(shí)跑通商業(yè)閉環(huán)。消息通知方面領(lǐng)養(yǎng)申請(qǐng)審核通過后可以用簡(jiǎn)單的站內(nèi)信或者推送小程序通知用戶不用短信成本低。數(shù)據(jù)統(tǒng)計(jì)則適合給管理員后臺(tái)加一個(gè)首頁儀表盤展示寵物總數(shù)、領(lǐng)養(yǎng)轉(zhuǎn)化率、寄養(yǎng)訂單量直接查幾張表做聚合就行。另外可以將前端 Vue 2 升級(jí)到 Vue 3組合式 API 寫業(yè)務(wù)邏輯更順手狀態(tài)管理也能用更輕量的方式。后端可以逐步拆出服務(wù)層把業(yè)務(wù)邏輯從 API 視圖函數(shù)里挪出去邏輯更清晰測(cè)試也好寫。回看整個(gè)實(shí)現(xiàn)過程最深的體會(huì)是“別急著寫代碼”。一開始我拿到題目就上手建表結(jié)果做了兩天推翻重來。后來老老實(shí)實(shí)把業(yè)務(wù)流程圖和數(shù)據(jù)流圖畫清楚再動(dòng)手寫效率反而更高。中間還踩了不少環(huán)境、部署相關(guān)的坑我把每一條都記錄在項(xiàng)目文檔里后來別人接手也能少走彎路。如果你正在做類似領(lǐng)養(yǎng)寄養(yǎng)的系統(tǒng)建議直接拿這張表去對(duì)照一下自己的功能是否齊全模塊必備功能加分功能用戶注冊(cè)、登錄、角色區(qū)分找回密碼、手機(jī)號(hào)綁定寵物發(fā)布、列表、詳情、狀態(tài)管理多圖展示、篩選搜索領(lǐng)養(yǎng)申請(qǐng)、審核、狀態(tài)流轉(zhuǎn)申請(qǐng)記錄回溯、免疫信息檔案寄養(yǎng)下單、日期校驗(yàn)、費(fèi)用計(jì)算支付、日歷可視化、護(hù)理日志后臺(tái)寵物管理、訂單管理、用戶管理數(shù)據(jù)統(tǒng)計(jì)、操作日志框架和語言只是工具核心還是把業(yè)務(wù)流程想透。希望這篇分享能給正在做類似系統(tǒng)的你一些啟發(fā)。