## 1. Django与Vue前后端分离的核心架构设计 前后端分离不是简单地把HTML扔进Django模板目录，而是一次职责重构：Django专注数据建模、权限控制、业务逻辑和API服务，Vue专注用户交互、状态管理、路由跳转和视觉呈现。我最早在2020年接手一个内部管理系统时踩过坑——当时把Vue组件直接写在Django模板里用`<script>`标签引入，结果调试时发现Vue的响应式更新总被Django的CSRF中间件干扰，热重载失效，接口报403，查了三天才定位到是`csrf_token`模板变量和Vue的`v-model`在DOM渲染顺序上打架。后来彻底拆开，后端只返回JSON，前端完全接管页面生命周期，整个开发节奏立刻顺畅起来。 这种架构下，两个系统本质上是“松耦合+强契约”：松耦合体现在部署可独立伸缩——Vue静态资源可以托管在CDN，Django API可以横向扩机器；强契约则体现在接口规范必须严格约定。比如我们团队现在强制要求所有API路径以`/api/v1/`开头，状态码遵循REST标准（200成功、201创建、400参数错、401未登录、403无权限、404不存在、500服务器错误），响应体统一为`{"code": 0, "msg": "ok", "data": {...}}`结构，前端axios拦截器自动处理code非0的情况，弹Toast或跳登录页。这个契约一旦定下，前后端就能并行开发，Vue组用Mock.js模拟API，Django组专注数据库事务和缓存策略，上线前一周联调，效率提升非常明显。 实际项目中，我建议把Vue项目作为Django项目的子模块管理，而不是完全独立仓库。比如Django根目录下建`frontend/`文件夹，里面放Vue CLI工程。这样做的好处是：CI/CD流程清晰——打包脚本可以直接读取Django的`.env`获取API_BASE_URL；版本回滚一致——Git提交记录里能同时看到前端改动和对应后端API变更；权限收敛——运维只需维护一套部署权限。当然，如果团队规模大、前端要复用到多个后端系统，那再拆成独立仓库也不迟，但初期真没必要增加协作成本。 ## 2. Vue构建产物与Django静态资源协同方案 Vue CLI执行`npm run build`后生成的`dist/`目录，本质是一组纯静态文件：`index.html`是唯一入口，`js/`和`css/`文件带hash命名防缓存，`img/`存放图片资源。Django要托管这些内容，关键在于让`index.html`能被Django路由识别，同时确保其他静态资源路径正确解析。很多人卡在这一步，以为只要把`dist/`拷进`STATIC_ROOT`就行，结果访问`/`返回404——因为Django默认不把`index.html`当模板处理，它只认`TEMPLATES['DIRS']`里声明的路径下的HTML文件。 正确的做法分三步走。第一步，在`settings.py`里配置模板路径： ```python import os from pathlib import Path BASE_DIR = Path(__file__).resolve().parent.parent.parent # 注意：这里要向上穿透到项目根目录 FRONTEND_DIR = BASE_DIR / 'frontend' / 'dist' TEMPLATES = [ { 'BACKEND': 'django.template.backends.django.DjangoTemplates', 'DIRS': [FRONTEND_DIR], # 关键：告诉Django这里放着前端入口页 'APP_DIRS': True, 'OPTIONS': { 'context_processors': [ 'django.template.context_processors.debug', 'django.template.context_processors.request', 'django.contrib.auth.context_processors.auth', 'django.contrib.messages.context_processors.messages', ], }, }, ] ``` 第二步，写一个通用视图来返回`index.html`： ```python # views.py from django.shortcuts import render from django.views.generic import TemplateView class FrontendAppView(TemplateView): template_name = 'index.html' # 自动从TEMPLATES['DIRS']里查找 # urls.py from django.urls import path, re_path from . import views urlpatterns = [ # API路由 path('api/v1/', include('api.urls')), # 前端路由兜底：除了/api/开头的路径，其他都交给Vue Router处理 re_path(r'^(?:.*)/?$', views.FrontendAppView.as_view()), ] ``` 第三步，处理静态资源路径。Vue默认打包的`index.html`里引用的是`/js/app.xxx.js`这样的绝对路径，但Django的`STATIC_URL`可能是`/static/`，这就导致404。解决方案是在Vue项目根目录的`vue.config.js`里配置： ```javascript module.exports = { publicPath: process.env.NODE_ENV === 'production' ? '/static/' : '/', outputDir: 'dist', assetsDir: 'static', } ``` 这样打包后`index.html`里的script标签就变成`<script src="/static/js/app.xxx.js">`，而Django的`STATIC_URL = '/static/'`正好匹配。最后别忘了在`settings.py`里把`frontend/dist/static/`加入`STATICFILES_DIRS`： ```python STATICFILES_DIRS = [ FRONTEND_DIR / 'static', # 指向dist/static目录 ] ``` 实测下来，这套方案在Docker容器化部署时特别稳——Nginx负责反向代理`/api/`到Django，其他请求直接返回`dist/`下的文件，零Node.js运行时，内存占用比跑Vue DevServer低80%。 ## 3. Django REST Framework与Vue的数据通信实践 Django REST Framework（DRF）不是给Django加个REST功能，而是提供了一套完整的API开发范式。我见过太多人用`@api_view`写一堆函数视图，结果权限校验、分页、过滤、序列化全靠手写，三个月后代码像毛线团。DRF的价值在于把重复劳动标准化：`ModelViewSet`自动生成CRUD，`Serializer`统一字段校验和序列化逻辑，`Permission`类集中管理访问控制。 举个真实例子：一个商品列表接口，需要支持按分类筛选、价格区间搜索、分页排序。用DRF实现只需要三步。第一步，定义序列化器： ```python # serializers.py from rest_framework import serializers from .models import Product class ProductListSerializer(serializers.ModelSerializer): class Meta: model = Product fields = ['id', 'name', 'price', 'category_name', 'cover_url'] ``` 第二步，写视图集： ```python # views.py from rest_framework import viewsets, filters from django_filters.rest_framework import DjangoFilterBackend from .models import Product from .serializers import ProductListSerializer class ProductViewSet(viewsets.ReadOnlyModelViewSet): queryset = Product.objects.select_related('category').all() serializer_class = ProductListSerializer filter_backends = [DjangoFilterBackend, filters.OrderingFilter] filterset_fields = ['category', 'price'] # 自动生成?category=1&price__gte=100 ordering_fields = ['price', 'created_at'] ordering = ['-created_at'] # 默认按创建时间倒序 ``` 第三步，配置路由： ```python # urls.py from rest_framework.routers import DefaultRouter from . import views router = DefaultRouter() router.register(r'products', views.ProductViewSet) urlpatterns = [ path('api/v1/', include(router.urls)), ] ``` 前端Vue这边，我习惯用Pinia做状态管理，封装一个`useProductStore`： ```javascript // stores/product.js import { defineStore } from 'pinia' import axios from '@/utils/request' // 封装了baseURL和token自动注入 export const useProductStore = defineStore('product', { state: () => ({ list: [], loading: false, pagination: { page: 1, page_size: 20, total: 0 } }), actions: { async fetchList(params = {}) { this.loading = true try { const res = await axios.get('/api/v1/products/', { params }) this.list = res.data.results this.pagination = { page: res.data.page, page_size: res.data.page_size, total: res.data.count } } finally { this.loading = false } } } }) ``` 关键细节在于：DRF默认分页返回`{"count": 120, "next": "...", "previous": "...", "results": [...]}`，所以前端要适配`res.data.results`；而Vue的`<el-table>`绑定`list`数组，分页组件监听`pagination`对象，数据流非常干净。另外，我坚持在Django侧做字段级权限控制——比如`is_vip_only`字段只对VIP用户返回，而不是前端判断`v-if="user.isVip"`，因为后者可能被开发者工具绕过，安全边界必须守在后端。 ## 4. 跨域、路由与生产环境部署的完整链路 开发阶段跨域问题最常见，但很多人只记得装`django-cors-headers`，却忽略了一个致命细节：**CORS配置必须放在Django中间件列表的靠前位置**。我曾经在某个项目里把`CorsMiddleware`加在`SessionMiddleware`后面，结果登录态丢失——因为CORS预检请求（OPTIONS）没经过Session中间件，导致后续请求拿不到sessionid。正确顺序应该是： ```python MIDDLEWARE = [ 'corsheaders.middleware.CorsMiddleware', # 必须在SessionMiddleware之前 'django.middleware.security.SecurityMiddleware', 'django.contrib.sessions.middleware.SessionMiddleware', 'django.middleware.common.CommonMiddleware', # ... 其他中间件 ] ``` 开发期设`CORS_ORIGIN_ALLOW_ALL = True`没问题，但上线前必须切到白名单模式： ```python CORS_ALLOWED_ORIGINS = [ 'https://your-company.com', 'https://admin.your-company.com', ] # 如果前端用IP+端口调试，可以临时加 if DEBUG: CORS_ALLOWED_ORIGINS += ['http://localhost:8080', 'http://127.0.0.1:8080'] ``` Vue Router历史模式在生产环境需要Web服务器配合。Nginx配置示例： ```nginx location / { try_files $uri $uri/ /index.html; } # 但注意：API请求不能被重写！ location /api/ { proxy_pass http://django_backend; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } ``` 这段配置的意思是：所有请求先尝试找真实文件（如`/static/js/app.js`），找不到就回退到`/index.html`，这样Vue Router才能捕获路径做前端路由。但`/api/`开头的请求必须明确代理到Django，否则会变成前端自己发请求又回到`index.html`，造成死循环。 最后是部署流程。我推荐用Docker Compose一体化部署： ```yaml # docker-compose.yml version: '3.8' services: django: build: . command: gunicorn myproject.wsgi:application --bind 0.0.0.0:8000 volumes: - ./media:/app/media depends_on: - db nginx: image: nginx:alpine ports: - "80:80" volumes: - ./nginx.conf:/etc/nginx/nginx.conf - ./frontend/dist:/usr/share/nginx/html depends_on: - django db: image: postgres:13 environment: POSTGRES_DB: myproject ``` 每次上线，前端执行`npm run build`生成新`dist/`，后端执行`docker-compose up -d --build`，Nginx自动加载新静态文件，Django重启生效。整个过程5分钟内完成，回滚也只需`docker-compose logs django`看错误日志，比以前手动scp文件靠谱多了。 我在实际使用中发现，这套方案最大的收益不是技术多炫酷，而是让前后端同学能真正聚焦在各自领域：前端研究怎么用Composition API写更优雅的组件，后端琢磨怎么用数据库索引优化慢查询。当大家不再为“为什么我的接口404”、“为什么你的CSS没加载”扯皮时，项目质量自然就上去了。