先说背景这个“基于Python的老年人服务预约系统”是我大半年以前开始折腾的项目。当时起因是帮一个社区做内部工具后来不断打磨最终形成了一套完整的前后端分离架构——前端用Vue后端用Python生态整个开发过程都在PyCharm里完成。正好最近有朋友问起这套系统的完整技术方案我干脆把项目的需求拆解、选型思路、核心模块实现、以及各种踩坑记录全部整理出来希望能给正在做类似全栈项目或者准备毕业设计的朋友一些可直接落地的参考。这个系统解决的是一个很具体的痛点社区里的老人需要助浴、助餐、陪诊、家政、康复护理等服务但以前全靠电话预约加手工登记。社区工作人员每天接电话接到手软安排服务靠Excel排表老年人或家属也完全看不到服务进度。所以这套系统的目标就是把预约服务全流程搬到线上——前端提供老人或家属使用的预约页面后端提供管理后台支持服务项目浏览、在线预约、后台审核派单、服务人员接单、服务完成后评价等一整套流程。后端框架我在Flask和Django之间反复权衡过第一版用Flask快速跑通重构时切到了Django所以这篇文里两个框架的实际体验都会讲到。适合读这篇内容的人很明确一是正在做Python Web方向毕业设计的学生二是社区服务类创业团队的技术负责人三是对Vue PythonFlask/Django前后端分离架构感兴趣、想用完整项目练手的开发者。文中会讲清楚每一个关键决策的理由也会把我在实际开发中踩过的坑明明白白列出来涉及环境配置、数据库设计、接口联调、部署上线等全流程操作。1. 项目概述与技术选型思路1.1 需求拆解这个系统到底需要哪些功能开始写代码之前我习惯先把需求全部列出来列清楚再决定技术方案。这里按照用户角色把功能拆成三层。老人/家属端前端用户注册登录、个人信息维护含家属联系方式、紧急联系人服务项目浏览与搜索助浴、助餐、陪诊、家政、康复护理等按服务人员空闲时段提交预约查看我的预约、取消预约、服务完成后评价接收预约状态变化通知管理员端后台管理服务项目配置名称、价格、时长、封面图、描述服务人员管理入驻、资质信息、可接单时段预约审核与派单把预约分配给具体服务人员数据统计看板日预约量、服务完成率等用户管理禁用、重置密码等服务人员端查看接到的服务单更新服务状态待出发、已到达、服务中、已完成查看自己的服务日程功能看着多但归拢下来核心就是一张预约单的生命周期管理。我在设计的时候把预约状态设计成一个状态机待支付可选→ 待审核 → 已派单 → 服务中 → 已完成 / 已取消。这个状态机是整个系统的主干前后端所有接口基本都是围绕它转的。这也意味着做这个项目别一上来就埋头写代码先把状态流转图画清楚后面能省下大量返工时间。1.2 后端框架Flask还是Django我是怎么选的这是所有Python Web开发者都要面对的灵魂问题。我当时在Flask和Django之间纠结了很久最后是结合项目需求做了取舍。这里把我的判断逻辑写出来供你参考。先看Flask。它的微型框架属性决定了它很灵活适合纯API服务。我第一版用的就是Flask Flask-SQLAlchemy开发速度确实快一个app.py就能跑通全部接口。但项目越往后写问题越明显用户认证、后台管理、表单验证、数据库迁移这些功能Flask都不内置需要自己一个个装第三方库拼起来。最头疼的是管理后台Flask没有官方Admin模块我用第三方库xadmin接了一次结果版本兼容性问题一堆后来干脆自己写轻量后台页面这块时间成本非常高。再看Django。它自带Admin后台、ORM、认证系统、迁移工具、表单验证开箱即用的东西非常多。缺点是“重”学习曲线比Flask陡峭而且Django的ORM确实没有SQLAlchemy那么灵活一些复杂的动态查询和多对多自定义中间表需要绕一点路。但最终我还是选择用Django重构原因很直接这个项目最大的时间消耗不在API接口而在后台管理页面、权限体系、数据迁移这些“内置能力”上这些恰好是Django的强项。维度FlaskDjango上手难度低写个接口几行代码中偏高要理解整体框架约定自带后台管理无需自行实现或接第三方自带Admin功能完善ORMSQLAlchemy灵活自主内置ORM约定优于配置用户认证需扩展flask-login等内置Auth系统开箱即用数据库迁移Flask-MigrateAlembic内置makemigrations/migrate适合场景轻量API、微服务、快速原型业务复杂、带管理后台的Web应用我的最终建议如果是做毕设或中小型业务系统直接从Django入手更省心如果只是验证想法或纯API服务Flask SQLAlchemy也很香。关键别在项目中途频繁切换框架重构的痛我替你先受了。1.3 前端选型与工具链Vue加PyCharm的组合前端为什么选Vue不选React其实两个都能做但从项目实际看Vue的生态和上手成本更适合“Python后端为主、前端为辅”的开发者。我喜欢Vue的几个点第一Vue 3的组合式API把逻辑抽出来比Vue 2的选项式清晰太多组件一多以后逻辑复用靠Composition函数就能搞定不用走mixins那套容易命名冲突的路子第二Vue的单文件组件把模板、脚本、样式放在一个文件里写完一个页面就是一个文件结构非常直观第三社区生态成熟Element Plus配合Vue 3非常好用后台管理界面的表格、表单、日期选择器、分页组件都是现成的做预约管理页面效率极高。技术栈具体是Vue 3 Vite Vue Router Pinia Element Plus Axios。UI用Element Plus移动端适配加上viewport meta和flexible布局确保在手机上打开也基本能看。开发工具上我用的是PyCharm Professional。为什么不用VSCode倒不是VSCode不行而是PyCharm对Python项目的开箱体验确实好代码补全、调试器、数据库工具、虚拟环境管理都是内置的尤其Django模板渲染调试和SQL查看这些功能VSCode要靠插件拼。做Python主后端项目PyCharm是最省心的选择。前端部分我把Vite的dev server跑在5173端口PyCharm里配置好npm启动项在Terminal里分两个tab分别跑后端和前端即可。注意PyCharm Community版对Django的模板调试、数据库工具支持很弱建议装Professional版。学生可以申请免费授权或者用公司采购的授权这部分不多说。2. 环境搭建与项目初始化2.1 Python虚拟环境与PyCharm配置这个项目我从Python 3.10开始因为3.10的兼容性和稳定性最好Django和Flask都能完美跑。装Python的时候有两点建议一是勾选“Add Python to PATH”避免后面在命令行找不到python二是建议用pyenv或者直接官网安装包都行但对新手来说官网安装包最省事。虚拟环境是Python项目的第一步也是很多人容易踩坑的地方。我的做法是在项目根目录下创建venvpython -m venv venv然后在PyCharm里打开项目File → Settings → Project → Python Interpreter选择刚才的venv作为解释器。这样所有依赖都装在这个虚拟环境里不会污染全局环境。如果你用的是Flask或者Django项目换到别的机器上时只要把requirements.txt导出在对方环境里执行pip install -r requirements.txt就能复现环境。pip freeze requirements.txt后来版本迭代多了我改用pipenv和Poetry但说实话对中小型项目原生venv加requirements.txt足够了别为了赶时髦引入多余的工具链。如果你的PyCharm版本较新还可以装AI插件写一些样板代码和正则的时候能省点事但核心逻辑千万别依赖它AI生成的Django代码经常有细节坑。2.2 初始化Django项目与基础配置后端我最终用的是Django 4.x版本配合djangorestframework写API。初始化命令很简单django-admin startproject elderly_service cd elderly_service python manage.py startapp user_app python manage.py startapp service_app python manage.py startapp reservation_app项目名叫elderly_service按模块拆分了三个appuser_app管用户和权限service_app管服务项目和人员reservation_app管预约核心业务。这样拆的好处是业务边界清晰后续扩展时改动局部即可而不是在一个app里塞几百个文件。创建完项目后需要改settings.py。首先要注册app和第三方库INSTALLED_APPS [ django.contrib.admin, django.contrib.auth, django.contrib.contenttypes, django.contrib.sessions, django.contrib.messages, django.contrib.staticfiles, rest_framework, corsheaders, user_app, service_app, reservation_app, ]然后配置数据库。我用的是MySQL需要在项目根目录的__init__.py里加pymysql的兼容代码否则MySQLdb会报错import pymysql pymysql.install_as_MySQLdb()settings里配置数据库连接信息包括数据库名、用户名、密码、主机和端口。如果你的环境是本地装MySQL不方便初期也可以用自带的SQLite但上线前一定要切到MySQL因为并发量和数据安全性不是一个量级。最后是MEDIA_ROOT和STATIC_ROOT的配置。服务项目封面图、用户头像这些上传文件需要配置MEDIA路径Django开发环境下用django.views.static.serve提供访问上线后交给Nginx处理。2.3 Vue 3项目初始化与环境配置前端初始化是我这个项目里最有心得的环节之一。之前用Vue CLI创建项目后期发现构建速度太慢。重构的时候换成了Vite创建项目的命令是npm create vuelatest或者更通用一点npm create vitelatest elderly-web -- --template vue创建完装依赖cd elderly-web npm install npm install vue-router4 pinia axios element-plus这里要注意的是Vue 3项目默认使用ESM语法Vite的dev server默认端口是5173这个端口后面要配到Django的跨域白名单里不然接口会被浏览器拦截。如果要用m3u8视频播放这类能力在Vue里可以引入hls.jsnpm install hls.js之后在组件里实例化即可播放。不过这个项目里我暂时用不到只在测试环境验证过。如果你是做社区服务类的项目可能未来要把操作演示视频放上去这个配置先记着后面扩展的时候直接用。开发环境配好后在PyCharm的Terminal里分两个tab一个cd到elderly_service跑python manage.py runserver 8000另一个在elderly-web里跑npm run dev两边独立编译调试互不影响。这才是完整的前后端分离开发姿势。3. 数据库设计与核心业务模块实现3.1 核心表结构设计预约单是绝对主干这个项目的数据库表设计我画了无数遍草稿核心思想是以预约单Reservation为绝对主干连接用户、服务项目、服务人员三张核心表。下面把核心模型写出来给做相似系统的人一个参考。用户部分我建议继承Django的AbstractUser扩展而不是直接用默认User表。原因很简单你需要手机号、角色字段直接改自带的表会舒服很多from django.db import models from django.contrib.auth.models import AbstractUser class User(AbstractUser): ROLE_CHOICES ( (1, 老人/家属), (2, 管理员), (3, 服务人员), ) phone models.CharField(max_length11, uniqueTrue, verbose_name手机号) role models.SmallIntegerField(choicesROLE_CHOICES, default1, verbose_name角色) avatar models.ImageField(upload_toavatars/, nullTrue, blankTrue, verbose_name头像) emergency_contact models.CharField(max_length50, blankTrue, verbose_name紧急联系人) emergency_phone models.CharField(max_length11, blankTrue, verbose_name紧急联系电话) class Meta: db_table user_info verbose_name 用户服务项目和服务人员模型class ServiceCategory(models.Model): name models.CharField(max_length50, verbose_name分类名称) icon models.CharField(max_length200, blankTrue, verbose_name图标地址) class ServiceItem(models.Model): category models.ForeignKey(ServiceCategory, on_deletemodels.CASCADE, related_nameitems) name models.CharField(max_length100, verbose_name服务名称) price models.DecimalField(max_digits8, decimal_places2, verbose_name价格) duration models.IntegerField(verbose_name时长/分钟) cover models.ImageField(upload_toservice_covers/, nullTrue, blankTrue) description models.TextField(blankTrue, verbose_name服务说明) class ServicePersonnel(models.Model): user models.OneToOneField(User, on_deletemodels.CASCADE, related_namepersonnel_info) service_items models.ManyToManyField(ServiceItem, related_namepersonnels, verbose_name可提供的服务) qualification models.CharField(max_length200, blankTrue, verbose_name资质信息) service_area models.CharField(max_length200, blankTrue, verbose_name服务区域)预约单模型是核心我贴出来细说class Reservation(models.Model): STATUS_CHOICES ( (0, 待审核), (1, 已派单), (2, 服务中), (3, 已完成), (4, 已取消), ) user models.ForeignKey(User, on_deletemodels.CASCADE, related_namereservations) service_item models.ForeignKey(ServiceItem, on_deletemodels.CASCADE, related_namereservations) personnel models.ForeignKey(ServicePersonnel, on_deletemodels.SET_NULL, nullTrue, blankTrue, related_namereservations) service_time models.DateTimeField(verbose_name预约服务时间) address models.CharField(max_length255, verbose_name服务地址) status models.SmallIntegerField(choicesSTATUS_CHOICES, default0, verbose_name状态) remark models.TextField(blankTrue, verbose_name备注) rating models.FloatField(nullTrue, blankTrue, verbose_name评分) comment models.TextField(blankTrue, verbose_name评价内容) created_at models.DateTimeField(auto_now_addTrue, verbose_name创建时间) updated_at models.DateTimeField(auto_nowTrue, verbose_name更新时间) class Meta: db_table reservation ordering [-created_at]字段看上去不多但有几个关键点要提醒personnel字段用了SET_NULL而不是CASCADE因为服务人员离职后历史预约单还需要保留不能一起删掉service_time用DateTimeField不用DateField因为服务需要精确到几点status字段一定要加choices后面代码里判断状态可读性会好很多。3.2 前后端数据交互Django REST Framework接口设计接口这一层我用的是Django REST FrameworkDRF。直接用DRF的ModelViewSet加Router很大一部分接口零代码生成。以预约接口为例# serializers.py from rest_framework import serializers from .models import Reservation class ReservationSerializer(serializers.ModelSerializer): service_item_name serializers.CharField(sourceservice_item.name, read_onlyTrue) personnel_name serializers.CharField(sourcepersonnel.user.username, read_onlyTrue, defaultNone) user_name serializers.CharField(sourceuser.username, read_onlyTrue) class Meta: model Reservation fields [id, user, service_item, service_item_name, personnel, personnel_name, service_time, address, status, remark, rating, comment, created_at] read_only_fields [status, created_at, updated_at]# views.py from rest_framework import viewsets, permissions from .models import Reservation from .serializers import ReservationSerializer class ReservationViewSet(viewsets.ModelViewSet): queryset Reservation.objects.all() serializer_class ReservationSerializer def get_permissions(self): if self.action in [create]: return [permissions.IsAuthenticated()] return [permissions.AllowAny()] def get_queryset(self): user self.request.user if user.role 1: return Reservation.objects.filter(useruser) if user.role 3: return Reservation.objects.filter(personnel__useruser) return Reservation.objects.all()接口用DRF自动生成的但业务逻辑部分必须自己去写。比如创建预约时要检查冲突这个服务时间段内同一个服务人员是否已经被派了别的单。这个判断我在创建接口的perform_create里手动加。DRF提供默认的API文档也很加分浏览器访问接口URL时能看到可视化调试页面方便前端同学联调。3.3 预约核心业务逻辑状态流转的完整实现预约状态流转是整个系统的灵魂。我把状态变更逻辑单独抽了一个service函数避免直接在视图里堆if elsedef update_reservation_status(reservation, new_status, user): allowed_transitions { 0: [1, 4], # 待审核 - 已派单 / 已取消 1: [2, 4], # 已派单 - 服务中 / 已取消 2: [3], # 服务中 - 已完成 } if new_status not in allowed_transitions.get(reservation.status, []): raise ValueError(f非法的状态变更{reservation.status} - {new_status}) if new_status 1 and reservation.personnel is None: raise ValueError(派单前必须指定服务人员) reservation.status new_status reservation.save(update_fields[status, updated_at]) return reservation这样做的价值在于所有状态流转的合法性判定集中在一个地方前端无论哪个页面触发了状态修改后端都不可能出现“从已完成又变回已派单”这种脏数据。后面如果要加“待支付”状态也只需要改这个表就够了。预约冲突判断我也单独写了个函数以服务人员为维度查询def check_conflict(personnel, start_time, duration_minutes60): end_time start_time timedelta(minutesduration_minutes) conflicts Reservation.objects.filter( personnelpersonnel, service_time__ltend_time, service_time__gtestart_time - timedelta(minutesduration_minutes), status__in[0, 1, 2] ).exists() return conflicts这套逻辑上线后实测很稳从来没出现过同一个服务人员同时段被安排两单的问题。4. 前端页面设计与接口联调4.1 Vue Router路由设计与参数传递前端页面我按角色划分成几个模块路由设计直接对应页面结构import { createRouter, createWebHistory } from vue-router const router createRouter({ history: createWebHistory(), routes: [ { path: /, name: home, component: () import(/views/Home.vue) }, { path: /services, name: services, component: () import(/views/Services.vue) }, { path: /service/:id, name: serviceDetail, component: () import(/views/ServiceDetail.vue), props: true }, { path: /reservation/:id, name: reservation, component: () import(/views/ReservationConfirm.vue), props: true }, { path: /orders, name: orders, component: () import(/views/MyOrders.vue), meta: { requiresAuth: true } }, { path: /admin, name: admin, component: () import(/views/AdminDashboard.vue), meta: { requiresAuth: true, requiresRole: 2 } }, { path: /login, name: login, component: () import(/views/Login.vue) }, ] })路由参数这块我在项目里用了两种方式。详情页用props传参比如预约确认页需要接收服务项目的id可以在跳转时router.push({ name: reservation, params: { id: serviceItemId } })这种方式页面刷新后参数还留在URL里不会丢。另一种情况比如列表页到详情页需要携带一些临时筛选条件我建议用query参数而不是params因为query可以在刷新后留存params用createWebHistory时刷新页面会丢。还有一个细节路由守卫。我在全局前置守卫里做登录态判断未登录用户访问需要认证的页面统一重定向到登录页登录后跳回原页面router.beforeEach((to, from, next) { const token localStorage.getItem(token) if (to.meta.requiresAuth !token) { next({ name: login, query: { redirect: to.fullPath } }) } else { next() } })4.2 页面组件设计与Element Plus应用前端的交互页面我用Element Plus这套组件库搭起来非常高效。这里重点说两个页面服务列表页和预约确认页。服务列表页的筛选区用el-select和el-input组合配合el-card平铺服务项目。每个服务卡片展示封面、名称、价格、时长点击卡片跳转到详情。列表数据从后端接口拉取分页用el-pagination。耗时主要在样式调整上Element Plus默认样式有点偏后管风格我自己用CSS变量覆盖了主色调让整体看起来偏暖色更适合长辈操作。预约确认页是整个前端最复杂的一块包含表单校验、服务时间选择、服务人员选择这三个核心交互。表单用了Element Plus的el-form加rules校验手机号格式、必填项都有前端验证。服务时间选择用el-date-picker但禁用了已过时间。服务人员选择是动态的根据用户选择的服务项目和时间段向后端请求该时段空闲的服务人员列表。提示不要在前端写死“服务人员”的下拉选项一定要根据用户选的日期时间动态请求后端。不然用户选了个没人接单的时间预约提交后才被后台拒绝体验很差。4.3 axios封装、跨域与统一认证前端发请求用的是axios。我在项目里封装了一个request实例统一处理baseURL、超时时间、token注入和错误码拦截import axios from axios const service axios.create({ baseURL: /api, timeout: 10000, withCredentials: true }) service.interceptors.request.use(config { const token localStorage.getItem(token) if (token) { config.headers.Authorization Bearer ${token} } return config }) service.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) } )开发模式下Vite的dev server是5173Django跑在8000端口不一样必然产生跨域问题。Django这边用django-cors-headers解决pip install django-cors-headerssettings里配置CORS_ALLOWED_ORIGINS [ http://localhost:5173, ] CORS_ALLOW_CREDENTIALS True这是开发环境。上线部署时前端和后端同域部署走Nginx反向代理就不存在跨域问题了详细方案放在后面部署章节。还有一个坑前后端分离环境下如果使用Session认证前端必须配置withCredentials: true否则Django这边拿不到客户端Cookie会一直返回401。我当时调试了半天才定位到是axios缺了withCredentials配置。如果你用JWT方案就不存在这个问题但我为了简单还是用的Django自带Session认证加DRF的TokenAuth。5. 扩展功能与部署上线5.1 服务人员排班与消息通知系统跑起来后社区那边提出了新需求服务人员什么时候有空、什么时候休息能不能提前设置好用户只挑有空的时段。这就是排班功能。排班表模型之前已经提过这里补充一下实现细节。我在WorkSchedule表里存了服务人员、日期、开始时间、结束时间、是否可预约。用户查询某个服务项目时后端先找出提供该服务的所有服务人员再和每个人员的排班表做交集返回可预约的时段集合。这个查询有点复杂不能单表查出来需要动态计算。我第一版用Python循环过滤数据量小的时候没问题但服务人员多了、排班数据大了以后响应变慢后来改成按日期范围在SQL层面过滤配合索引后性能提升很明显。经验是这种动态排班查询数据库层面过滤比Python循环快一个量级别偷懒全查出来再说。消息通知这块我初期用的是轮询前端每隔10秒请求一次“我的未读消息数”有变化就更新角标。后来觉得实时性不够也不想引用WebSocket把复杂度抬太高就保持了轮询方案。如果你的业务对实时性要求更高可以考虑Django Channels或独立的Go服务但小项目真没必要。5.2 数据统计与后台看板后台看板是一个很能体现系统价值的功能。我用Django的ORM做聚合统计接口返回给前端前端用ECharts画图表。统计接口的核心逻辑from django.db.models import Count, Sum from django.db.models.functions import TruncDate def daily_stats(request): stats Reservation.objects.filter( created_at__date__gtetimezone.now() - timedelta(days30) ).annotate( dayTruncDate(created_at) ).values(day).annotate( countCount(id), completedCount(id, filtermodels.Q(status3)) ).order_by(day) return JsonResponse(list(stats), safeFalse)ECharts在前端通过npm install echarts安装导入后在组件里初始化。我画了预约量趋势折线图、服务分类占比饼图、服务人员完成量排名柱状图。这套看板做出来后社区管理员反馈特别好很多以前要靠Excel手工统计的数据现在一眼就能看到。5.3 部署上线云服务器与宝塔面板项目开发完成后我部署到一台2核4G的云服务器上系统是Ubuntu 22.04。部署路径用的是宝塔面板加Nginx反向代理整体来说比较顺但有几个关键坑要写清楚。先把后端跑起来。服务器上创建venv安装依赖用gunicorn作为WSGI服务器pip install gunicorn gunicorn elderly_service.wsgi:application --bind 127.0.0.1:8000 --workers 3然后配置Nginx。我的Nginx配置里做了两件事第一前端打包后的dist目录作为静态文件根目录直接托管访问第二把/api开头的请求反向代理到本地的gunicorn服务。server { listen 80; server_name your_domain.com; root /www/elderly-web/dist; index index.html; location / { try_files $uri $uri/ /index.html; } location /api/ { proxy_pass http://127.0.0.1:8000; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } location /media/ { alias /www/elderly_service/media/; } }注意前端静态文件上传的图片也就是/media路径这部分必须单独配置alias指向Django的MEDIA_ROOT目录否则图片无法访问。这是我部署时踩到的第一个坑。第二个坑是Django的ALLOWED_HOSTS必须加上域名或服务器IP否则浏览器访问时Django直接返回400错误。第三个坑是数据库用MySQL时需要确保服务器上的MySQL开启远程访问或者本地socket连接正常用pymysql配合时注意字符集设置否则中文乱码。如果数据库想用云厂商的托管数据库比如阿里的RDS也可以只需要在settings里把HOST改成数据库内网地址即可但要注意安全组放行3306端口。6. 常见问题排查与避坑指南6.1 环境配置阶段的高频问题环境和依赖这一块几乎每个来问我的人都会遇到同样的问题。我把最常见的几个列成表方便自查问题现象可能原因解决方法python命令找不到安装时没勾选Add to PATH重新安装Python并勾选或手动配置环境变量pip安装慢或超时默认源是国外源换镜像源pip install -i https://pypi.tuna.tsinghua.edu.cn/simple 包名Django命令找不到没激活虚拟环境激活venv后再执行命令或检查PyCharm解释器是否选对npm run dev报错Node版本过低升级Node到18以上Vite要求较高版本数据库中文乱码MySQL字符集不是utf8mb4创建数据库时指定charsetutf8mb4连接串加charset参数还有一个很常见的坑是Django版本和第三方库不兼容。比如django-cors-headers对Django版本有要求如果你用最新版Django 5.x有些老版本第三方库可能不支持最好统一用较新的版本组合。我在项目初期就用错了版本后来全部用pip freeze锁定了版本号才把环境稳定下来。6.2 数据库与模型相关的坑数据库迁移这个操作新手最怕的就是makemigrations之后发现改了模型迁移文件却冲突。我的经验是每次改模型后马上执行makemigrations和migrate不要攒着改好几处再来迁移。还有生产环境的数据库迁移一定要先备份再操作。Django里执行删除对象比如删除一条评论comment Comment.objects.get(id1) comment.delete()看似简单但要注意在外键没有设置on_deletemodels.CASCADE的情况下删除父表数据会报ProtectedError如果设置了CASCADE会连带删除子表数据。在预约系统里删除服务项目时如果还有历史预约单指向它会导致预约单数据丢失。所以我对核心业务表都尽量用on_deletemodels.SET_NULL或者只做软删除加一个is_active字段历史数据不能随便物理删。另外非常建议在数据库表里加入created_at和updated_at字段Django中可以用auto_now_add和auto_now自动维护这对排查数据问题和做统计都极其有用我早期没加后来返工补上的。6.3 前后端联调的典型问题联调阶段最常见的就是跨域和接口格式不一致。跨域问题前面已经提到了。这里补充一个细节用django-cors-headers时如果前端请求带了自定义Header比如AuthorizationCORS_ALLOW_HEADERS里要加上对应Header名否则仍然会被浏览器拦截。Django开发的Native过程中可以在浏览器开发者工具的Console里看到具体的跨域报错信息顺着那条信息排查速度最快。接口格式不一致这个问题更隐蔽。比如后端返回的日期格式是2024-06-01T10:30:00ZISO 8601前端想在页面上显示成6月1日 10:30直接拿来显示肯定不对。我的做法是后端序列化器里按前端需要的格式返回class ReservationSerializer(serializers.ModelSerializer): service_time serializers.DateTimeField(format%Y-%m-%d %H:%M)但这样做的坏处是后端被前端显示格式绑架换个前端就废了。更好的方式是后端返回原始格式前端在展示层统一格式化。我最后采用了前端方案在Vue组件里写一个formatTime过滤器统一把ISO字符串转成中文格式。这样做的好处是同一个接口给PC端和移动端复用各端自行决定怎么显示。还有一个非常容易踩的坑是HTTP状态码的语义。我见过不少同学后端不管什么错误都返回200在响应体里放个code字段来区分。这种做法不是不行但会让前端axios拦截器写起来很别扭。我建议遵循RESTful风格成功返回200/201参数错误返回400未认证返回401权限不足返回403资源不存在返回404服务异常返回500。这样axios统一拦截异常前端逻辑会清爽很多。6.4 部署上线的坑静态文件、域名和进程守护部署阶段的问题和开发阶段完全不一样。除了前面Nginx配置那三个坑还有几个实际运维中特别重要的点。第一个是Django静态文件收集。Django框架需要执行collectstatic命令把admin后台的静态文件复制到STATIC_ROOT指定的目录否则你Django自带的admin后台页面没有样式全是裸HTML。这个命令在每次部署前都要重新执行。第二个是进程守护问题。直接用gunicorn启动的服务SSH断开后进程就死了。我用了Supervisor管理gunicorn进程配置了开机自启和自动重启。这样即使机器重启或进程崩溃后端服务也能自动恢复。第三个是HTTPS。现在很多浏览器对非HTTPS域名会有安全隐患提示尤其是涉及登录、支付功能的项目。如果想让系统正式上线建议在宝塔面板里一键申请SSL证书并开启强制HTTPS。等以后要做移动端小程序或App时HTTPS是硬性要求后面改造的成本会高不少。结尾这套系统的后续价值与个人体会这个项目做完之后我自己最大的体会是技术选型真的不要太追求“酷炫新框架”稳定、熟悉、社区成熟的组合才是做项目的王道。Vue加PythonFlask或Django这套组合从开发效率、学习资料丰富度、就业简历友好度来看都是非常稳的选择。尤其对准备做毕业设计的同学来说这套系统从需求到设计再到实现的完整链路本身就是一个很好的项目亮点面试时能讲清楚状态机设计、权限控制、跨域处理这些细节比光说“我做了个XX系统”有说服力得多。最后再分享一个小技巧像这种前后端分离的项目一定要养成写接口文档的习惯。我项目初期偷懒没写前后端联调时沟通成本极高后来用DRF自带的文档接口配合简单说明效率提升非常明显。如果你用的是Flask建议用flask-restx或自己维护一个Markdown接口文档不然等代码量增长后你自己都记不住哪个接口返回什么格式。从这个角度说Django REST Framework的自动文档功能也是我最终选择Django而不是Flask的重要理由之一。希望这篇记录能给正在做同类项目的你实实在在的帮助。
先说背景这个“基于Python的老年人服务预约系统”是我大半年以前开始折腾的项目。当时起因是帮一个社区做内部工具后来不断打磨最终形成了一套完整的前后端分离架构——前端用Vue后端用Python生态整个开发过程都在PyCharm里完成。正好最近有朋友问起这套系统的完整技术方案我干脆把项目的需求拆解、选型思路、核心模块实现、以及各种踩坑记录全部整理出来希望能给正在做类似全栈项目或者准备毕业设计的朋友一些可直接落地的参考。这个系统解决的是一个很具体的痛点社区里的老人需要助浴、助餐、陪诊、家政、康复护理等服务但以前全靠电话预约加手工登记。社区工作人员每天接电话接到手软安排服务靠Excel排表老年人或家属也完全看不到服务进度。所以这套系统的目标就是把预约服务全流程搬到线上——前端提供老人或家属使用的预约页面后端提供管理后台支持服务项目浏览、在线预约、后台审核派单、服务人员接单、服务完成后评价等一整套流程。后端框架我在Flask和Django之间反复权衡过第一版用Flask快速跑通重构时切到了Django所以这篇文里两个框架的实际体验都会讲到。适合读这篇内容的人很明确一是正在做Python Web方向毕业设计的学生二是社区服务类创业团队的技术负责人三是对Vue PythonFlask/Django前后端分离架构感兴趣、想用完整项目练手的开发者。文中会讲清楚每一个关键决策的理由也会把我在实际开发中踩过的坑明明白白列出来涉及环境配置、数据库设计、接口联调、部署上线等全流程操作。1. 项目概述与技术选型思路1.1 需求拆解这个系统到底需要哪些功能开始写代码之前我习惯先把需求全部列出来列清楚再决定技术方案。这里按照用户角色把功能拆成三层。老人/家属端前端用户注册登录、个人信息维护含家属联系方式、紧急联系人服务项目浏览与搜索助浴、助餐、陪诊、家政、康复护理等按服务人员空闲时段提交预约查看我的预约、取消预约、服务完成后评价接收预约状态变化通知管理员端后台管理服务项目配置名称、价格、时长、封面图、描述服务人员管理入驻、资质信息、可接单时段预约审核与派单把预约分配给具体服务人员数据统计看板日预约量、服务完成率等用户管理禁用、重置密码等服务人员端查看接到的服务单更新服务状态待出发、已到达、服务中、已完成查看自己的服务日程功能看着多但归拢下来核心就是一张预约单的生命周期管理。我在设计的时候把预约状态设计成一个状态机待支付可选→ 待审核 → 已派单 → 服务中 → 已完成 / 已取消。这个状态机是整个系统的主干前后端所有接口基本都是围绕它转的。这也意味着做这个项目别一上来就埋头写代码先把状态流转图画清楚后面能省下大量返工时间。1.2 后端框架Flask还是Django我是怎么选的这是所有Python Web开发者都要面对的灵魂问题。我当时在Flask和Django之间纠结了很久最后是结合项目需求做了取舍。这里把我的判断逻辑写出来供你参考。先看Flask。它的微型框架属性决定了它很灵活适合纯API服务。我第一版用的就是Flask Flask-SQLAlchemy开发速度确实快一个app.py就能跑通全部接口。但项目越往后写问题越明显用户认证、后台管理、表单验证、数据库迁移这些功能Flask都不内置需要自己一个个装第三方库拼起来。最头疼的是管理后台Flask没有官方Admin模块我用第三方库xadmin接了一次结果版本兼容性问题一堆后来干脆自己写轻量后台页面这块时间成本非常高。再看Django。它自带Admin后台、ORM、认证系统、迁移工具、表单验证开箱即用的东西非常多。缺点是“重”学习曲线比Flask陡峭而且Django的ORM确实没有SQLAlchemy那么灵活一些复杂的动态查询和多对多自定义中间表需要绕一点路。但最终我还是选择用Django重构原因很直接这个项目最大的时间消耗不在API接口而在后台管理页面、权限体系、数据迁移这些“内置能力”上这些恰好是Django的强项。维度FlaskDjango上手难度低写个接口几行代码中偏高要理解整体框架约定自带后台管理无需自行实现或接第三方自带Admin功能完善ORMSQLAlchemy灵活自主内置ORM约定优于配置用户认证需扩展flask-login等内置Auth系统开箱即用数据库迁移Flask-MigrateAlembic内置makemigrations/migrate适合场景轻量API、微服务、快速原型业务复杂、带管理后台的Web应用我的最终建议如果是做毕设或中小型业务系统直接从Django入手更省心如果只是验证想法或纯API服务Flask SQLAlchemy也很香。关键别在项目中途频繁切换框架重构的痛我替你先受了。1.3 前端选型与工具链Vue加PyCharm的组合前端为什么选Vue不选React其实两个都能做但从项目实际看Vue的生态和上手成本更适合“Python后端为主、前端为辅”的开发者。我喜欢Vue的几个点第一Vue 3的组合式API把逻辑抽出来比Vue 2的选项式清晰太多组件一多以后逻辑复用靠Composition函数就能搞定不用走mixins那套容易命名冲突的路子第二Vue的单文件组件把模板、脚本、样式放在一个文件里写完一个页面就是一个文件结构非常直观第三社区生态成熟Element Plus配合Vue 3非常好用后台管理界面的表格、表单、日期选择器、分页组件都是现成的做预约管理页面效率极高。技术栈具体是Vue 3 Vite Vue Router Pinia Element Plus Axios。UI用Element Plus移动端适配加上viewport meta和flexible布局确保在手机上打开也基本能看。开发工具上我用的是PyCharm Professional。为什么不用VSCode倒不是VSCode不行而是PyCharm对Python项目的开箱体验确实好代码补全、调试器、数据库工具、虚拟环境管理都是内置的尤其Django模板渲染调试和SQL查看这些功能VSCode要靠插件拼。做Python主后端项目PyCharm是最省心的选择。前端部分我把Vite的dev server跑在5173端口PyCharm里配置好npm启动项在Terminal里分两个tab分别跑后端和前端即可。注意PyCharm Community版对Django的模板调试、数据库工具支持很弱建议装Professional版。学生可以申请免费授权或者用公司采购的授权这部分不多说。2. 环境搭建与项目初始化2.1 Python虚拟环境与PyCharm配置这个项目我从Python 3.10开始因为3.10的兼容性和稳定性最好Django和Flask都能完美跑。装Python的时候有两点建议一是勾选“Add Python to PATH”避免后面在命令行找不到python二是建议用pyenv或者直接官网安装包都行但对新手来说官网安装包最省事。虚拟环境是Python项目的第一步也是很多人容易踩坑的地方。我的做法是在项目根目录下创建venvpython -m venv venv然后在PyCharm里打开项目File → Settings → Project → Python Interpreter选择刚才的venv作为解释器。这样所有依赖都装在这个虚拟环境里不会污染全局环境。如果你用的是Flask或者Django项目换到别的机器上时只要把requirements.txt导出在对方环境里执行pip install -r requirements.txt就能复现环境。pip freeze requirements.txt后来版本迭代多了我改用pipenv和Poetry但说实话对中小型项目原生venv加requirements.txt足够了别为了赶时髦引入多余的工具链。如果你的PyCharm版本较新还可以装AI插件写一些样板代码和正则的时候能省点事但核心逻辑千万别依赖它AI生成的Django代码经常有细节坑。2.2 初始化Django项目与基础配置后端我最终用的是Django 4.x版本配合djangorestframework写API。初始化命令很简单django-admin startproject elderly_service cd elderly_service python manage.py startapp user_app python manage.py startapp service_app python manage.py startapp reservation_app项目名叫elderly_service按模块拆分了三个appuser_app管用户和权限service_app管服务项目和人员reservation_app管预约核心业务。这样拆的好处是业务边界清晰后续扩展时改动局部即可而不是在一个app里塞几百个文件。创建完项目后需要改settings.py。首先要注册app和第三方库INSTALLED_APPS [ django.contrib.admin, django.contrib.auth, django.contrib.contenttypes, django.contrib.sessions, django.contrib.messages, django.contrib.staticfiles, rest_framework, corsheaders, user_app, service_app, reservation_app, ]然后配置数据库。我用的是MySQL需要在项目根目录的__init__.py里加pymysql的兼容代码否则MySQLdb会报错import pymysql pymysql.install_as_MySQLdb()settings里配置数据库连接信息包括数据库名、用户名、密码、主机和端口。如果你的环境是本地装MySQL不方便初期也可以用自带的SQLite但上线前一定要切到MySQL因为并发量和数据安全性不是一个量级。最后是MEDIA_ROOT和STATIC_ROOT的配置。服务项目封面图、用户头像这些上传文件需要配置MEDIA路径Django开发环境下用django.views.static.serve提供访问上线后交给Nginx处理。2.3 Vue 3项目初始化与环境配置前端初始化是我这个项目里最有心得的环节之一。之前用Vue CLI创建项目后期发现构建速度太慢。重构的时候换成了Vite创建项目的命令是npm create vuelatest或者更通用一点npm create vitelatest elderly-web -- --template vue创建完装依赖cd elderly-web npm install npm install vue-router4 pinia axios element-plus这里要注意的是Vue 3项目默认使用ESM语法Vite的dev server默认端口是5173这个端口后面要配到Django的跨域白名单里不然接口会被浏览器拦截。如果要用m3u8视频播放这类能力在Vue里可以引入hls.jsnpm install hls.js之后在组件里实例化即可播放。不过这个项目里我暂时用不到只在测试环境验证过。如果你是做社区服务类的项目可能未来要把操作演示视频放上去这个配置先记着后面扩展的时候直接用。开发环境配好后在PyCharm的Terminal里分两个tab一个cd到elderly_service跑python manage.py runserver 8000另一个在elderly-web里跑npm run dev两边独立编译调试互不影响。这才是完整的前后端分离开发姿势。3. 数据库设计与核心业务模块实现3.1 核心表结构设计预约单是绝对主干这个项目的数据库表设计我画了无数遍草稿核心思想是以预约单Reservation为绝对主干连接用户、服务项目、服务人员三张核心表。下面把核心模型写出来给做相似系统的人一个参考。用户部分我建议继承Django的AbstractUser扩展而不是直接用默认User表。原因很简单你需要手机号、角色字段直接改自带的表会舒服很多from django.db import models from django.contrib.auth.models import AbstractUser class User(AbstractUser): ROLE_CHOICES ( (1, 老人/家属), (2, 管理员), (3, 服务人员), ) phone models.CharField(max_length11, uniqueTrue, verbose_name手机号) role models.SmallIntegerField(choicesROLE_CHOICES, default1, verbose_name角色) avatar models.ImageField(upload_toavatars/, nullTrue, blankTrue, verbose_name头像) emergency_contact models.CharField(max_length50, blankTrue, verbose_name紧急联系人) emergency_phone models.CharField(max_length11, blankTrue, verbose_name紧急联系电话) class Meta: db_table user_info verbose_name 用户服务项目和服务人员模型class ServiceCategory(models.Model): name models.CharField(max_length50, verbose_name分类名称) icon models.CharField(max_length200, blankTrue, verbose_name图标地址) class ServiceItem(models.Model): category models.ForeignKey(ServiceCategory, on_deletemodels.CASCADE, related_nameitems) name models.CharField(max_length100, verbose_name服务名称) price models.DecimalField(max_digits8, decimal_places2, verbose_name价格) duration models.IntegerField(verbose_name时长/分钟) cover models.ImageField(upload_toservice_covers/, nullTrue, blankTrue) description models.TextField(blankTrue, verbose_name服务说明) class ServicePersonnel(models.Model): user models.OneToOneField(User, on_deletemodels.CASCADE, related_namepersonnel_info) service_items models.ManyToManyField(ServiceItem, related_namepersonnels, verbose_name可提供的服务) qualification models.CharField(max_length200, blankTrue, verbose_name资质信息) service_area models.CharField(max_length200, blankTrue, verbose_name服务区域)预约单模型是核心我贴出来细说class Reservation(models.Model): STATUS_CHOICES ( (0, 待审核), (1, 已派单), (2, 服务中), (3, 已完成), (4, 已取消), ) user models.ForeignKey(User, on_deletemodels.CASCADE, related_namereservations) service_item models.ForeignKey(ServiceItem, on_deletemodels.CASCADE, related_namereservations) personnel models.ForeignKey(ServicePersonnel, on_deletemodels.SET_NULL, nullTrue, blankTrue, related_namereservations) service_time models.DateTimeField(verbose_name预约服务时间) address models.CharField(max_length255, verbose_name服务地址) status models.SmallIntegerField(choicesSTATUS_CHOICES, default0, verbose_name状态) remark models.TextField(blankTrue, verbose_name备注) rating models.FloatField(nullTrue, blankTrue, verbose_name评分) comment models.TextField(blankTrue, verbose_name评价内容) created_at models.DateTimeField(auto_now_addTrue, verbose_name创建时间) updated_at models.DateTimeField(auto_nowTrue, verbose_name更新时间) class Meta: db_table reservation ordering [-created_at]字段看上去不多但有几个关键点要提醒personnel字段用了SET_NULL而不是CASCADE因为服务人员离职后历史预约单还需要保留不能一起删掉service_time用DateTimeField不用DateField因为服务需要精确到几点status字段一定要加choices后面代码里判断状态可读性会好很多。3.2 前后端数据交互Django REST Framework接口设计接口这一层我用的是Django REST FrameworkDRF。直接用DRF的ModelViewSet加Router很大一部分接口零代码生成。以预约接口为例# serializers.py from rest_framework import serializers from .models import Reservation class ReservationSerializer(serializers.ModelSerializer): service_item_name serializers.CharField(sourceservice_item.name, read_onlyTrue) personnel_name serializers.CharField(sourcepersonnel.user.username, read_onlyTrue, defaultNone) user_name serializers.CharField(sourceuser.username, read_onlyTrue) class Meta: model Reservation fields [id, user, service_item, service_item_name, personnel, personnel_name, service_time, address, status, remark, rating, comment, created_at] read_only_fields [status, created_at, updated_at]# views.py from rest_framework import viewsets, permissions from .models import Reservation from .serializers import ReservationSerializer class ReservationViewSet(viewsets.ModelViewSet): queryset Reservation.objects.all() serializer_class ReservationSerializer def get_permissions(self): if self.action in [create]: return [permissions.IsAuthenticated()] return [permissions.AllowAny()] def get_queryset(self): user self.request.user if user.role 1: return Reservation.objects.filter(useruser) if user.role 3: return Reservation.objects.filter(personnel__useruser) return Reservation.objects.all()接口用DRF自动生成的但业务逻辑部分必须自己去写。比如创建预约时要检查冲突这个服务时间段内同一个服务人员是否已经被派了别的单。这个判断我在创建接口的perform_create里手动加。DRF提供默认的API文档也很加分浏览器访问接口URL时能看到可视化调试页面方便前端同学联调。3.3 预约核心业务逻辑状态流转的完整实现预约状态流转是整个系统的灵魂。我把状态变更逻辑单独抽了一个service函数避免直接在视图里堆if elsedef update_reservation_status(reservation, new_status, user): allowed_transitions { 0: [1, 4], # 待审核 - 已派单 / 已取消 1: [2, 4], # 已派单 - 服务中 / 已取消 2: [3], # 服务中 - 已完成 } if new_status not in allowed_transitions.get(reservation.status, []): raise ValueError(f非法的状态变更{reservation.status} - {new_status}) if new_status 1 and reservation.personnel is None: raise ValueError(派单前必须指定服务人员) reservation.status new_status reservation.save(update_fields[status, updated_at]) return reservation这样做的价值在于所有状态流转的合法性判定集中在一个地方前端无论哪个页面触发了状态修改后端都不可能出现“从已完成又变回已派单”这种脏数据。后面如果要加“待支付”状态也只需要改这个表就够了。预约冲突判断我也单独写了个函数以服务人员为维度查询def check_conflict(personnel, start_time, duration_minutes60): end_time start_time timedelta(minutesduration_minutes) conflicts Reservation.objects.filter( personnelpersonnel, service_time__ltend_time, service_time__gtestart_time - timedelta(minutesduration_minutes), status__in[0, 1, 2] ).exists() return conflicts这套逻辑上线后实测很稳从来没出现过同一个服务人员同时段被安排两单的问题。4. 前端页面设计与接口联调4.1 Vue Router路由设计与参数传递前端页面我按角色划分成几个模块路由设计直接对应页面结构import { createRouter, createWebHistory } from vue-router const router createRouter({ history: createWebHistory(), routes: [ { path: /, name: home, component: () import(/views/Home.vue) }, { path: /services, name: services, component: () import(/views/Services.vue) }, { path: /service/:id, name: serviceDetail, component: () import(/views/ServiceDetail.vue), props: true }, { path: /reservation/:id, name: reservation, component: () import(/views/ReservationConfirm.vue), props: true }, { path: /orders, name: orders, component: () import(/views/MyOrders.vue), meta: { requiresAuth: true } }, { path: /admin, name: admin, component: () import(/views/AdminDashboard.vue), meta: { requiresAuth: true, requiresRole: 2 } }, { path: /login, name: login, component: () import(/views/Login.vue) }, ] })路由参数这块我在项目里用了两种方式。详情页用props传参比如预约确认页需要接收服务项目的id可以在跳转时router.push({ name: reservation, params: { id: serviceItemId } })这种方式页面刷新后参数还留在URL里不会丢。另一种情况比如列表页到详情页需要携带一些临时筛选条件我建议用query参数而不是params因为query可以在刷新后留存params用createWebHistory时刷新页面会丢。还有一个细节路由守卫。我在全局前置守卫里做登录态判断未登录用户访问需要认证的页面统一重定向到登录页登录后跳回原页面router.beforeEach((to, from, next) { const token localStorage.getItem(token) if (to.meta.requiresAuth !token) { next({ name: login, query: { redirect: to.fullPath } }) } else { next() } })4.2 页面组件设计与Element Plus应用前端的交互页面我用Element Plus这套组件库搭起来非常高效。这里重点说两个页面服务列表页和预约确认页。服务列表页的筛选区用el-select和el-input组合配合el-card平铺服务项目。每个服务卡片展示封面、名称、价格、时长点击卡片跳转到详情。列表数据从后端接口拉取分页用el-pagination。耗时主要在样式调整上Element Plus默认样式有点偏后管风格我自己用CSS变量覆盖了主色调让整体看起来偏暖色更适合长辈操作。预约确认页是整个前端最复杂的一块包含表单校验、服务时间选择、服务人员选择这三个核心交互。表单用了Element Plus的el-form加rules校验手机号格式、必填项都有前端验证。服务时间选择用el-date-picker但禁用了已过时间。服务人员选择是动态的根据用户选择的服务项目和时间段向后端请求该时段空闲的服务人员列表。提示不要在前端写死“服务人员”的下拉选项一定要根据用户选的日期时间动态请求后端。不然用户选了个没人接单的时间预约提交后才被后台拒绝体验很差。4.3 axios封装、跨域与统一认证前端发请求用的是axios。我在项目里封装了一个request实例统一处理baseURL、超时时间、token注入和错误码拦截import axios from axios const service axios.create({ baseURL: /api, timeout: 10000, withCredentials: true }) service.interceptors.request.use(config { const token localStorage.getItem(token) if (token) { config.headers.Authorization Bearer ${token} } return config }) service.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) } )开发模式下Vite的dev server是5173Django跑在8000端口不一样必然产生跨域问题。Django这边用django-cors-headers解决pip install django-cors-headerssettings里配置CORS_ALLOWED_ORIGINS [ http://localhost:5173, ] CORS_ALLOW_CREDENTIALS True这是开发环境。上线部署时前端和后端同域部署走Nginx反向代理就不存在跨域问题了详细方案放在后面部署章节。还有一个坑前后端分离环境下如果使用Session认证前端必须配置withCredentials: true否则Django这边拿不到客户端Cookie会一直返回401。我当时调试了半天才定位到是axios缺了withCredentials配置。如果你用JWT方案就不存在这个问题但我为了简单还是用的Django自带Session认证加DRF的TokenAuth。5. 扩展功能与部署上线5.1 服务人员排班与消息通知系统跑起来后社区那边提出了新需求服务人员什么时候有空、什么时候休息能不能提前设置好用户只挑有空的时段。这就是排班功能。排班表模型之前已经提过这里补充一下实现细节。我在WorkSchedule表里存了服务人员、日期、开始时间、结束时间、是否可预约。用户查询某个服务项目时后端先找出提供该服务的所有服务人员再和每个人员的排班表做交集返回可预约的时段集合。这个查询有点复杂不能单表查出来需要动态计算。我第一版用Python循环过滤数据量小的时候没问题但服务人员多了、排班数据大了以后响应变慢后来改成按日期范围在SQL层面过滤配合索引后性能提升很明显。经验是这种动态排班查询数据库层面过滤比Python循环快一个量级别偷懒全查出来再说。消息通知这块我初期用的是轮询前端每隔10秒请求一次“我的未读消息数”有变化就更新角标。后来觉得实时性不够也不想引用WebSocket把复杂度抬太高就保持了轮询方案。如果你的业务对实时性要求更高可以考虑Django Channels或独立的Go服务但小项目真没必要。5.2 数据统计与后台看板后台看板是一个很能体现系统价值的功能。我用Django的ORM做聚合统计接口返回给前端前端用ECharts画图表。统计接口的核心逻辑from django.db.models import Count, Sum from django.db.models.functions import TruncDate def daily_stats(request): stats Reservation.objects.filter( created_at__date__gtetimezone.now() - timedelta(days30) ).annotate( dayTruncDate(created_at) ).values(day).annotate( countCount(id), completedCount(id, filtermodels.Q(status3)) ).order_by(day) return JsonResponse(list(stats), safeFalse)ECharts在前端通过npm install echarts安装导入后在组件里初始化。我画了预约量趋势折线图、服务分类占比饼图、服务人员完成量排名柱状图。这套看板做出来后社区管理员反馈特别好很多以前要靠Excel手工统计的数据现在一眼就能看到。5.3 部署上线云服务器与宝塔面板项目开发完成后我部署到一台2核4G的云服务器上系统是Ubuntu 22.04。部署路径用的是宝塔面板加Nginx反向代理整体来说比较顺但有几个关键坑要写清楚。先把后端跑起来。服务器上创建venv安装依赖用gunicorn作为WSGI服务器pip install gunicorn gunicorn elderly_service.wsgi:application --bind 127.0.0.1:8000 --workers 3然后配置Nginx。我的Nginx配置里做了两件事第一前端打包后的dist目录作为静态文件根目录直接托管访问第二把/api开头的请求反向代理到本地的gunicorn服务。server { listen 80; server_name your_domain.com; root /www/elderly-web/dist; index index.html; location / { try_files $uri $uri/ /index.html; } location /api/ { proxy_pass http://127.0.0.1:8000; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } location /media/ { alias /www/elderly_service/media/; } }注意前端静态文件上传的图片也就是/media路径这部分必须单独配置alias指向Django的MEDIA_ROOT目录否则图片无法访问。这是我部署时踩到的第一个坑。第二个坑是Django的ALLOWED_HOSTS必须加上域名或服务器IP否则浏览器访问时Django直接返回400错误。第三个坑是数据库用MySQL时需要确保服务器上的MySQL开启远程访问或者本地socket连接正常用pymysql配合时注意字符集设置否则中文乱码。如果数据库想用云厂商的托管数据库比如阿里的RDS也可以只需要在settings里把HOST改成数据库内网地址即可但要注意安全组放行3306端口。6. 常见问题排查与避坑指南6.1 环境配置阶段的高频问题环境和依赖这一块几乎每个来问我的人都会遇到同样的问题。我把最常见的几个列成表方便自查问题现象可能原因解决方法python命令找不到安装时没勾选Add to PATH重新安装Python并勾选或手动配置环境变量pip安装慢或超时默认源是国外源换镜像源pip install -i https://pypi.tuna.tsinghua.edu.cn/simple 包名Django命令找不到没激活虚拟环境激活venv后再执行命令或检查PyCharm解释器是否选对npm run dev报错Node版本过低升级Node到18以上Vite要求较高版本数据库中文乱码MySQL字符集不是utf8mb4创建数据库时指定charsetutf8mb4连接串加charset参数还有一个很常见的坑是Django版本和第三方库不兼容。比如django-cors-headers对Django版本有要求如果你用最新版Django 5.x有些老版本第三方库可能不支持最好统一用较新的版本组合。我在项目初期就用错了版本后来全部用pip freeze锁定了版本号才把环境稳定下来。6.2 数据库与模型相关的坑数据库迁移这个操作新手最怕的就是makemigrations之后发现改了模型迁移文件却冲突。我的经验是每次改模型后马上执行makemigrations和migrate不要攒着改好几处再来迁移。还有生产环境的数据库迁移一定要先备份再操作。Django里执行删除对象比如删除一条评论comment Comment.objects.get(id1) comment.delete()看似简单但要注意在外键没有设置on_deletemodels.CASCADE的情况下删除父表数据会报ProtectedError如果设置了CASCADE会连带删除子表数据。在预约系统里删除服务项目时如果还有历史预约单指向它会导致预约单数据丢失。所以我对核心业务表都尽量用on_deletemodels.SET_NULL或者只做软删除加一个is_active字段历史数据不能随便物理删。另外非常建议在数据库表里加入created_at和updated_at字段Django中可以用auto_now_add和auto_now自动维护这对排查数据问题和做统计都极其有用我早期没加后来返工补上的。6.3 前后端联调的典型问题联调阶段最常见的就是跨域和接口格式不一致。跨域问题前面已经提到了。这里补充一个细节用django-cors-headers时如果前端请求带了自定义Header比如AuthorizationCORS_ALLOW_HEADERS里要加上对应Header名否则仍然会被浏览器拦截。Django开发的Native过程中可以在浏览器开发者工具的Console里看到具体的跨域报错信息顺着那条信息排查速度最快。接口格式不一致这个问题更隐蔽。比如后端返回的日期格式是2024-06-01T10:30:00ZISO 8601前端想在页面上显示成6月1日 10:30直接拿来显示肯定不对。我的做法是后端序列化器里按前端需要的格式返回class ReservationSerializer(serializers.ModelSerializer): service_time serializers.DateTimeField(format%Y-%m-%d %H:%M)但这样做的坏处是后端被前端显示格式绑架换个前端就废了。更好的方式是后端返回原始格式前端在展示层统一格式化。我最后采用了前端方案在Vue组件里写一个formatTime过滤器统一把ISO字符串转成中文格式。这样做的好处是同一个接口给PC端和移动端复用各端自行决定怎么显示。还有一个非常容易踩的坑是HTTP状态码的语义。我见过不少同学后端不管什么错误都返回200在响应体里放个code字段来区分。这种做法不是不行但会让前端axios拦截器写起来很别扭。我建议遵循RESTful风格成功返回200/201参数错误返回400未认证返回401权限不足返回403资源不存在返回404服务异常返回500。这样axios统一拦截异常前端逻辑会清爽很多。6.4 部署上线的坑静态文件、域名和进程守护部署阶段的问题和开发阶段完全不一样。除了前面Nginx配置那三个坑还有几个实际运维中特别重要的点。第一个是Django静态文件收集。Django框架需要执行collectstatic命令把admin后台的静态文件复制到STATIC_ROOT指定的目录否则你Django自带的admin后台页面没有样式全是裸HTML。这个命令在每次部署前都要重新执行。第二个是进程守护问题。直接用gunicorn启动的服务SSH断开后进程就死了。我用了Supervisor管理gunicorn进程配置了开机自启和自动重启。这样即使机器重启或进程崩溃后端服务也能自动恢复。第三个是HTTPS。现在很多浏览器对非HTTPS域名会有安全隐患提示尤其是涉及登录、支付功能的项目。如果想让系统正式上线建议在宝塔面板里一键申请SSL证书并开启强制HTTPS。等以后要做移动端小程序或App时HTTPS是硬性要求后面改造的成本会高不少。结尾这套系统的后续价值与个人体会这个项目做完之后我自己最大的体会是技术选型真的不要太追求“酷炫新框架”稳定、熟悉、社区成熟的组合才是做项目的王道。Vue加PythonFlask或Django这套组合从开发效率、学习资料丰富度、就业简历友好度来看都是非常稳的选择。尤其对准备做毕业设计的同学来说这套系统从需求到设计再到实现的完整链路本身就是一个很好的项目亮点面试时能讲清楚状态机设计、权限控制、跨域处理这些细节比光说“我做了个XX系统”有说服力得多。最后再分享一个小技巧像这种前后端分离的项目一定要养成写接口文档的习惯。我项目初期偷懒没写前后端联调时沟通成本极高后来用DRF自带的文档接口配合简单说明效率提升非常明显。如果你用的是Flask建议用flask-restx或自己维护一个Markdown接口文档不然等代码量增长后你自己都记不住哪个接口返回什么格式。从这个角度说Django REST Framework的自动文档功能也是我最终选择Django而不是Flask的重要理由之一。希望这篇记录能给正在做同类项目的你实实在在的帮助。
