基于Django+Vue的宠物医院管理系统设计与实现全解析

1. 这个项目到底在做什么：需求梳理与技术选型

Python+Vue的宠物医院设计与实现，这个标题一出来，懂行的都知道是毕设/课设的经典命题。但经典不等于简单，我见过太多人在Django和Flask之间反复纠结，或者在Vue前端联调阶段痛苦挣扎两星期。这篇文章打算把从需求拆解到技术选型、从数据建模到前端联调的全过程摊开讲清楚，给准备做同类管理系统的朋友一条能直接照着走的路。

先解决第一个问题：宠物医院系统到底要管哪些事？别急着写代码，先花半天把业务跑一遍。宠物主人带着猫狗进门，前台先建档——记录主人电话、宠物名字、品种、年龄、疫苗情况；然后挂号，选择科室（内科、外科、眼科、美容）和值班医生；医生接诊后在系统里写病历，包含主诉、检查结果、诊断结论、处方用药；宠物主人最后去收费处结算。这一套流程走完，系统的模块就出来了：档案管理、挂号预约、病历处方、药品收费，再加上登录权限和统计报表，就是一个完整的业务闭环。

1.1 核心模块与角色划分

系统至少有三类角色：前台、医生、管理员。有的规模大一点会拆出药房和收费员，但对一个毕设级别的项目，合并成三类就够了。不同角色看到的页面和操作权限不一样，这直接决定前端路由结构和后端接口的数据过滤。前台能建档、挂号、收银；医生只能看到待诊列表和病历编辑；管理员额外看统计报表和用户管理。把角色想清楚，后面权限控制的所有代码都在围绕这个展开。

模块划分建议按下面这张表来，它跟论文里的"功能需求分析"也能对上：

• 宠物档案：主人信息（姓名、电话、住址）、宠物信息（昵称、品种、种类、性别、绝育状态、疫苗记录）
• 挂号管理：科室、医生、号源时段、挂号状态（待诊/看诊中/已完成/已取消）
• 病历管理：主诉、检查项、诊断、医嘱、处方明细
• 药品与收费：药品字典、收费项目、结算记录
• 统计报表：日营收、挂号量、宠物种类分布
• 系统管理：用户、角色、菜单权限

这套模块边界一旦定下来，后续的模型、接口、页面全都围绕这条主线展开，不会出现"做着做着不知道下一步干嘛"的情况。

1.2 Django还是Flask：我的选型思路

标题里两个框架都写了，说明前期定题目的时候还没想清楚，等到真开工必须二选一。我的结论很明确：这种带多个实体、有权限管理、有后台维护需求的业务系统，优先选Django。两个框架直觉上差不太多，但真做起管理系统来，差距很明显：

几个直观的理由帮你做决定。第一，Django自带ORM、Admin后台、迁移机制和用户认证，这四个能力恰好全是管理系统的刚需。Flask也不是不能做，但"要什么装什么"的模式意味着你要花大量时间评估和配置第三方扩展。第二，DRF在后端接口上优势巨大，序列化器处理参数校验和字段转换，ViewSet直接生成CRUD接口，一个模块的接口开发量能压缩到半天。第三，社区资料厚，毕设里遇到的坑随便一搜就有答案，对新手极其友好。

如果你的核心需求只是快速出几个轻量接口，Flask当然更快，灵活性也是它最大的资本。但在这个项目里，业务表有七八张，且涉及权限、状态流转、统计，用Django的约定式开发比Flask的自由发挥稳得多。关于Flask我只说一句：它适合给懂行的人用来快速搭小服务，不适合从零搭一个全栈管理系统。

1.3 PyCharm环境和依赖管理

开发工具用PyCharm没问题，专业版对Django和Vue的工程支持更完整，有模板识别、数据库面板，但社区版也完全够用，别在激活这件事上浪费时间。新开项目建议装Python 3.10左右的稳定版本，直接用项目自带的venv建虚拟环境，别把包装到全局环境里，不然以后切换项目，版本冲突会让人崩溃。

建立虚拟环境后，一条命令装齐基础依赖：

pip install django djangorestframework django-cors-headers pymysql

PyMySQL是为了给Django连MySQL预留的，如果你图省事直接用默认的SQLite也行，后面数据量大了再切MySQL，Django ORM层的差异很小，只需要改settings里的DATABASES配置。这一步做完，跑一下django-admin startproject和python manage.py runserver，确认默认页面能打开，后端骨架就算立住了。

2. 数据模型设计：把业务翻译成表

系统能不能撑起来，模型设计占六成功力。我真见过有人把宠物、主人、挂号全塞进一张大表里的，后期查询、统计全部绕着弯走。这一节把核心表结构和Django模型代码说清楚，你可以直接参考。

2.1 核心表结构与关系

表设计围绕业务对象拆，至少要有这些：

关键关联一句话概括：一个主人可以养多只宠物，一只宠物可以多次挂号，一次挂号对应一份病历，一份病历挂多个药品或收费项目，结算记录绑定挂号单。这些一对多关系如果建错了，后面写查询条件时会非常别扭，所以建模阶段值得多花点心思画一张关系图，哪怕只是手绘。

2.2 Django模型定义参考

直接给核心模型的写法，去掉无关字段保持精简：

from django.db import models from django.contrib.auth.models import User class PetOwner(models.Model): user = models.OneToOneField(User, on_delete=models.CASCADE, related_name='owner') phone = models.CharField(max_length=11, unique=True) address = models.CharField(max_length=200, blank=True) created_at = models.DateTimeField(auto_now_add=True) class Pet(models.Model): owner = models.ForeignKey(PetOwner, on_delete=models.CASCADE, related_name='pets') name = models.CharField(max_length=50) species = models.CharField(max_length=30) # 猫/狗/其他 breed = models.CharField(max_length=50, blank=True) gender = models.CharField(max_length=10, choices=[('male', '公'), ('female', '母')]) birthday = models.DateField(null=True, blank=True) weight = models.DecimalField(max_digits=5, decimal_places=2, null=True, blank=True) class DoctorProfile(models.Model): user = models.OneToOneField(User, on_delete=models.CASCADE, related_name='doctorprofile') department = models.CharField(max_length=50) title = models.CharField(max_length=20, blank=True) class Registration(models.Model): STATUS_CHOICES = [(0, '待诊'), (1, '看诊中'), (2, '已完成'), (3, '已取消')] pet = models.ForeignKey(Pet, on_delete=models.CASCADE, related_name='registrations') doctor = models.ForeignKey(DoctorProfile, on_delete=models.PROTECT, related_name='registrations') status = models.IntegerField(choices=STATUS_CHOICES, default=0) appointment_date = models.DateTimeField() created_at = models.DateTimeField(auto_now_add=True)

这里有几个容易踩的细节，我当年都犯过。

第一，金额和重量这种数值必须用DecimalField，别用FloatField。浮点数在结算时会出现0.1+0.2不等于0.3的经典问题，财务数据一旦出现分角误差，排查起来极其恶心。DecimalField会在Python和数据库层都做定点运算，虽然多占一点空间，但安全得多。

第二，外键的on_delete参数要想清楚。挂号单如果已经关联了结算记录，挂号取消时结算数据不该被物理删除，应该留着做账，所以Registration里对doctor用PROTECT，对pet用CASCADE，含义是：宠物档案删了，底下挂号记录跟着删，但医生用户不允许被随便删。这个语义不是随便选的，它背后是财务数据的完整性约束。

第三，状态字段用IntegerField加choices，别用字符串。字符串"待诊"和"待診"这种全角半角差异、大小写差异，都会变成线上bug。用choices加数字，代码里引用常量，显示时用get_status_display()取中文名称，干净利落。

2.3 基础数据初始化：别让页面空转

模型写完就是makemigrations和migrate，这个不多说。要提醒的是创建完超级用户后，先把字典数据录进去：科室、医生、药品、收费项目。没这些基础数据，前端页面跑起来全是空的，调试接口也没有意义。Django的Admin后台正好在这里派上用场，注册一下模型就能直接录入：

from django.contrib import admin from .models import PetOwner, Pet, Registration admin.site.register(PetOwner) admin.site.register(Pet) admin.site.register(Registration)

这一步千万别偷懒。Admin后台不仅能录基础数据，还是你联调阶段最好的"数据工厂"——前端还没开发完的时候，你可以直接用Admin把业务数据填起来，再用Postman调接口验证逻辑。省掉这个环节，后面每写一个页面都要手工造数据，效率会低很多。等前端开发完，这些数据正好变成页面上真实的演示内容，一举两得。

3. 后端接口建设：DRF把业务逻辑挂起来

模型只是地基，真正被前端调用的是接口。强烈建议用DRF，不要在手写views里用JsonResponse拼字段。一个序列化器就能帮你把模型字段转JSON、参数校验、嵌套关联、只读字段全处理掉，省下的时间远大于学习它的成本。

3.1 序列化器：让接口返回好看的数据

以挂号单为例，前端提交时只需要pet、doctor、appointment_date这些字段，但列表页展示时最好直接带上宠物名、主人电话、医生姓名。嵌套序列化和SerializerMethodField都能做，用source是更简洁的写法：

class RegistrationSerializer(serializers.ModelSerializer): pet_name = serializers.CharField(source='pet.name', read_only=True) owner_phone = serializers.CharField(source='pet.owner.phone', read_only=True) doctor_name = serializers.CharField(source='doctor.user.username', read_only=True) class Meta: model = Registration fields = ['id', 'pet', 'pet_name', 'owner_phone', 'doctor', 'doctor_name', 'appointment_date', 'status']

新手最容易卡住的是三个地方：source的取值路径、read_only的含义、关联字段的读写分离。我的建议是，凡是前端需要展示的关联字段，一律用source在序列化器里先带出来，避免前端拿着外键id再发请求查名字，造成N+1请求。前端少发一轮请求，后端自然少一轮压力，响应也更快。

3.2 视图集：CRUD和自定义逻辑分开

CRUD接口直接用ModelViewSet，自定义业务逻辑放在action里。比如"今天所有挂号"这个典型的自定义接口，可以这样写：

from rest_framework import viewsets from rest_framework.decorators import action from rest_framework.response import Response from django.utils import timezone class RegistrationViewSet(viewsets.ModelViewSet): queryset = Registration.objects.select_related('pet', 'pet__owner', 'doctor').all() serializer_class = RegistrationSerializer @action(detail=False, methods=['get']) def today(self, request): today_regs = self.get_queryset().filter( appointment_date__date=timezone.localdate() ) data = self.get_serializer(today_regs, many=True).data return Response(data)

这里涉及一个查询性能的做法：用select_related把外键对象一次性取出来，否则列表页每次渲染都要触发大量SQL查询，数据量小看不出差异，一旦上线立刻原形毕露。用ORM时养成习惯，关联查询能一次取就别分多次，这在任何业务项目里都是最基本的要求。

另外，挂号涉及号源占用，虽然毕设阶段不强调并发，但我建议用事务把逻辑写规范。创建挂号时，先查时段剩余号数，再插入记录，整个过程包在transaction.atomic()里，防止两个人同时挂号时超卖号源。这个设计在答辩时被问到的概率很高，答上来说明你对并发安全有概念，会是明显的加分项。

3.3 权限控制：按角色返回数据

Django自带的认证体系配合DRF的permission_classes就能覆盖大部分需求。JWT用djangorestframework-simplejwt扩展，登录接口返回access和refresh token，前端存到本地。接口侧按角色限制数据的标准做法是重写get_queryset：

from rest_framework.permissions import IsAuthenticated class RegistrationViewSet(viewsets.ModelViewSet): permission_classes = [IsAuthenticated] def get_queryset(self): user = self.request.user if user.is_staff: return Registration.objects.all() if hasattr(user, 'doctorprofile'): return Registration.objects.filter(doctor=user.doctorprofile) return Registration.objects.filter(pet__owner__user=user)

这套模式比在前端隐藏栏目要干净得多。记住一个原则：接口返回的数据面要跟着用户身份走，敏感数据在服务端就过滤掉，不要一次把所有数据丢给前端再指望它不乱显示。权限控制的核心不是"隐藏"，是"服务端根本不给你"。

4. 前端Vue实现：把系统做成能用的界面

后端接口供好，前端就可以并行开发了。Vue这套东西，好多人卡在环境搭建上，其实核心就几步：装Node、配镜像、用Vite创建项目、装Element Plus组件库，然后就是路由、状态管理、接口封装。别再纠结Vue 2还是Vue 3，直接上Vue 3加Vite，生态已经成熟到不需要回头看了。

4.1 项目初始化和工程目录

创建项目很简单，真正重要的是目录结构。我自己习惯这样分层：

• src/router：路由配置，含静态路由和动态路由
• src/api：按业务模块拆分的接口文件
• src/views：页面组件
• src/components：公共组件
• src/store：Pinia状态管理
• src/utils/request.js：axios实例封装

这个结构的核心好处是接口层和视图层分离。后端接口变了，多数时候只改src/api下的文件，页面不跟着动。项目规模变大后，这种"接口收口"的维护价值会越来越明显。尤其是宠物医院这种多模块管理系统，挂号、病历、收费、统计都在各自文件里管理，后期定位问题非常快。

4.2 Axios封装与登录态

axios封装是每个Vue项目都绕不开的一件事。实际项目里，几乎每个请求都要带token、处理超时、统一报错提示。如果每个页面都手写一遍config和catch，代码很快就会烂掉。封装一个request实例，让所有请求从这里走：

const service = axios.create({ baseURL: import.meta.env.VITE_API_BASE || '/api', timeout: 10000 }); 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) { router.push('/login'); } return Promise.reject(error); } );

这里有两个细节很多人吃过亏。第一，路由如果用了history模式，后端必须把非API请求都转发到index.html，否则刷新页面就是404，这个在第5.3节具体说。第二，401拦截跳转要放在响应拦截器里，并且要避开登录接口本身，否则登录失败也会触发跳转，造成死循环。简单做法是给登录接口的request单独配置一个skipAuth标志，拦截时判断一下。

4.3 核心业务页面怎么做

前端业务页面上，挂号、病历、收费三个页面是核心。

挂号页面流程是：搜索宠物主人、选宠物、选科室和医生、选日期时段、提交。用Element Plus的Form加级联选择器基本能搞定。但要注意，搜索主人要走后端模糊查询接口，按姓名或电话查，不要在本地把所有数据拉下来再filter。数据量一大，本地filter就卡成PPT。

病历页面最麻烦的地方是动态表单：不同科室的检查项不一样，眼科和皮肤科的模板完全不同。简单方案是前端预设几个模板字段切换；想做得有深度，可以建一张检查项模板表，病历按模板动态生成字段，提交时存成JSON。毕设用前者足够，但后者写进论文里能明显撑高技术深度。

收费页面绑定挂号单，展示处方明细，前端只读展示，确认后调结算接口。这里提醒一句：金额展示一律用后端返回的字符串，不要在前端做浮点累加。我给别人做的项目里出现过前端四舍五入导致分时段对账对不上的情况，后来全部改成后端算金额、前端只做展示，问题才彻底消失。

4.4 路由守卫与角色菜单

登录后的跳转判断用Vue Router的beforeEach守卫，读取本地token决定是否放行。角色菜单的规范做法是后端返回菜单数据，前端根据角色动态渲染Sidebar，再用addRoute动态注册权限路由。简单做法是把路由表按角色拆成两套，登录后根据角色信息动态挂载。

无论哪种方案，路由守卫都必须在白名单里放行/login和/register这类公共页面。带参数的路由判断时要匹配路径前缀而不是精确相等，比如"/record/:id"要写path.startsWith('/record')，不然动态参数页面会被误拦，用户刷新一下就跳登录页，体验极差。

5. 联调与部署：真正让系统跑起来

代码写完了不等于项目能跑，前后端联调往往是最耗时的一环。这块单独讲，因为踩坑的价值比前面任何一章都高。

5.1 CORS跨域：不是加一个头就完事

开发环境下前端跑在5173端口，后端跑在8000端口，端口不同就天然跨域。后端装django-cors-headers再配置：

CORS_ALLOWED_ORIGINS = [ "http://localhost:5173", "http://127.0.0.1:5173", ]

配置看着简单，坑都在细节里。第一个，如果部分接口用session认证而不是JWT，也就是请求要携带cookie，只配ALLOWED_ORIGINS还不够，必须CORS_ALLOW_CREDENTIALS = True，而且allowed origins不能是"*"字符串。第二个，本地测试时填了http://localhost:5173，但实际浏览器访问的是http://127.0.0.1:5173，这俩在CORS规则里是完全不同的origin，照样跨域失败。所以配置里最好两个都写上，省得来回切换地址时莫名报错。

注意：CORS的调试非常容易自欺欺人。报错时先看浏览器Network面板里请求的Origin头到底是什么，再去对settings里的白名单，别瞎试。

5.2 时间字段和空值：两类经典问题

Django的DateTime默认序列化格式是ISO字符串，带T和微秒，比如"2024-05-20T14:30:00.123456+08:00"。Element Plus的DatePicker不一定能直接解析这种格式，显示出来要么多一位毫秒，要么直接报错。在settings里统一格式能省掉一堆麻烦：

REST_FRAMEWORK = { 'DATETIME_FORMAT': '%Y-%m-%d %H:%M:%S', 'DATE_FORMAT': '%Y-%m-%d', }

定好之后，前端拿到的是"2024-05-20 14:30:00"这种标准格式，直接可以展示。另一个高频问题空值：后端返回null，前端组件经常撑不住，要么显示个"null"，要么调用undefined方法报错。我的习惯是接口层尽量给默认值，比如"未填写"，前端展示前再统一做一次空字符串兜底，两个方向都堵住，基本就能杜绝空值bug。

5.3 打包部署：把Vue塞进Django

答辩前通常要把系统打包成一个整体。Vue项目执行npm run build产生dist目录，把dist里的静态文件复制到Django项目的一个static/dist目录，并在settings里配置STATICFILES_DIRS。然后在主路由的urls.py里加兜底路由：

from django.urls import re_path from django.views.generic import TemplateView urlpatterns = [ # 其他API路由... re_path(r'^.*$', TemplateView.as_view(template_name='index.html')), ]

这个正则的意图是：除已配置的API路径外，所有前端路由请求全部交给index.html，然后由Vue Router接管后续跳转。注意兜底路由必须放在urlpatterns的最后，否则会吞掉所有API请求。如果你的API路径统一挂在/api前缀下，这个方案很安全；如果Django接口直接暴露在根路径，就会被这个正则抢走，出大乱子。

前端history模式的刷新404问题，正靠这个兜底路由解决。更正规的部署方式是Nginx托管dist，再反向代理/api到Django，适合真正的服务器环境，但答辩演示直接用Django托管最省事，一个进程就能跑起来。

6. 复盘与扩展方向

项目能跑通只是第一步。作为毕设或作品集项目，最终呈现出的完整度决定它值多少钱。

6.1 从演示项目到可用系统，差距在哪

我看过不少同类毕设，有一个通病：功能列表很全，但缺少真实业务里最看重的过程性约束。比如挂号，演示项目可能只是insert一条记录，但真实系统要处理号源并发、退号后号源释放、迟到状态变更、收费后状态锁定这一串流程。把这些约束体现到代码里，哪怕只是多几个状态判断和一个事务，系统含金量立刻不一样。

另一个细节是演示数据。答辩时界面上出现一只叫"测试猫"的宠物，印象分会打折扣。造一套看起来像真的数据——主人姓名、电话、宠物品种、病历描述都编得像样一点。这个细节很多人忽略，但给答辩老师的观感影响其实很大。

6.2 还能扩展什么方向

基础功能做完还有余力的话，这三个方向性价比最高。

第一个，用Django Channels做WebSocket推送，比如医生端实时收到新挂号通知，不用手动刷新页面。这个技术点和现在后端实时推送的需求正好对上，也足够作为论文的创新点。第二个，做数据可视化看板，把营收趋势、科室挂号占比、宠物品种分布用ECharts展示，后端给统计接口就行，前端工作量也不大。第三个，移动端适配，用uni-app套壳一个H5版，满足"随时查看预约"这类需求。

这些都是独立的加分项，挑一两个做深，比把十个模块都做成半吊子强得多。

我当时做完这个项目的体会是：一个宠物医院管理系统看似普通，但完整覆盖了业务建模、权限控制、前后端协作、事务处理、部署配置这几个软件开发里最核心的环节，麻雀虽小五脏俱全。完整做一遍比抄十个项目模板都更能建立对全栈开发的整体认知。如果你正卡在某个环节，按这个顺序排查：先看数据模型是否符合业务逻辑，再看接口返回是否满足前端需要，最后查跨域和路由配置，九成的问题都出在这三层里面。