最近整理項目代碼時翻到一套之前花了兩周時間搭出來的“寵物之家”系統(tǒng)技術(shù)棧是 Flask 做后端Vue 做前端頁面開發(fā)環(huán)境用 PyCharm。這個項目在同類里非常典型寵物領(lǐng)養(yǎng)、臨時寄養(yǎng)、后臺管理、用戶登錄注冊全都是老生常談但又繞不開的功能。很多人拿到這種題目第一反應(yīng)是套個管理系統(tǒng)模板但真要從零把一個可演示、可部署的完整系統(tǒng)寫出來里面還是有不少值得說的細節(jié)。這篇博文我就拿這個項目當例子從需求拆解、技術(shù)選型、數(shù)據(jù)庫設(shè)計、核心接口、前端聯(lián)調(diào)到部署避坑完整串一遍。先說一下項目的真實定位它不是一個大廠級別的中臺就是一個單體應(yīng)用后端 Flask 提供 REST API前端 Vue 寫單頁頁面數(shù)據(jù)庫用的 SQLite 做開發(fā)環(huán)境、上線再切 MySQL。這個組合在課程設(shè)計、個人作品集、小團隊內(nèi)部工具里出現(xiàn)的頻率非常高原因也很簡單——能跑、能改、能演示還不重。接下來按模塊拆開講。1. 項目盤點與需求拆解1.1 寵物之家在解決什么業(yè)務(wù)問題寵物之家解決的是兩個看起來相似、但邏輯上要分開的場景領(lǐng)養(yǎng)和寄養(yǎng)。領(lǐng)養(yǎng)場景里平臺是信息撮合方。有寵物來源方通常是救助站、個人送養(yǎng)人把寵物信息發(fā)布出來有領(lǐng)養(yǎng)意向的用戶瀏覽寵物列表看中之后提交領(lǐng)養(yǎng)申請管理員在后臺對申請做審核審核通過后寵物狀態(tài)改成“已領(lǐng)養(yǎng)”。這個流程看著簡單但狀態(tài)處理很考驗設(shè)計。比如寵物一旦被別人提交了申請就不能繼續(xù)出現(xiàn)在“可領(lǐng)養(yǎng)”列表里了否則兩個人同時申請同一只寵物后臺審核就會打架。寄養(yǎng)場景則更像一個服務(wù)預(yù)約流程。寵物主人因為出差、旅游等原因沒法照顧寵物就在平臺上下一個寄養(yǎng)訂單選擇寄養(yǎng)開始和結(jié)束日期系統(tǒng)根據(jù)時長算費用管理員確認后訂單進入“寄養(yǎng)中”狀態(tài)寄養(yǎng)結(jié)束后訂單完成。這里面涉及日期重疊校驗、訂單狀態(tài)流轉(zhuǎn)、費用計算邏輯比領(lǐng)養(yǎng)復(fù)雜一點。這兩個場景合在一起就是寵物之家的全部核心。剩下的是用戶管理、內(nèi)容管理這類周邊功能本質(zhì)上都是給這兩個主流程服務(wù)的。1.2 角色、權(quán)限與核心功能邊界系統(tǒng)里我設(shè)計了三種角色普通用戶、管理員、訪客。訪客不是一種持久角色只是為了描述“未登錄狀態(tài)下的瀏覽行為”。角色主要能力典型操作訪客瀏覽寵物列表、查看寵物詳情打開首頁看寵物不登錄也能看普通用戶注冊登錄后提交領(lǐng)養(yǎng)申請、創(chuàng)建寄養(yǎng)訂單、管理個人資料申請領(lǐng)養(yǎng)“布丁”、給自家貓預(yù)約7天寄養(yǎng)管理員管理寵物信息、審核領(lǐng)養(yǎng)申請、處理寄養(yǎng)訂單、管理用戶上架新寵物、通過/駁回領(lǐng)養(yǎng)申請、確認寄養(yǎng)訂單權(quán)限邊界這件事我在開發(fā)時就強調(diào)了一點前端菜單隱藏只是體驗問題后端接口必須再做一次鑒權(quán)。很多人前端的“刪除按鈕”用v-ifrole admin控制但后端的/api/pet/delete接口誰都能直接調(diào)。這種漏洞在演示時可能沒事答辯或外包驗收時一問就露餡。所以后端每個接口我都在路由裝飾器層做了角色校驗管理員接口除了要登錄還要檢查 token 里的角色字段。這個細節(jié)放在第三章詳細講。2. 技術(shù)選型Flask 作為后端Vue 作為前端2.1 為什么用 Flask 而不是 Django項目標題里同時出現(xiàn)了 Flask 和 Django很容易讓人困惑。實際項目里我選的是 Flask原因很現(xiàn)實這個系統(tǒng)規(guī)模不大Flask 的輕量優(yōu)勢能讓我把每個模塊的邏輯都寫得很清楚。具體展開說一下兩者差異。Django 自帶 ORM、Admin 后臺、Form 校驗、遷移工具功能完整但是“完整”的另一面是“重”。你建一個模型之后Django 自動幫你生成一套后臺看起來省事可對自定義業(yè)務(wù)邏輯比較強的場景反而不順手。比如領(lǐng)養(yǎng)申請這個流程狀態(tài)流轉(zhuǎn)和審核操作被我塞了比較多的自定義判斷Django Admin 默認的增刪改查頁面要改很多配置才能貼合業(yè)務(wù)。Flask 不一樣它只提供基礎(chǔ)的路由、請求上下文剩下的一切由你自己拼裝代碼里面的每一個判斷都清清楚楚調(diào)試時路徑也短出錯更容易定位。另外一個考慮因素是學習曲線。Flask 的代碼從app Flask(__name__)開始寫一個接口只要幾行入門成本低。這個項目如果給一個剛開始接觸前后端分離的人看Flask 的后端代碼比 Django 更容易看懂因為數(shù)據(jù)流是肉眼可見的。2.2 前后端分離架構(gòu)怎么落地前后端分離聽起來高級實際上就是把“界面展示”和“業(yè)務(wù)邏輯”拆到兩個進程里。前端 Vue 跑在 8080 端口負責渲染頁面、收集用戶操作、發(fā)請求后端 Flask 跑在 5000 端口只處理 API 請求并返回 JSON。項目的目錄結(jié)構(gòu)大概長這樣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后端不是把所有路由寫在同一個文件里而是按照業(yè)務(wù)模塊拆成了幾個 Blueprint。這個拆分很重要不然隨著接口數(shù)量增多app.py會膨脹到?jīng)]法維護。開發(fā)階段前端通過代理轉(zhuǎn)發(fā)請求Vue CLI 的vue.config.js里配置一個 devServer.proxy 就能把/api開頭的請求轉(zhuǎn)發(fā)到后端。上線階段則用 Nginx 做反向代理同一個域名下/指向前端靜態(tài)文件/api指向后端服務(wù)這樣跨域問題也順帶解決了。2.3 PyCharm 下的開發(fā)環(huán)境搭建PyCharm 配合 Flask 項目的體驗確實好主要功勞集中在三塊虛擬環(huán)境管理、代碼補全和調(diào)試器。我建議不要用全局 Python 環(huán)境而是給項目建一個獨立的虛擬環(huán)境。PyCharm 里新建項目時直接選 Virtualenv或者進入Settings - Project - Python Interpreter新增一個。虛擬環(huán)境可以把 Flask、SQLAlchemy、PyJWT 這些依賴隔離在項目目錄內(nèi)換機器部署時只需要用pip freeze requirements.txt導(dǎo)出一份依賴列表目標機器上pip install -r requirements.txt就能還原。調(diào)試這塊Flask 自帶 debug 模式能打印錯誤堆棧但 PyCharm 的斷點調(diào)試更實用。在某個 API 函數(shù)里打一個斷點瀏覽器發(fā)起一次請求PyCharm 會自動把請求攔截住一步一步看變量變化。這種能力在處理登錄鑒權(quán)、狀態(tài)流轉(zhuǎn)類邏輯時特別好用。3. 核心業(yè)務(wù)模塊的設(shè)計與實現(xiàn)3.1 數(shù)據(jù)庫模型設(shè)計寵物之家涉及四張核心表用戶表、寵物表、領(lǐng)養(yǎng)申請表、寄養(yǎng)訂單表。四張表各自獨立又通過外鍵關(guān)聯(lián)成一個閉合的數(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è)計時我重點考慮了兩個點。第一個是密碼存儲。密碼絕對不能明文存進數(shù)據(jù)庫。這里用 Werkzeug 的generate_password_hash做加密校驗時用check_password_hash。即使數(shù)據(jù)庫文件泄露攻擊者拿到的也是哈希值不是原始密碼。第二個是寵物狀態(tài)字段。寵物表里我留了一個status字段可選值有available可領(lǐng)養(yǎng)、pending申請審核中、adopted已領(lǐng)養(yǎng)、suspend下架。為什么不用布爾值的“是否可領(lǐng)養(yǎng)”因為狀態(tài)之間存在過渡期用戶提交申請之后到管理員審核之前寵物既不能算“可領(lǐng)養(yǎng)”也還沒到“已領(lǐng)養(yǎng)”如果只用一個布爾字段這個區(qū)間沒法表達。多狀態(tài)枚舉字段雖然看著笨但邏輯最清晰。3.2 基于 JWT 的登錄與權(quán)限攔截登錄模塊我選的是 JWT不是傳統(tǒng)的 Session。原因很簡單前后端分離場景下前端和后端不在同一個端口Session 依賴 Cookie 的自動攜帶配置起來麻煩跨域時還要處理 CORS 的credentials設(shè)置。JWT 天然適合這種架構(gòu)用戶登錄成功后后端返回一個 token 字符串前端存到本地存儲里每次請求在請求頭帶上Authorization: Bearer token即可。核驗邏輯寫成一個裝飾器# 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在實際項目里不能寫死在代碼中我上線時改成了從環(huán)境變量讀取。JWT 有一個坑要注意它不需要服務(wù)端存儲狀態(tài)所以 token 一旦簽發(fā)在過期之前無法主動撤銷。如果遇到安全要求高的場景要么把 token 過期時間設(shè)短要么加一層服務(wù)端黑名單但那樣反而犧牲了 JWT 的無狀態(tài)優(yōu)勢取舍要看具體項目級。3.3 寵物管理與領(lǐng)養(yǎng)申請閉環(huán)寵物管理接口天然分成兩個角色視角管理員可以增刪改查寵物普通用戶只能看列表和詳情。刪除接口我特意做了軟刪除策略。后來想了想在這個系統(tǒng)里寵物被刪除通常意味著“下架”而不是“從數(shù)據(jù)庫抹掉”直接DELETE FROM pet WHERE id1會把歷史申請記錄的外鍵關(guān)系搞斷。所以實際實現(xiàn)里我沒有用物理刪除而是把status改成suspend列表接口默認過濾掉這些寵物。領(lǐng)養(yǎng)申請閉環(huán)是整套系統(tǒng)里邏輯最繞的一部分。用戶提交申請時后端要做的檢查按順序來當前寵物狀態(tài)必須是available當前用戶之前沒有對這只寵物提交過通過審核的申請創(chuàng)建申請記錄同時把寵物狀態(tài)改為pending前兩步是為了防并發(fā)兩個用戶同時看到一只可領(lǐng)養(yǎng)的寵物都點了申請按鈕如果后端不檢查就產(chǎn)生了兩條申請記錄。雖然實際教學中并發(fā)量很小但這個邏輯該有還得有。管理員審核時接口接收adoption_id和審核結(jié)果。通過則把對應(yīng)寵物改成adopted并駁回這只寵物的其他pending申請拒絕則把寵物改回available。這里面就是一個事務(wù)操作我用 Flask-SQLAlchemy 的db.session包了整個過程中間任何一步出錯就回滾保證數(shù)據(jù)庫不會出現(xiàn)“寵物已經(jīng)領(lǐng)養(yǎng)但申請記錄還是待審核”這種矛盾狀態(tài)。# adoption_api.py 簡化版 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: 申請不存在}), 404 pet Pet.query.get(adoption.pet_id) if action approved: adoption.status approved pet.status adopted # 駁回同寵物其他待審核申請 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ǎng)訂單表里必須校驗起始日期和結(jié)束日期的先后順序還要避免同一只寵物在同一時間段被預(yù)約兩次。日期重疊的判斷我卡了很久后來理清楚了一個法則兩條時間記錄重疊等價于“新開始時間 舊結(jié)束時間 且 新結(jié)束時間 舊開始時間”。比如舊訂單是 9 月 1 日到 9 月 7 日新請求如果也是 9 月 1 日至 9 月 7 日重疊如果新請求是 9 月 8 日到 9 月 10 日不重疊。訂單狀態(tài)我設(shè)計了五個pending待確認、confirmed已確認、in_progress寄養(yǎng)中、completed已完成、canceled已取消。狀態(tài)流轉(zhuǎn)的約束規(guī)則寫在業(yè)務(wù)層pending可以被管理員確認成confirmed也可以被用戶自己取消成canceledconfirmed在開始日期到達后系統(tǒng)自動或由管理員手動改成in_progressin_progress在結(jié)束日期到達后改成completed只有pending和confirmed狀態(tài)允許用戶取消為了避免狀態(tài)想怎么跳就怎么跳我專門寫了一個校驗函數(shù)每次更新狀態(tài)前檢查當前狀態(tài)到目標狀態(tài)是否合法。這樣雖然代碼多幾行但防止了接口調(diào)用方傳一個奇奇怪怪的狀態(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 } } ];普通用戶能看到的頁面有寵物列表、詳情、登錄注冊、我的申請、我的寄養(yǎng)訂單。管理員頁面單獨放在views/admin目錄路由上加了meta.role標記。vue-router 的全局守衛(wèi)里讀取 token 解析后的角色如果不是管理員就重定向到首頁。這個只是體驗層后端接口的權(quán)限校驗依然不可省略。4.2 Axios 請求封裝與接口對接Vue 頁面里如果每個頁面都直接axios.get(url, { headers })寫重復(fù)代碼會很多而且 token 還要手動塞進頭部。我封裝了一個request.js實例// 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)。后端約定了一個固定的返回格式{ code: 0, msg: success, data: {...} }錯誤時code非 0。前端頁面只需要判斷response.code 0再取數(shù)據(jù)不用每個接口單獨處理異常結(jié)構(gòu)。4.3 關(guān)鍵頁面實現(xiàn)細節(jié)寵物列表頁是普通用戶進系統(tǒng)的第一站我用卡片網(wǎng)格展示寵物。每個卡片包含寵物照片、名字、品種、年齡和當前狀態(tài)。狀態(tài)這個字段需要映射成中文展示available顯示“可領(lǐng)養(yǎng)”pending顯示“審核中”adopted顯示“已領(lǐng)養(yǎng)”。這個映射我放在前端的公共utils/statusMap.js里避免頁面組件里到處寫重復(fù)的三元判斷。寵物詳情頁比較有意思的地方是“申請領(lǐng)養(yǎng)”按鈕的可點擊條件。按鈕是否可用要同時滿足三個條件寵物狀態(tài)是可領(lǐng)養(yǎng)、用戶已經(jīng)登錄、用戶不是管理員。用戶未登錄時按鈕旁邊顯示“登錄后即可申請”點擊后跳轉(zhuǎn)登錄頁面管理員登錄時根本不顯示申請按鈕因為管理員不會申請領(lǐng)養(yǎng)自己的平臺寵物。提交領(lǐng)養(yǎng)申請的表單里我留了一個必填的備注框引導(dǎo)用戶填寫喂養(yǎng)經(jīng)驗、居住環(huán)境等信息。這個設(shè)計是學真實領(lǐng)養(yǎng)平臺的目的是輔助后臺管理員做初步篩選也讓整個申請流程更像真事。5. 聯(lián)調(diào)、部署與踩坑記錄5.1 跨域問題的三種解法前后端分離開發(fā)中遇到最多的第一個坑就是跨域。前端跑在 127.0.0.1:8080后端跑在 127.0.0.1:5000瀏覽器默認會攔截前后端不同端口之間的 AJAX 請求。最簡單的解法是安裝 Flask-Cors 擴展初始化時放開所有跨域限制。這種方式適合本地開發(fā)但不適合上線。上線后接口如果對任意域開放等于把接口暴露給第三方網(wǎng)頁隨意外調(diào)用存在被刷接口的風險。第二種解法前端開發(fā)環(huán)境用 devServer proxy。Vue CLI 項目在vue.config.js里寫module.exports { devServer: { proxy: { /api: { target: http://127.0.0.1:5000, changeOrigin: true } } } }這樣前端請求/api/pet/list開發(fā)服務(wù)器會幫它轉(zhuǎn)發(fā)給 5000 端口的后端。瀏覽器里看到的請求地址始終是同源的不會觸發(fā)跨域限制。第三種解法也就是上線的做法用 Nginx 同時托管前端靜態(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ā)時一切正常上線后遇到一個問題Nginx 只托管了前端靜態(tài)文件訪問/api走代理但用戶上傳的圖片路徑如/uploads/xxx.jpg沒有匹配到任何 location直接 404。解決辦法是給圖片目錄單獨加一個 locationlocation /uploads/ { alias /var/www/pet-home/uploads/; }同時提醒一個細節(jié)后端返回的圖片地址不要存成完整的http://127.0.0.1:5000/uploads/xxx.jpg因為服務(wù)器的 IP 或域名一變前端就全都崩了。正確做法是只存相對的資源路徑uploads/xxx.jpg前端拼接域名顯示圖片。我這個項目里統(tǒng)一用了相對路徑換環(huán)境部署時省去一大半麻煩。5.3 部署時常見問題部署到 Linux 服務(wù)器時有幾個坑比較隱蔽一一記錄。第一個是數(shù)據(jù)庫遷移。開發(fā)時用的 SQLite文件數(shù)據(jù)庫直接復(fù)制數(shù)據(jù)庫文件到服務(wù)器沒問題。但切到 MySQL 之后需要重新建庫、重新配置連接字符串。如果模型改動頻繁建議用 Flask-Migrate 管理數(shù)據(jù)庫遷移省得每次手動刪表重建。第二個是 Python 依賴和版本兼容。requirements.txt里最好鎖定版本號不鎖定的話過幾個月在新環(huán)境裝依賴可能裝出一個不兼容的新版本。比如 Flask-SQLAlchemy 2.x 和 3.x 的某些 API 變化會造成代碼報錯。第三是服務(wù)進程存活。上線我用的 gunicorn 做 WSGI 服務(wù)但 gunicorn 進程如果掛了就不會自動起來。所以用 systemd 寫了一個守護服務(wù)進程崩潰后自動重啟。這個方法很老套但確實管用比定期人工檢查靠譜得多。6. 項目復(fù)盤與可擴展方向6.1 維護心得寵物之家這個系統(tǒng)代碼量不算大后端大概 2000 多行前端 3000 多行但我維護了很長一段時間中間沒覺得頭疼主要歸功于一開始守住了幾條原則。第一所有接口都按業(yè)務(wù)模塊分組用 Blueprint 劃分不往app.py里堆。第二API 返回格式統(tǒng)一成{ code, msg, data }前端攔截器統(tǒng)一處理。第三狀態(tài)字段都用字符串枚舉表示不藏數(shù)字魔法值。這三條看著是基本功但很多中途爛掉的項目都是在這上面翻的車。6.2 后續(xù)升級建議如果這個系統(tǒng)還要繼續(xù)往下走我會優(yōu)先補三塊線上支付對接、消息通知、數(shù)據(jù)統(tǒng)計分析。寄養(yǎng)訂單現(xiàn)在只是算費用不收款接個標準支付接口可以真實跑通商業(yè)閉環(huán)。消息通知方面領(lǐng)養(yǎng)申請審核通過后可以用簡單的站內(nèi)信或者推送小程序通知用戶不用短信成本低。數(shù)據(jù)統(tǒng)計則適合給管理員后臺加一個首頁儀表盤展示寵物總數(shù)、領(lǐng)養(yǎng)轉(zhuǎn)化率、寄養(yǎng)訂單量直接查幾張表做聚合就行。另外可以將前端 Vue 2 升級到 Vue 3組合式 API 寫業(yè)務(wù)邏輯更順手狀態(tài)管理也能用更輕量的方式。后端可以逐步拆出服務(wù)層把業(yè)務(wù)邏輯從 API 視圖函數(shù)里挪出去邏輯更清晰測試也好寫?；乜凑麄€實現(xiàn)過程最深的體會是“別急著寫代碼”。一開始我拿到題目就上手建表結(jié)果做了兩天推翻重來。后來老老實實把業(yè)務(wù)流程圖和數(shù)據(jù)流圖畫清楚再動手寫效率反而更高。中間還踩了不少環(huán)境、部署相關(guān)的坑我把每一條都記錄在項目文檔里后來別人接手也能少走彎路。如果你正在做類似領(lǐng)養(yǎng)寄養(yǎng)的系統(tǒng)建議直接拿這張表去對照一下自己的功能是否齊全模塊必備功能加分功能用戶注冊、登錄、角色區(qū)分找回密碼、手機號綁定寵物發(fā)布、列表、詳情、狀態(tài)管理多圖展示、篩選搜索領(lǐng)養(yǎng)申請、審核、狀態(tài)流轉(zhuǎn)申請記錄回溯、免疫信息檔案寄養(yǎng)下單、日期校驗、費用計算支付、日歷可視化、護理日志后臺寵物管理、訂單管理、用戶管理數(shù)據(jù)統(tǒng)計、操作日志框架和語言只是工具核心還是把業(yè)務(wù)流程想透。希望這篇分享能給正在做類似系統(tǒng)的你一些啟發(fā)。