說起來這可能不算最“主流”的技術選型但我最近把一個茶文化交流平臺從零搭到上線前端用的 Vue 3后端是 Python Django整體跑下來非常順手。這類平臺既不是純內容站也不是純社區(qū)產品它更像一個“內容 社區(qū) 活動”的混合體要展示茶品百科、沉淀茶藝文章還要支撐用戶發(fā)帖交流、評論互動、收藏點贊。如果你也在做類似的興趣社區(qū)或內容平臺這篇文章應該能幫你省不少彎路。我會按自己的實戰(zhàn)順序來講先講這個項目到底該拆成哪些模塊再落到 Django 數(shù)據(jù)模型、DRF 接口設計、Vue 3 前端工程然后是前后端聯(lián)調時最容易出問題的幾個環(huán)節(jié)最后聊上線部署和性能實測。整個過程里穿插了不少我實際踩過的坑希望能給你一些可以直接抄作業(yè)的參考。1. 先想清楚茶文化平臺到底是“內容站”還是“社區(qū)”1.1 為什么用 Vue 3 Django 這組搭配很多人一看到“社區(qū)”兩個字就想著上重框架一看到“內容平臺”就想著搞 CMS。實際上茶文化交流平臺這兩個屬性都有但都不算極端內容以圖文為主偶爾帶視頻社區(qū)以帖子和評論為主不需要實時聊天那種高并發(fā)場景。這個定位決定了技術棧不需要往“大而全”的方向走而是要快、穩(wěn)、好維護。我當時選 Vue 3 Django主要基于三個判斷。第一Django 自帶 Admin 后臺和 ORM對內容型平臺是天然優(yōu)勢。茶品百科、文化文章這種數(shù)據(jù)需要運營人員經常錄入和修改Django Admin 幾乎不用額外開發(fā)就能頂上。第二Django REST FrameworkDRF把接口層的序列化、分頁、權限都封裝好了開發(fā)效率比手寫 Flask 路由高不少尤其適合一個人或小團隊從零到一。第三Vue 3 的組合式 API 加 Pinia 做狀態(tài)管理配合 Vite 的構建速度前端開發(fā)體驗很好而且生態(tài)里像 Element Plus、富文本編輯器、圖片懶加載這些組件都很成熟不用造輪子。作為對比我也簡單評估過 Node.js Express 和 Spring Boot。Node 生態(tài)做社區(qū)實時性更好但內容管理后臺要自己搭Spring Boot 在企業(yè)里很穩(wěn)但對小團隊來說開發(fā)節(jié)奏偏重了。Python 這邊還有個額外優(yōu)勢以后想給平臺加文本分類、關鍵詞抽取、茶文化知識圖譜之類的功能可以直接用 Python 的數(shù)據(jù)處理生態(tài)不需要跨語言。1.2 從兩張“原型圖”倒推核心模塊我在動手寫代碼之前其實只畫了兩張簡單的頁面草圖一張是首頁另一張是社區(qū)帖子詳情頁。首頁決定了“內容端”要有什么帖子詳情頁決定了“社區(qū)端”要有什么。倒推下來的核心模塊大概是這些用戶體系注冊、登錄、個人主頁、編輯資料、頭像上傳、關注/粉絲。茶品百科茶葉名稱、產地、分類、工藝、口感描述、圖片可以按分類和產地篩選。文化內容文章資訊、茶藝視頻展示、茶人故事支持標簽和搜索。社區(qū)互動發(fā)帖、評論、回復、點贊、收藏、分享?；顒幽K茶會活動發(fā)布、報名、活動回顧內容沉淀。個人中心我的發(fā)布、我的收藏、我的報名、瀏覽記錄。模塊清單列完技術上的難點基本就清晰了一是數(shù)據(jù)模型的關系設計二是權限控制自己的帖子只能自己改別人的內容只能看三是富文本內容的存儲與安全四是圖片處理。后面四部分我會逐一展開。有一點要提醒你模塊不要貪多。我最初還想加直播和實時聊天后來砍掉了。茶文化平臺的節(jié)奏偏慢用戶更需要的是“高質量的沉淀內容”和“有深度的討論”這兩個做扎實了比堆功能有用得多。2. 數(shù)據(jù)模型設計把“茶文化”翻譯成一張張表2.1 核心模型字段與關系Django 的 ORM 設計模型很直觀但正因為太直觀很多人會忽略字段類型、索引、外鍵關系對后續(xù)性能的影響。茶文化平臺的數(shù)據(jù)關系不算復雜我最后沉淀了下面這幾張核心表。模型關鍵字段說明User擴展用戶phone、avatar、bio、favorite_tea使用 Django 自帶的 User 做一對一擴展Tea茶品百科name、origin、category、process、flavor、cover、description分類用 choices 或外鍵都可以產地建議單獨字段Article文化文章title、content、author、cover、tags、view_count富文本內容存 TextField標簽用多對多或簡單逗號分隔Post社區(qū)帖子title、content、author、topic、images圖片存在 ImageField或只存 URL 列表 JSON 字段Comment評論content、author、post、parentparent 用于樓中樓回復可為空Favorite收藏user、content_type、object_id用 Django ContentType 實現(xiàn)通用收藏Follow關注follower、following一對多自關聯(lián)查粉絲和關注列表都方便Activity活動title、start_time、location、max_people、participants報名關系單獨拎出來更好擴展這里有一個我特別想展開的地方收藏功能。剛開始我習慣給每個模型都加一個 favorite_count 字段然后各自建一張收藏表比如 TeaFavorite、ArticleFavorite。但后來發(fā)現(xiàn)這會導致接口層要寫大量重復邏輯。更好的做法是引入 Django 自帶的 ContentType 通用外鍵一張 Favorite 表就能收藏所有內容。用 ContentType 的寫法大致長這樣from django.contrib.contenttypes.fields import GenericForeignKey from django.contrib.contenttypes.models import ContentType class Favorite(models.Model): user models.ForeignKey(User, on_deletemodels.CASCADE, related_namefavorites) content_type models.ForeignKey(ContentType, on_deletemodels.CASCADE) object_id models.PositiveIntegerField() content_object GenericForeignKey(content_type, object_id) created_at models.DateTimeField(auto_now_addTrue) class Meta: constraints [ models.UniqueConstraint( fields[user, content_type, object_id], nameunique_favorite, ) ]這樣前端傳一個content_type和object_id就能在任意模型上收藏后端只需要一個通用視圖。唯一要注意的是查詢時要select_related把對應的 content_object 取出來否則 N1 查詢會讓你接口慢得懷疑人生。2.2 索引、外鍵與查詢性能的最初設計數(shù)據(jù)模型階段就要為查詢場景設計索引不要等數(shù)據(jù)多了再回頭改。我在初期設計時主要加了這些索引列表頁排序字段比如 Article 的created_at、Post 的created_at加db_indexTrue。外鍵關聯(lián)字段Comment.post、Favorite.user這些默認就帶索引不用額外處理。篩選場景字段Tea 的category和origin這兩個字段可能用于組合篩選可以建聯(lián)合索引。計數(shù)統(tǒng)計字段Post 的view_count、Article 的view_count后續(xù)做熱門排序直接order_by(-view_count)。還有一個容易忽略的點Django 默認的DateTimeField(auto_now_addTrue)只記錄創(chuàng)建時間不會更新時間。如果業(yè)務里需要“最后回復時間”來排序帖子列表必須單獨加一個last_replied_at字段在有新評論時手動更新。這個字段對社區(qū)類平臺非常關鍵因為用戶進論壇看的往往是最新有動靜的帖子而不是最早創(chuàng)建的帖子。數(shù)據(jù)庫選型上開發(fā)階段我直接用 SQLite 起步部署到生產就切到 PostgreSQL。切換過程基本沒遇到什么坑Django 的 ORM 抽象得比較好。用 PostgreSQL 的好處是后續(xù)可以做全文搜索SearchVector比在業(yè)務層用icontains一個個字段掃要靠譜得多。3. Django 后端接口不是寫出來是排出來的3.1 從模型到序列化器再到視圖集Django 后端我用了 DRF整體流程就是“模型 - 序列化器 - 視圖集 - 路由注冊”這條鏈路。不要跳過序列化器直接寫 APIView因為序列化器的嵌套展示、字段校驗、錯誤信息格式化都是現(xiàn)成的能少寫很多代碼。以茶品列表接口為例序列化器可以這樣寫from rest_framework import serializers from .models import Tea class TeaListSerializer(serializers.ModelSerializer): category_display serializers.CharField(sourceget_category_display, read_onlyTrue) class Meta: model Tea fields [id, name, origin, category, category_display, cover, flavor]然后在視圖集里定義標準動作from rest_framework import viewsets from rest_framework.permissions import IsAuthenticatedOrReadOnly class TeaViewSet(viewsets.ReadOnlyModelViewSet): queryset Tea.objects.all().order_by(-created_at) serializer_class TeaListSerializer permission_classes [IsAuthenticatedOrReadOnly] def get_queryset(self): queryset super().get_queryset() category self.request.query_params.get(category) origin self.request.query_params.get(origin) if category: queryset queryset.filter(categorycategory) if origin: queryset queryset.filter(origin__icontainsorigin) return queryset這里用ReadOnlyModelViewSet是因為茶品百科這類數(shù)據(jù)通常只讀由后臺運營錄入。社區(qū)的帖子、評論則用ModelViewSet再按操作做權限控制。接口路徑和功能對應關系大概如下方法路徑功能POST/api/auth/register用戶注冊POST/api/auth/login登錄換取 TokenGET/api/teas茶品列表支持篩選GET/api/teas/{id}茶品詳情GET/api/articles文章列表POST/api/posts發(fā)布帖子GET/api/posts/{id}帖子詳情POST/api/posts/{id}/comments發(fā)表評論POST/api/favorites收藏/取消收藏GET/api/users/{id}用戶主頁信息3.2 用戶認證、權限與通用的收藏/點贊接口用戶認證我直接用的djangorestframework-simplejwt它對比 Django 自帶的 session 認證更適合前后端分離的場景。配置也比較簡單核心就幾個參數(shù)from datetime import timedelta SIMPLE_JWT { ACCESS_TOKEN_LIFETIME: timedelta(minutes10), REFRESH_TOKEN_LIFETIME: timedelta(days7), ROTATE_REFRESH_TOKENS: True, }ROTATE_REFRESH_TOKENS我建議設成 True這樣前端每次用 refresh token 換 access token 時后端會同時返回一個新的 refresh token安全性更好。access token 有效期設短一點比如 10 到 15 分鐘減少 token 泄露后的風險窗口。權限控制方面我寫了一個自定義權限類確?！爸荒芫庉嬜约旱膬热荨眆rom rest_framework.permissions import BasePermission class IsOwnerOrReadOnly(BasePermission): def has_object_permission(self, request, view, obj): if request.method in [GET, HEAD, OPTIONS]: return True return obj.author request.user然后在帖子、評論、收藏這類模型視圖集里加上permission_classes [IsAuthenticatedOrReadOnly, IsOwnerOrReadOnly]。這里有個容易踩的坑如果你直接用ModelViewSet的destroy方法它會先走權限判斷但如果你重寫了perform_destroy或get_queryset一定要記得牽著權限走否則可能出現(xiàn)“知道自己不是作者但還是把別人的帖子刪了”這種詭異 bug。收藏和點贊這類操作我用的是一個通用接口。前端傳content_type和object_id后端先檢查是否已收藏已收藏就刪除未收藏就創(chuàng)建。這樣一個接口就能覆蓋茶品、文章、帖子所有內容類型。點贊我最初沒有單獨做因為收藏已經能滿足“標記喜歡”的需求后來用戶反饋想要“快速表達態(tài)度”才補了一個Like模型邏輯跟收藏幾乎一樣。3.3 搜索、分頁與統(tǒng)計字段的優(yōu)化搜索這塊一開始我先用 DRF 的SearchFilter在帖子標題和內容里做icontains模糊匹配。數(shù)據(jù)量小的時候沒問題但帖子量過千后響應時間明顯上升。后來切換到 PostgreSQL 全文搜索Django 里可以用SearchVector建一個生成列再用SearchQuery查詢。分頁我用的 DRFPageNumberPagination每頁默認 10 條。這里有個體驗細節(jié)給前端返回分頁信息時除了count之外我會把total_pages也一起返回省得前端自己去算。序列化器里加一個自定義字段class PaginatedResponse(serializers.Serializer): count serializers.IntegerField() total_pages serializers.IntegerField() current_page serializers.IntegerField() results serializers.ListField()統(tǒng)計字段的優(yōu)化更值得說view_count、like_count、comment_count這類數(shù)值不要每次都COUNT(*)查一次。我在模型里直接存冗余字段創(chuàng)建評論時用F()表達式更新計數(shù)from django.db.models import F Post.objects.filter(pkpost_id).update(comment_countF(comment_count) 1)F()表達式可以避免并發(fā)場景下的數(shù)據(jù)競爭比先查后改安全很多。4. Vue 3 前端模塊化搭建與關鍵組件落地4.1 組合式 API 的工程結構劃分前端項目的工程結構會影響后續(xù)所有功能的開發(fā)速度。我用的是 Vue 3 Vite Pinia Vue Router 4目錄大概這樣src/ api/ # 每個模塊的接口請求封裝 assets/ # 靜態(tài)資源 components/ # 通用組件 composables/ # 組合式函數(shù) router/ # 路由配置 stores/ # Pinia 狀態(tài) views/ # 頁面組件組合式函數(shù)composables是我覺得 Vue 3 最值得投入的地方。比如usePagination負責列表頁的分頁狀態(tài)和請求邏輯useUser負責用戶信息的獲取和更新。這樣頁面組件就變得很薄只關心怎么展示不關心數(shù)據(jù)怎么來。拿帖子列表頁舉例頁面組件大概是這個狀態(tài)script setup import { ref, onMounted } from vue; import { fetchPosts } from /api/post; import { usePagination } from /composables/usePagination; const { page, pageSize, total, data, loading, loadData } usePagination(fetchPosts); onMounted(() { loadData(); }); /script不過我要提醒一句組合式函數(shù)也不是越多越好過度抽象反而會讓代碼跳來跳去不好維護。我的經驗是一個邏輯如果只在一個頁面用就直接寫在頁面里被兩個以上頁面復用了再抽成 composable。4.2 茶品卡片、文章列表、富文本編輯器的組件化思路組件劃分我遵循的原則是“看它有沒有獨立的展示邏輯”。像茶品卡片這種在首頁、列表頁、搜索結果頁都會出現(xiàn)就必須獨立成組件而且數(shù)據(jù)格式要統(tǒng)一。茶品卡片組件我用了defineProps接收數(shù)據(jù)再通過defineEmits拋事件script setup defineProps({ tea: { type: Object, required: true, }, }); defineEmits([click]); /script template div classtea-card click$emit(click, tea.id) img :srctea.cover :alttea.name loadinglazy / h3{{ tea.name }}/h3 p{{ tea.origin }}/p span{{ tea.category_display }}/span /div /template圖片上加了loadinglazy這是很便宜的懶加載方案比引入額外組件庫更省事。文章列表我做了類似的文章卡片只是展示字段不同。富文本編輯器這塊我前端選的是 Quill用起來不復雜但后面聯(lián)調部分會細講它的安全問題。頁面路由用 Vue Router 實現(xiàn)需要注意路由懶加載const routes [ { path: /, name: Home, component: () import(/views/Home.vue), }, { path: /teas, name: TeaList, component: () import(/views/TeaList.vue), }, { path: /posts/:id, name: PostDetail, component: () import(/views/PostDetail.vue), }, ];懶加載看著是個小事情但對首屏加載速度影響很大。如果不做代碼分割用戶打開首頁就要把整個應用打包文件全下載下來移動端網(wǎng)絡差一點體驗就很糟。4.3 狀態(tài)持久化與請求封裝Pinia 狀態(tài)管理我分成了幾個 storeuserStore存用戶信息和登錄態(tài)appStore存主題設置、全局 loading 狀態(tài)。用戶登錄后Token 會同時寫入 localStorage刷新頁面后能直接恢復登錄狀態(tài)。參考實現(xiàn)如下export const useUserStore defineStore(user, { state: () ({ token: localStorage.getItem(access_token) || , userInfo: null, }), getters: { isLoggedIn: (state) !!state.token, }, actions: { setToken(token) { this.token token; localStorage.setItem(access_token, token); }, logout() { this.token ; localStorage.removeItem(access_token); localStorage.removeItem(refresh_token); }, }, });axios 封裝是另一個關鍵點。我在請求攔截器里統(tǒng)一加Authorization: Bearer token在響應攔截器里處理 401 和 token 刷新import axios from axios; import { useUserStore } from /stores/user; const http axios.create({ baseURL: import.meta.env.VITE_API_BASE, timeout: 15000, }); http.interceptors.request.use((config) { const userStore useUserStore(); if (userStore.token) { config.headers.Authorization Bearer ${userStore.token}; } return config; }); http.interceptors.response.use( (response) response, async (error) { if (error.response?.status 401) { const userStore useUserStore(); try { const refresh await axios.post(/api/auth/refresh, { refresh: localStorage.getItem(refresh_token), }); userStore.setToken(refresh.data.access); error.config.headers.Authorization Bearer ${refresh.data.access}; return http(error.config); } catch (refreshError) { userStore.logout(); window.location.href /login; } } return Promise.reject(error); } );這塊是前后端分離項目里最容易出錯的地方之一。初次實現(xiàn)的時候我用的是同步邏輯導致刷新 token 時多個請求同時 401重復刷新了好幾次。后來加了并發(fā)鎖用一個isRefreshing標記把所有 401 請求排隊刷新完成后再統(tǒng)一重放才算穩(wěn)定。5. 前后端聯(lián)調跨域、Token 刷新和富文本安全這些硬仗5.1 CORS 與 Token 刷新機制前后端聯(lián)調第一個坎就是跨域。前端開發(fā)服務器跑在localhost:5173后端在localhost:8000端口不同必然觸發(fā) CORS。Django 這邊我用的是django-cors-headers配置白名單時要注意別順手放開CORS_ALLOW_ALL_ORIGINS True生產環(huán)境這樣設置等于給爬蟲和惡意請求開了后門。我本地的配置長這樣CORS_ALLOWED_ORIGINS [ http://localhost:5173, http://127.0.0.1:5173, ]還有一個容易忽略的點如果你請求里帶了自定義 headers比如Authorization要確認CORS_ALLOW_HEADERS里有沒有包含它。django-cors-headers默認包含常見 headers但保險起見還是要自己核對一遍。Token 刷新機制我在前端已經寫好了攔截器這里補充一個后端細節(jié)simplejwt 的刷新接口如果你設置了ROTATE_REFRESH_TOKENS True第一次刷新后 refresh token 就作廢了。如果你前端代碼里同時有多個請求在刷新 token就會發(fā)生“第一個刷新成功第二個刷新拿著舊 token 報錯”的情況。所以前端一定要做刷新互斥不要讓兩個 401 同時進入刷新邏輯。5.2 富文本內容的安全清洗富文本編輯器是內容平臺逃不開的組件但它也是最容易埋雷的地方。用戶在編輯器里隨便粘貼一段帶腳本的 HTML一旦存儲時沒有任何處理發(fā)布出去就是存儲型 XSS。我用的 Quill 默認會過濾掉大部分腳本但出于安全考慮后端必須再做一次清洗。我的做法是在 Django 序列化器里加一層驗證函數(shù)用白名單方式保留常用標簽import re from rest_framework import serializers class ArticleSerializer(serializers.ModelSerializer): class Meta: model Article fields __all__ def validate_content(self, value): allowed_tags { p, br, strong, em, h1, h2, h3, ul, ol, li, blockquote, a, img, pre, code, } cleaned re.sub(r(?![/!?]?( |.join(allowed_tags) r)\b)[^]*, , value) cleaned re.sub(ron\w\s*\s*[\][^\]*[\], , cleaned) cleaned re.sub(rjavascript:, , cleaned) return cleaned這個清洗不是萬能的但它能擋住絕大多數(shù)由粘貼產生的危險 HTML。更嚴格的做法是引入專門的 HTML 清洗庫比如 Python 的bleach如果你對安全要求高建議直接用這個庫。5.3 圖片上傳的壓縮與校驗圖片上傳涉及前端壓縮、后端校驗、存儲方式三塊。前端我用的是compressorjs在用戶選擇圖片后先壓縮再上傳類型和大小都在前端卡一道import Compressor from compressorjs; function compressImage(file) { return new Promise((resolve, reject) { new Compressor(file, { quality: 0.7, maxWidth: 1200, maxHeight: 1200, success(result) { resolve(result); }, error(err) { reject(err); }, }); }); }后端在接收圖片時要校驗文件類型和大小不能信任前端的任何值。我寫了一個工具函數(shù)import imghdr from rest_framework.exceptions import ValidationError def validate_image(file): allowed_types {jpeg, png, gif, webp} file_type imghdr.what(file) if file_type not in allowed_types: raise ValidationError(僅支持 jpeg/png/gif/webp 格式的圖片) if file.size 5 * 1024 * 1024: raise ValidationError(圖片大小不能超過 5MB)存儲方面開發(fā)環(huán)境我直接存在本地的media/目錄部署到生產后換成了對象存儲并掛 CDN。Django 配置對象存儲很方便只需要改DEFAULT_FILE_STORAGE和對應的 bucket 配置業(yè)務代碼不用動。6. 部署上線與性能實測別等上線再調優(yōu)6.1 Docker Compose 編排服務部署我用的 Docker Compose一共編排了四個服務前端 Nginx、后端 Django Gunicorn、PostgreSQL、Nginx 反向代理也可以把前端和反向代理合并到同一個 Nginx。這里我建議前端靜態(tài)文件服務和后端反向代理分開后續(xù)調整轉發(fā)規(guī)則更方便。services: db: image: postgres:15 environment: POSTGRES_DB: tea_platform POSTGRES_USER: tea_user POSTGRES_PASSWORD: secret volumes: - pgdata:/var/lib/postgresql/data backend: build: ./backend command: gunicorn config.wsgi:application --bind 0.0.0.0:8000 --workers 3 volumes: - static_volume:/app/staticfiles - media_volume:/app/media depends_on: - db frontend: build: ./frontend volumes: - static_volume:/usr/share/nginx/html ports: - 80:80 depends_on: - backendGunicorn 的 worker 數(shù)量我直接用了 3因為這臺部署服務器的 CPU 是 2 核。公式大概就是2 * CPU核心數(shù) 1可以根據(jù)你的機器配置調整。worker 開太多反而會增加內存壓力尤其 Django 每個 worker 都會加載完整的應用代碼。6.2 Nginx 托管前端與反向代理Nginx 配置文件里最關鍵的是兩件事一是靜態(tài)文件緩存二是 API 反向代理加 gzip。前端構建產物是純靜態(tài)資源可以設置較長緩存時間但index.html不要緩存否則用戶每次發(fā)布新版本后還要強制刷新才能看到。server { listen 80; server_name _; root /usr/share/nginx/html; index index.html; location /api/ { proxy_pass http://backend:8000; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; gzip on; gzip_types text/plain application/json text/css application/javascript; } location /static/ { alias /app/staticfiles/; expires 7d; } location /media/ { alias /app/media/; expires 30d; } location / { try_files $uri $uri/ /index.html; } }try_files $uri $uri/ /index.html;這行是 Vue Router 的 history 模式必須的否則你點擊頁面跳轉后刷新就會 404。如果你用的 hash 模式可以少配這一行但 URL 里會多個#不美觀我建議直接上 history 模式。6.3 數(shù)據(jù)庫與 API 的慢查詢優(yōu)化上線前的壓測我用的是簡單的ab命令模擬 200 個并發(fā)請求打首頁和帖子列表頁。結果發(fā)現(xiàn)帖子列表接口響應時間從 80ms 漲到了 1.2s定位發(fā)現(xiàn)是因為查詢評論數(shù)時做了 N1 查詢。優(yōu)化方案是用annotate一次性把評論數(shù)、點贊數(shù)查出來from django.db.models import Count from .models import Post posts Post.objects.annotate( comment_countCount(comments), like_countCount(likes), ).select_related(author).order_by(-last_replied_at)select_related處理的是外鍵字段一對一、多對一把author提前查出來避免每條帖子都查一次用戶表。多對多或一對多的統(tǒng)計用annotate配合Count一次算完。這兩個是 Django 查詢優(yōu)化的核心也是慢查詢最常見的解藥。另外我把數(shù)據(jù)庫連接數(shù)設置成了CONN_MAX_AGE 60讓連接在進程內持久化減少了反復握手的時間。對 PostgreSQL 這種數(shù)據(jù)庫連接復用能顯著降低請求延遲。6.4 上線后的日常維護清單上線不是終點反而是一系列維護工作的開始。我給自己列了一個日常清單每天看一次 Nginx 錯誤日志和 Django 日志重點查 5xx 和慢請求。數(shù)據(jù)庫自動備份我用的 cron 每天凌晨導出 PostgreSQL保留最近 7 天。監(jiān)控磁盤空間尤其media/目錄會漲得很快用戶大量傳圖片容易爆盤。檢查 Django Admin 的操作記錄防止運營誤刪數(shù)據(jù)。每周看一次數(shù)據(jù)庫慢查詢日志結合訪問量判斷是否需要加索引。這些維護動作都不復雜但遺漏任何一項都可能讓線上服務出現(xiàn)“小事變大事”的故障。比如磁盤爆滿表面是圖片傳不上去實際是服務器上日志和臨時文件堆積太多。提前設好監(jiān)控比事后救火舒服得多。我之前在項目里加了一個簡單的健康檢查接口Django 返回數(shù)據(jù)庫連接狀態(tài)和磁盤剩余空間交給外部監(jiān)控定時拉取。這樣一個輕量接口能幫你提前發(fā)現(xiàn)大部分即將到來的故障。最后說幾點個人體會這個項目從需求梳理到上線實際用了大概四周中間有兩次差點改架構后來都穩(wěn)住了。第一次是收藏功能想用 ContentType擔心復雜度太高實際做下來發(fā)現(xiàn)反而節(jié)約了大量重復代碼第二次是富文本 XSS 清洗一開始想依賴前端編輯器過濾后來想明白一個核心道理前端過濾只是用戶體驗后端過濾才是安全底線。我做這類平臺最深的體會是技術選型最好不要追新而是要跟著業(yè)務形態(tài)走。茶文化交流平臺的內容屬性和社區(qū)屬性決定了它不需要極致的實時性也不需要在首頁塞太多動態(tài)效果穩(wěn)定、可維護、內容可沉淀才是重點。Vue 3 Django 這組搭配恰好把前端開發(fā)體驗和后端管理效率都照顧到了對小團隊和個人開發(fā)者來說性價比很高。如果你也在做類似的興趣社區(qū)或內容平臺給你一個具體建議第一版上線千萬不要做全功能先把“用戶注冊 - 瀏覽內容 - 發(fā)帖評論 - 收藏點贊”這條主鏈路打通跑通之后再考慮活動、關注、推薦這些增量功能。等平臺有真實用戶了你會發(fā)現(xiàn)用戶反饋會幫你做決定而不是靠產品經理猜需求。