基于Vue+Django+Flask的校园兼职系统设计与实现详解

前前后后做了好几个类似的校园业务系统说实话校园兼职这个方向算是信息管理系统里比较典型的实战练手项目。前后端分离、权限控制、发布报名流程、列表检索各个模块一应俱全特别适合拿来验证 Vue 和 Python 这套技术栈的配合能力。这个项目标题写的是“基于 Vue 的校园兼职系统的设计与实现 Python django flask”我相信很多人看到这里会有同感这压根不是二选一的问题而是需要在 Django 和 Flask 之间做一个合理取舍再配合 Vue 把前后端串起来。这篇文章就把我完整做下来的过程、踩过的坑、以及最终沉淀下来的方案拆开讲清楚给正准备做类似系统的同学一条尽可能顺的路径。1. 整体设计与技术选型解析1.1 技术栈选择的底层逻辑先说结论这个项目最终我选择了Django Django REST Framework 作为后端主体Flask 作为轻量级辅助服务。标题里同时出现 Django 和 Flask看着像二选一实际做的时候完全可以两条腿走路。你要是自己去搜“Django 还是 Flask”看到的无非是那句话Django 是大而全的框架Flask 是微框架。但真正动手做校园兼职系统之前你得先搞清楚这两者的差异到底落在什么具体能力上。对比项DjangoFlaskORM内置完整 ORM迁移脚本自动生成默认无 ORM常配 SQLAlchemyAdmin 后台自带 Admin 界面管理数据超方便需要自己写后台逻辑认证体系自带用户模型配合扩展实现 JWT需要完全自己搭开发速度适合 CRUD 密集型的业务系统适合原型验证和高自由度接口学习曲线稍陡但套路统一平坦但后续功能要自己堆我之前有个很直接的感受校园兼职系统的核心就是用户、兼职信息、报名记录这三张表的增删改查外加状态流转的管理逻辑。这种业务如果用 Flask 硬写每个接口都要自己写数据库查询、序列化、参数校验一个列表页就能写出一堆重复代码。而 Django 的 ORM 和 DRFDjango REST Framework几乎就是为这种业务量身定做的。那 Flask 在这个项目里有没有位置有。我把系统中的信息推送和定时任务拆成了一个独立的 Flask 服务比如每天晚上做一遍兼职信息过期自动下架、给学生推送报名状态变更提醒。Flask 启动快、干净单独跑这类轻量服务很舒服。1.2 前后端分离架构与项目结构规划既然前端选了 Vue那就必须走前后端分离的路子。后端不再返回 HTML 页面只提供 JSON 接口前端通过 Axios 请求这些接口在浏览器里渲染页面。这样做的直接好处是前端开发和后端开发可以完全并行你后端还没写完接口前端已经可以用 Mock 数据把页面画出来了。实际项目目录结构我是这么组织的campus-parttime-system/ ├── backend/ # Django 后端 │ ├── manage.py │ ├── config/ # 配置目录settings、urls、wsgi │ ├── apps/ │ │ ├── users/ # 用户模块 │ │ ├── jobs/ # 兼职信息模块 │ │ └── applications/ # 报名与收藏模块 │ └── requirements.txt ├── notify-server/ # Flask 轻量服务 │ ├── app.py │ └── tasks.py └── frontend/ # Vue 前端 ├── src/ │ ├── api/ # 接口请求封装 │ ├── router/ # 路由配置 │ ├── views/ # 页面组件 │ └── store/ # 状态管理 └── package.jsonDjango 里我把业务拆成了users、jobs、applications三个 app每个 app 只负责自己那一摊事。一开始你可能觉得这样拆麻烦但等代码量上来以后就会发现每个模块的 models、serializers、views 各归各的改一个模块完全不影响另一个排查问题的时候定位也快。1.3 数据库设计与核心表结构数据库设计这块我直接用了 MySQL但开发阶段建议先用 SQLite 顶着。原因很简单SQLite 零配置创建数据库就是本地文件Django 默认就能跑等系统上线再切换到 MySQL只需要改 settings.py 里的数据库配置然后跑一次迁移就行。核心表结构有四张用户表users_user字段类型说明idint主键student_idvarchar(20)学号唯一usernamevarchar(50)用户名passwordvarchar(128)密码哈希值phonevarchar(11)手机号rolevarchar(10)角色student / admin兼职信息表jobs_job字段类型说明idint主键titlevarchar(100)兼职标题descriptiontext兼职描述salarydecimal(10,2)薪资locationvarchar(100)工作地点work_timevarchar(100)工作时间段publisherint发布人外键statusvarchar(10)published / closed / pendingcreated_atdatetime发布时间报名记录表applications_application字段类型说明idint主键userint报名学生外键jobint兼职外键statusvarchar(10)applied / accepted / rejectedapply_timedatetime报名时间收藏表applications_favorite字段类型说明idint主键userint用户外键jobint兼职外键created_atdatetime收藏时间设计时的关键约束点报名记录要把user和job组合起来设置为唯一约束确保同一个学生不能对同一条兼职信息重复报名。2. 后端接口开发与核心逻辑实现2.1 Django 项目初始化和模型创建搭环境这一步虽然基础但值得认真走一遍。我习惯用虚拟环境隔离依赖避免不同项目相互污染。# 创建虚拟环境 python -m venv venv # 激活虚拟环境Windows venv\Scripts\activate # 激活虚拟环境macOS / Linux source venv/bin/activate # 安装核心依赖 pip install django djangorestframework django-cors-headers djangorestframework-simplejwt mysqlclient # 创建项目与模块 django-admin startproject config . python manage.py startapp users python manage.py startapp jobs python manage.py startapp applications模型创建这块用户表我直接继承了 Django 自带的AbstractUser这样省去了自己写密码加密和权限验证的麻烦# apps/users/models.py from django.contrib.auth.models import AbstractUser from django.db import models class User(AbstractUser): student_id models.CharField(max_length20, uniqueTrue, verbose_name学号) phone models.CharField(max_length11, verbose_name手机号) role models.CharField( max_length10, choices[(student, 学生), (admin, 管理员)], defaultstudent, verbose_name角色, ) class Meta: db_table users_user def __str__(self): return self.username兼职信息模型的核心在于状态字段。发布、下架、审核中这三个状态决定了列表页展示哪些数据# apps/jobs/models.py from django.db import models from apps.users.models import User class Job(models.Model): STATUS_CHOICES [ (published, 已发布), (pending, 待审核), (closed, 已下架), ] title models.CharField(max_length100, verbose_name兼职标题) description models.TextField(verbose_name兼职描述) salary models.DecimalField(max_digits10, decimal_places2, verbose_name薪资) location models.CharField(max_length100, verbose_name工作地点) work_time models.CharField(max_length100, verbose_name工作时间) publisher models.ForeignKey(User, on_deletemodels.CASCADE, verbose_name发布人) status models.CharField(max_length10, choicesSTATUS_CHOICES, defaultpending) created_at models.DateTimeField(auto_now_addTrue, verbose_name发布时间) class Meta: db_table jobs_job ordering [-created_at]这里有个小设计发布兼职时默认走pending待审核状态管理员审核通过后自动变成published前端列表页只请求published的数据。这么做是防刷校园场景下保不齐有人乱发内容审核环节不能省。2.2 认证体系与 JWT 鉴权校园兼职系统涉及学生个人信息登录认证是刚需。我没有用 Django 默认的 session 认证因为前后端分离的项目里前端是静态站点session 这套 Cookie 机制通信起来很别扭。最终选了 JWT无状态、能跨域、前端存 Token 也方便。配置起来其实很清爽# config/settings.py 关键配置 INSTALLED_APPS [ # ... 其他应用 rest_framework, rest_framework_simplejwt, corsheaders, ] MIDDLEWARE [ # ... 其他中间件 corsheaders.middleware.CorsMiddleware, ] # 允许跨域 CORS_ALLOW_ALL_ORIGINS True # DRF 配置 REST_FRAMEWORK { DEFAULT_AUTHENTICATION_CLASSES: [ rest_framework_simplejwt.authentication.JWTAuthentication, ], DEFAULT_PERMISSION_CLASSES: [ rest_framework.permissions.IsAuthenticatedOrReadOnly, ], }这里注意中间件顺序CorsMiddleware要尽量往上放放在CommonMiddleware前面不然跨域预检请求可能会被拦掉这个坑我踩过后面问题排查小节细说。登录接口用 simplejwt 自带的TokenObtainPairView就能直接跑# apps/users/urls.py from django.urls import path from rest_framework_simplejwt.views import TokenObtainPairView, TokenRefreshView urlpatterns [ path(login/, TokenObtainPairView.as_view(), namelogin), path(refresh/, TokenRefreshView.as_view(), namerefresh), ]前端每次请求都在 Header 带上Authorization: Bearer token后端拿到 Token 后解析出用户 ID再通过request.user识别当前是谁在操作。2.3 兼职信息核心接口发布、列表与检索兼职信息的 CRUD 是整个系统最核心的接口组。我把发布、列表、检索三个需求合并到了一个视图里用 DRF 的ListCreateAPIView处理。# apps/jobs/views.py from rest_framework import generics from rest_framework.permissions import IsAuthenticated, IsAuthenticatedOrReadOnly from .models import Job from .serializers import JobSerializer class JobListView(generics.ListCreateAPIView): queryset Job.objects.all() serializer_class JobSerializer permission_classes [IsAuthenticatedOrReadOnly] def get_queryset(self): keyword self.request.query_params.get(keyword, ) sort_by self.request.query_params.get(sort, -created_at) queryset Job.objects.filter(statuspublished) if keyword: queryset queryset.filter(title__icontainskeyword) # 排序白名单校验 allowed_sorts [-created_at, salary, -salary] if sort_by in allowed_sorts: queryset queryset.order_by(sort_by) return queryset def perform_create(self, serializer): # 发布人自动取当前登录用户 serializer.save(publisherself.request.user, statuspending)列表接口一段代码同时搞定了查询全部、关键词检索、排序、分页分页配置在 settings 里发布接口还自动把 status 置为待审核。这里最关键的一手是排序白名单。直接把前端传的 sort 参数塞进order_by会造成任意字段排序虽然不至于拖库但属于潜在安全隐患白名单校验成本低顺手就做了。分页配置也很简单# config/settings.py REST_FRAMEWORK { # ... 其他配置 DEFAULT_PAGINATION_CLASS: rest_framework.pagination.PageNumberPagination, PAGE_SIZE: 10, }一页十条前端滚动翻页体验正好。2.4 报名与收藏的业务闭环报名这个动作看似简单但需求细节多同一个学生不能重复报名同一兼职、报名后兼职的报名数要更新、兼职发布者登录自己的报名列表看有哪些学生、学生能取消报名。# apps/applications/views.py from rest_framework.views import APIView from rest_framework.response import Response from rest_framework.permissions import IsAuthenticated from .models import Application from apps.jobs.models import Job class ApplyJobView(APIView): permission_classes [IsAuthenticated] def post(self, request): job_id request.data.get(job_id) try: job Job.objects.get(idjob_id, statuspublished) except Job.DoesNotExist: return Response({detail: 兼职不存在或已下架}, status400) # 防止重复报名 if Application.objects.filter(userrequest.user, jobjob).exists(): return Response({detail: 你已经报名过这条兼职了}, status400) Application.objects.create(userrequest.user, jobjob) return Response({detail: 报名成功}, status201)像这种需要做多个判断才能完成的操作我用APIView自己写逻辑比 DRF 自动视图更清晰。实际做下来报名成功之后给兼职发布者发通知这一步我是交给后面的 Flask 服务异步处理的主 Django 进程里不阻塞请求响应速度不受影响。3. 前端 Vue 工程搭建与核心页面实现3.1 Vue 环境配置与依赖安装前端环境配置看似简单其实是很多新手卡壳的第一道坎。Node.js 版本太老或者 npm 源太慢都能让整个工程起不来。实测下来 Node 建议 16 以上我用的是 18.19.0全程没遇到版本兼容问题。# 检查 Node 版本 node -v # 使用 Vite 创建 Vue 3 项目比 vue-cli 快太多 npm create vitelatest frontend -- --template vue # 进入项目目录安装依赖 cd frontend npm install # 安装路由、状态管理、UI 库和 HTTP 库 npm install vue-router4 pinia axios element-plus这里重点说下为什么选了 Vite 而不是 vue-cli。Vite 基于 ESModule冷启动速度比 Webpack 快了不是一点点开发阶段改代码热更新几乎是秒级。对校园项目这种需要反复调整页面细节的场景来讲开发体验提升非常明显。Element Plus 这个东西你要不装也行自己手写样式也完全能实现一样的页面。但从零到一把表单项、弹窗、分页、表格全部手搓一遍项目周期会拉得很难看所以我直接用现成组件库把精力花在业务逻辑上。3.2 Axios 请求封装与路由守卫前端所有接口请求都走同一个 Axios 实例这是降低重复代码量的好办法。我更看重的是在拦截器里统一处理 Token 注入和错误提示// src/api/request.js import axios from axios import { ElMessage } from element-plus import router from /router const request axios.create({ baseURL: /api, timeout: 10000, }) // 请求拦截自动携带 Token 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 { const status error.response?.status if (status 401) { localStorage.removeItem(token) router.push(/login) } else if (status 400) { ElMessage.error(error.response.data.detail || 请求参数有误) } else { ElMessage.error(服务器开小差了请稍后再试) } return Promise.reject(error) } ) export default request这个封装的好处是业务组件里不用每次写一遍 Token 注入和错误处理。Token 失效跳转登录页这种事前端用户是无感知的拦截器里统一判断好比每个页面单独判断简洁得多。路由守卫的逻辑也是同样道理页面访问前先判断该路由需不需要登录态// src/router/index.js router.beforeEach((to, from, next) { const token localStorage.getItem(token) if (to.meta.requiresAuth !token) { next({ path: /login, query: { redirect: to.fullPath } }) } else { next() } })3.3 核心页面实现要点列表、发布、个人中心前端页面我做下来最费心思的是兼职列表页。它要在同一个页面里同时支持关键词搜索、按薪资排序、分页加载并且每条信息要展示标题、薪资、地点、状态这几个关键字段。!-- src/views/JobList.vue 核心模板 -- template div classjob-list div classfilter-bar el-input v-modelkeyword placeholder搜索兼职关键词 clearable keyup.enterfetchJobs(1) / el-select v-modelsortBy changefetchJobs(1) el-option label最新发布 value-created_at / el-option label薪资最高 value-salary / /el-select el-button typeprimary clickfetchJobs(1)搜索/el-button /div el-table :datajobs v-loadingloading el-table-column proptitle label兼职标题 min-width200 / el-table-column propsalary label薪资(元) width120 / el-table-column proplocation label地点 width150 / el-table-column label操作 width200 template #default{ row } el-button typeprimary link clickgoDetail(row.id)详情/el-button el-button typesuccess link clickapplyJob(row.id)报名/el-button /template /el-table-column /el-table el-pagination layoutprev, pager, next :totaltotal :page-sizepageSize current-changefetchJobs / /div /template对应的数据请求逻辑const fetchJobs async (page 1) { loading.value true try { const res await request.get(/jobs/, { params: { keyword: keyword.value, sort: sortBy.value, page }, }) jobs.value res.results total.value res.count } finally { loading.value false } }发布页的关键在于表单校验。兼职标题不能为空、薪资必须大于零、工作地点不能太宽泛这些前端校验可以在用户填错的时候立刻提醒减少后端接口被无效请求打到的次数。Element Plus 的表单校验规则非常好用const rules { title: [ { required: true, message: 请输入兼职标题, trigger: blur }, { min: 5, max: 50, message: 标题长度在 5 到 50 个字符, trigger: blur }, ], salary: [ { required: true, message: 请输入薪资, trigger: blur }, { validator: (rule, value, callback) value 0 ? callback() : callback(new Error(薪资必须大于0)), trigger: blur }, ], }个人中心页相对简单展示当前登录用户的信息外加两个 Tab我报名的兼职、我发布的兼职如果是管理员还要加上审核入口。后边那个“待审核”列表是管理员才有的操作普通学生看不到用一个role admin的判断就可以控制。4. 前后端联调与常见问题排查4.1 跨域配置与接口调试技巧前后端分离项目联调时最常撞见的不是业务 bug而是跨域问题。浏览器帮你把请求拦在了门外前端控制台一片红色报错后端接口单独用 Postman 测又是好的这就非常让人困惑。Django 端加上django-cors-headers之后还需要确认中间件顺序正确MIDDLEWARE [ corsheaders.middleware.CorsMiddleware, # 放在最上面 django.middleware.common.CommonMiddleware, # ... 其他中间件 ] CORS_ALLOW_ALL_ORIGINS True # 开发阶段用上线要换成具体域名这里有个非常容易踩的坑中间件顺序不对跨域请求直接 404。CorsMiddleware 必须放在 CommonMiddleware 之前浏览器发送预检请求 OPTIONS 时才能被正确处理。我第一次没注意顺序排错排了一下午。联调的时候我用的是 Vite 的代理把/api开头的请求转发到 Django 监听的 8000 端口这样浏览器里看到的还是同源请求开发阶段跨域问题直接被规避了。// vite.config.js export default defineConfig({ server: { proxy: { /api: { target: http://127.0.0.1:8000, changeOrigin: true, }, }, }, })上线阶段直接把前端构建产物交给 NginxNginx 再根据/api前缀把请求转发给后端前端代码里还是那套/api开头的请求不用做任何改动。4.2 高频报错排查记录做完整套系统我把遇到的典型问题整理成了一张速查表很多问题都是在不同项目里反复出现的类型。症状可能原因解决方案前端请求一直 401Token 没传或者过期检查 Axios 拦截器确认请求头里带了 Authorization过期则走刷新接口接口返回 403没有权限检查视图的 permission_classes确认登录用户有访问权限跨域预检请求 404中间件顺序错误把 CorsMiddleware 移到 CommonMiddleware 之前创建账号时密码明文存储没使用 Django 加密用 create_user 而非 create 创建用户时间显示差了 8 小时时区配置问题settings.py 设置 TIME_ZONE Asia/Shanghai前端拿到数据渲染不出表格字段名不对用 console.log 打印接口返回值核对外键序列化字段名其中时间显示这个问题尤其常见。Django 默认时区是 UTC数据库里存的时间是带时区的 UTC 时间前端显示出来就比本地时间少了 8 小时。最终我直接在 settings.py 里统一TIME_ZONE Asia/Shanghai USE_TZ True后端序列化返回的就是东八区时间前端不用再做时间格式转换直接显示字符串就行。4.3 Flask 辅助服务与部署经验Flask 服务在这套系统里负责跑定期任务。比如每天晚上 12 点自动把过期兼职的状态改成closed再比如报名状态变更后给学生推送站内信提醒。这类任务用 Django 也能写但 Django 的启动本身就重单独写一个 Flask 脚本定时执行会更轻巧。# notify-server/tasks.py import requests from apscheduler.schedulers.blocking import BlockingScheduler scheduler BlockingScheduler() def close_expired_jobs(): # 调用 Django 提供的管理接口 requests.post(http://127.0.0.1:8000/api/admin/close-expired-jobs/) def send_remind(): # 推送报名状态提醒 requests.post(http://127.0.0.1:8000/api/notify/push/) scheduler.add_job(close_expired_jobs, cron, hour0, minute0) scheduler.add_job(send_remind, cron, hour9, minute0) scheduler.start()这里要注意Flask 服务和 Django 服务是通过 HTTP 接口通信的所以 Django 那些管理接口得设置成只能用内部 Token 调用防止被外部攻击。我用的是简单的X-Internal-Token请求头做校验请求方带着固定 Token服务端验证通过才执行。部署方面我的最终方案是Django 用 Gunicorn 跑4 个 worker监听 8000 端口Flask 用nohup python tasks.py 常驻后台Vue 构建产物npm run build后丢到 Nginx 的 html 目录Nginx 配置里把/api反向代理到 Django 的 8000 端口静态资源直接走 Nginx上线前务必把 Debug 关掉ALLOWED_HOSTS 配置成真实域名不然 Django 会报错甚至可能暴露敏感配置信息。还有数据库连接信息、JWT 密钥、内部通信 Token 这类配置务必放到环境变量里别硬编码在代码中提交到仓库。5. 做一个可用的系统到底难在哪抛开技术细节不谈这个项目真正让我觉得有价值的地方在于它把一个完整业务从需求到落地的流程完整逼真地跑了一遍。做兼职发布页的时候一开始我只写了标题、描述、薪资这三个字段后来同学试用的时候反馈说没有 “工作时间” 信息兼职列表一多根本不知道谁是谁。于是又加了work_time字段发布表单也跟着改。这种需求演进的过程恰恰是真实的开发状态——需求和实现永远在互相迭代所谓的“可维护”不是设计得完美而是改起来顺。还有权限设计最开始我是什么接口都能访问测试的时候自己登录自己账号随便点。后来补了IsAuthenticatedOrReadOnly才对发布、报名这类操作加了门槛。管理员审核兼职信息这个功能也是后期加的但因为是基于状态字段设计的加权限控制只花了不到半小时。我个人在实际操作中的体会是这类学校业务系统难的不是某个技术难点而是把一堆简单功能可靠地串联起来。Vue 负责交互动效和页面状态Django 负责数据管理和业务规则Flask 在角落里做定时的辅助任务三者配合好了整个系统就像一条流水线数据从表单流向数据库再流向列表和详情页每一步都有据可查。如果你也准备做类似的项目我的建议是先把数据库表结构设计好再决定接口最后才设计页面。表结构错了改起来牵一发动全身页面丑一点后面随时可以优化。这条路我自己走了一遍少踩了很多弯路。