接手这个“django基于python的流浪宠物领养管理系统”项目时我其实没有把它当成一个普通的课程设计或者毕业设计来做。市面上这类“宠物领养系统”模板一大堆但绝大多数都停留在“注册登录 宠物列表 提交表单”的层面真正把领养流程、审核机制和用户权限理顺的非常少。我自己早年帮某机构做过一个类似的救助站管理系统踩过不少坑所以这次决定用Django把整套逻辑完整地做出来从数据库建模到权限控制从领养申请到后台审批全部走一遍。这篇博文就是把整个项目的设计思路、关键技术点和实操过程整理出来给准备做同类系统的朋友一个可以直接参考的范本。先说一下这套系统最终能做什么管理员可以录入流浪宠物信息、维护领养公告、审核领养申请普通用户可以浏览宠物档案、提交领养意向、查看申请进度游客只能看基础信息无法提交申请。整个系统分为前台展示和后台管理两大部分前台面向公众后台面向管理员。技术上用的是Python 3 Django我这次用的4.x版本 SQLite起步后期可以平滑切换到MySQL。1. 系统整体设计与技术选型1.1 为什么用Django而不是Flask或Node选型这件事我基本没有犹豫。Django自带Admin后台、ORM、表单处理、认证体系和模板引擎这些对一个管理信息系统来说都是刚需。你要是拿Flask来做用户认证要自己写Admin后台要自己搭文件上传要自己配工作量翻倍不说安全性还容易出纰漏。Django把那些“每个项目都要重复一遍”的东西都内置好了我只需要把精力放在业务逻辑上。对比一下就更清楚了技术栈开发效率自带后台ORM适合场景Django Python高有完整Admin成熟稳定管理类系统、CMS、业务平台Flask Python中无自带后台可集成SQLAlchemy轻量接口、微服务Node Express中无Mongoose/Sequelize实时应用、前后端分离API这次项目我用了Django 4.2版本分应用开发整个工程分成“宠物管理”“用户中心”“领养申请”“公告系统”几个模块每个模块一个独立的Django App。这样后期扩展功能时不会把代码搅成一锅粥。1.2 项目目录结构规划一个清晰的目录结构能省掉后面80%的麻烦。我习惯在项目初期就把目录规划好而不是边写边改。下面是我在实际项目里使用的结构pet_adoption/ ├── manage.py ├── requirements.txt ├── config/ │ ├── settings.py │ ├── urls.py │ └── wsgi.py ├── apps/ │ ├── accounts/ # 用户注册登录、个人中心 │ ├── pets/ # 宠物档案管理 │ ├── adoption/ # 领养申请与审核 │ └── announ/ # 公告与新闻 ├── static/ │ ├── css/ │ ├── js/ │ └── images/ ├── media/ # 宠物图片上传目录 ├── templates/ │ ├── base.html │ ├── index.html │ ├── accounts/ │ ├── pets/ │ ├── adoption/ │ └── announ/ └── requirement.txt把App都放到apps目录下是我个人的习惯主要是为了让项目根目录干净一点App多了以后更好管理。config目录用来放全局配置和根路由media目录用来存放上传的宠物照片这些路径在settings.py里要提前配好不然生产环境会出现图片无法访问的问题。1.3 核心需求拆解这个项目的核心流程并不复杂但涉及的交互比较多。我把需求拆成四条主线和三条辅助线游客浏览查看首页、宠物列表、宠物详情、公告信息不需要登录。用户领养注册登录后浏览宠物详情并提交领养申请填写申请理由、居住情况、养宠经验。管理员审核在后台审核领养申请通过的申请进入“待领养”状态宠物被领养后下架。信息发布管理员发布宠物档案、领养公告、成功案例等。辅助功能包括用户个人中心的申请记录查看、收藏宠物、修改个人资料、密码重置等。这里我特别想强调一点领养申请必须要有审核流程不能提交了就完事。很多山寨系统就是一张表单丢到数据库里管理员连审核入口都没有这种系统做出来没有实际价值。我在设计时把申请状态设计成“待审核、已通过、已拒绝、已完成”四种每个状态变化都记录时间这样管理员和用户都能看到完整的流程进度。2. 数据库设计与核心模型2.1 数据表关系梳理数据库是整个系统的地基。我画了一下核心数据表的关系用户表自定义User模型、宠物表Pet、领养申请表AdoptionApplication、公告表Announcement、收藏表Favorite。表与表之间的关系我在这里直接说清楚一个宠物属于一个分类分类就是“猫、狗、其他”这种。一个用户可以提交多个领养申请但同一只宠物在“待审核/已通过”状态下不允许第二个用户重复申请。一个用户可以收藏多只宠物宠物和用户之间是多对多关系。公告表独立存在只由管理员操作。2.2 自定义用户模型Django自带的User模型能用但为了后续扩展性我强烈建议从一开始就自定义用户模型用AbstractUser继承。为什么因为在做这个领养系统时至少要给用户加上“联系电话”和“所在城市”这两个字段这些是线下交接宠物时必须的信息。如果默认模型已经迁移过数据库后期再改用户模型会非常痛苦。自定义用户模型代码如下from django.contrib.auth.models import AbstractUser from django.db import models class User(AbstractUser): phone models.CharField(max_length11, blankTrue, verbose_name联系电话) city models.CharField(max_length64, blankTrue, verbose_name所在城市) avatar models.ImageField(upload_toavatar/, blankTrue, verbose_name头像) created_at models.DateTimeField(auto_now_addTrue, verbose_name注册时间) class Meta: db_table user verbose_name 用户设置文件里别忘了加一行AUTH_USER_MODEL accounts.User这个配置必须在第一次migrate之前设置好否则后续改动需要重置数据库那真叫一个哭爹喊娘。2.3 宠物档案模型设计宠物档案是整个系统信息量最大的数据表。除了基本信息还要考虑状态流转。我设计的字段如下class Pet(models.Model): STATUS_CHOICES ( (available, 待领养), (adopted, 已领养), (pending, 待交接), ) name models.CharField(max_length32, verbose_name宠物昵称) category models.CharField(max_length16, choices((cat, 猫咪), (dog, 狗狗), (other, 其他)), verbose_name类别) breed models.CharField(max_length32, blankTrue, verbose_name品种) age models.IntegerField(default1, verbose_name年龄(岁)) gender models.CharField(max_length8, choices((M, 男孩), (F, 女孩)), defaultM, verbose_name性别) health_status models.TextField(blankTrue, verbose_name健康状况) story models.TextField(blankTrue, verbose_name救助故事) cover_image models.ImageField(upload_topets/, verbose_name封面图片) status models.CharField(max_length16, choicesSTATUS_CHOICES, defaultavailable, verbose_name状态) created_at models.DateTimeField(auto_now_addTrue, verbose_name发布时间) class Meta: db_table pet verbose_name 宠物档案这里有几个细节值得注意。status字段不要用布尔值“是否被领养”因为领养过程有中间状态——申请通过了但宠物还没被接走这个阶段叫“待交接”。只用布尔值会丢失关键信息后面做状态筛选就很费劲。2.4 领养申请表模型领养申请表是连接用户和宠物的核心桥梁设计质量直接决定审核流程能不能顺畅跑起来。我加了几个跟实际救助工作强相关的字段class AdoptionApplication(models.Model): STATUS_CHOICES ( (pending, 待审核), (approved, 已通过), (rejected, 已拒绝), (completed, 已完成), ) user models.ForeignKey(User, on_deletemodels.CASCADE, verbose_name申请人) pet models.ForeignKey(Pet, on_deletemodels.CASCADE, verbose_name申请宠物) reason models.TextField(verbose_name领养理由) has_experience models.BooleanField(defaultFalse, verbose_name有无养宠经验) family_agreement models.BooleanField(defaultTrue, verbose_name家人是否同意) address models.CharField(max_length128, verbose_name居住地址) status models.CharField(max_length16, choicesSTATUS_CHOICES, defaultpending, verbose_name审核状态) created_at models.DateTimeField(auto_now_addTrue, verbose_name申请时间) reviewed_at models.DateTimeField(nullTrue, blankTrue, verbose_name审核时间) remark models.TextField(blankTrue, verbose_name审核备注) class Meta: db_table adoption_application unique_together (pet, user)unique_together这个约束我用在了这让“同一用户对同一宠物只能提交一次申请”。如果不加这个约束用户重复提交申请会导致后台审核出现一堆冗余记录。当然被拒绝后是否允许重新申请这个需求我实现了分支判断在视图里单独处理而不是直接靠唯一约束锁死。3. 核心功能模块与实现要点3.1 用户注册、登录与权限控制用户模块我分了三个角色游客、普通用户、管理员。管理员就是is_staffTrue的用户用Django自带的认证系统就够了。不过登录后的跳转逻辑需要自己写一下。注册这块我额外接了验证码用的是Pillow生成的图片验证码。虽然是老技术但简单可靠能挡住大部分恶意注册脚本。视图逻辑大致是from django.contrib.auth import login from .forms import RegisterForm def register(request): if request.method POST: form RegisterForm(request.POST) if form.is_valid(): # 验证码校验 code request.session.get(captcha_code) input_code form.cleaned_data.get(captcha) if code and code.lower() input_code.lower(): user form.save(commitFalse) user.set_password(form.cleaned_data[password]) user.save() login(request, user) return redirect(pet_list) else: form.add_error(captcha, 验证码错误) else: form RegisterForm() return render(request, accounts/register.html, {form: form})权限控制上我用了Django自带的login_required装饰器没有登录的用户访问提交申请页面时会被自动弹回登录页。这个方案成熟、安全比自己在视图里判断request.user.is_authenticated靠谱得多。3.2 宠物信息的展示与筛选宠物列表页面做了三块内容搜索框、分类筛选、卡片式宠物列表。搜索功能我直接用ORM的icontains做模糊查询虽然数据量大以后效率一般但对于这种小型系统完全够用没必要上来就上Elasticsearch。def pet_list(request): pets Pet.objects.filter(statusavailable) keyword request.GET.get(keyword, ) category request.GET.get(category, ) if keyword: pets pets.filter(name__icontainskeyword) if category and category in dict(Pet.STATUS_CHOICES): pets pets.filter(categorycategory) return render(request, pets/pet_list.html, {pets: pets})这里有个小坑首页只展示“待领养”状态的宠物时如果直接用Pet.objects.all()会把“已领养”的老档案也展示出来让用户看到一只早被别人领走的宠物体验会很差。所以列表页一律过滤状态。宠物详情页我除了展示基本信息还增加了一个“收藏”按钮和“提交领养申请”按钮。收藏按钮通过AJAX异步请求实现不用刷新整个页面。领养申请按钮则判断当前用户是否登录未登录时弹窗提示去登录。3.3 领养申请流程的实现领养申请是整个系统的业务核心。我的流程是用户进入宠物详情页点击“申请领养”。系统检查用户是否登录、宠物是否处于“待领养”状态。检查用户是否已经提交过该宠物的申请防止重复提交。通过检查后跳转到申请表单页。用户填写领养理由、是否有养宠经验等信息提交。状态变为“待审核”管理员在后台处理。审核通过后宠物状态变为“待交接”用户和管理员可以协商线下交接。交接完成后管理员把申请状态改为“已完成”宠物状态改为“已领养”。login_required def submit_application(request, pet_id): pet get_object_or_404(Pet, idpet_id) if pet.status ! available: messages.error(request, 该宠物当前不可领养) return redirect(pet_detail, pet_idpet.id) existing AdoptionApplication.objects.filter(petpet, userrequest.user) if existing.exists(): messages.warning(request, 您已经申请过这只宠物请等待审核结果) return redirect(pet_detail, pet_idpet.id) if request.method POST: form ApplicationForm(request.POST) if form.is_valid(): app form.save(commitFalse) app.user request.user app.pet pet app.save() return redirect(my_applications) else: form ApplicationForm() return render(request, adoption/apply.html, {form: form, pet: pet})这段代码看起来简单但已经把三种异常情况都堵住了宠物状态不可领养、用户重复申请、表单校验失败。我见过很多项目在业务校验上偷懒结果数据库里出现一堆非法数据后面查问题查到头大。3.4 后台审核功能增强Django自带Admin很好用但原生Admin在处理业务审核时不够直观。我给领养申请在Admin里增加了一个列表筛选和自定义操作class AdoptionApplicationAdmin(admin.ModelAdmin): list_display (pet, user, status, created_at, reviewed_at) list_filter (status,) actions [approve_applications, reject_applications] def approve_applications(self, request, queryset): for app in queryset: if app.status pending: app.status approved app.reviewed_at timezone.now() app.pet.status pending app.pet.save() app.save() approve_applications.short_description 批量通过批量通过的时候连宠物状态一起更新这样管理员不需要进宠物表再改一次状态。批量操作按钮是我在生产中经常用到的功能强烈推荐大家给自己的Admin加上。3.5 公告模块与前端展示公告模块做起来不复杂但它是救助站向公众传递信息的窗口也影响整个系统看起来是否完整。公告模型就三个核心字段标题、正文、发布时间。首页在轮播图和宠物列表之间展示最新三条公告。我顺便做了一个“成功案例”栏目本质上也是公告但多一张配图字段。这个功能是为了鼓励更多人参与领养实际运营中效果很不错。4. 实操过程与核心环节实现4.1 开发环境准备这个项目用的所有依赖我都放在requirements.txt里Django4.2.7 Pillow10.1.0 django-crispy-forms2.1 gunicorn21.2.0开发时用Django自带服务器部署时换成Gunicorn Nginx。数据库先用SQLite方便本地调试发布时切到MySQL只需要改settings.py里的DATABASES配置Django的ORM会帮我们把所有SQL差异抹平。4.2 数据初始化的建议系统刚上线时数据库是空的直接给用户看一个空荡荡的页面非常掉价。我建议做两件事用python manage.py seed_data命令批量生成测试宠物数据脚本里用Faker生成名字、品种、描述。手动创建一个管理员账号把宠物分类等基础数据填好。创建管理员的命令是python manage.py createsuperuser测试数据生成脚本我放到了management/commands/seed_data.py里主要是为了测试列表页、搜索功能和详情页时不用一条条手动添加。注意这个脚本只用于开发环境正式生产环境还是得靠管理员人工录入真实宠物档案。4.3 宠物图片上传与访问配置这是新手最容易踩坑的地方。图片能上传成功但页面死活不显示原因通常是settings.py里的MEDIA_URL和MEDIA_ROOT没配对或者主urls.py没有挂载静态服务。# settings.py MEDIA_URL /media/ MEDIA_ROOT BASE_DIR / media# config/urls.py from django.conf import settings from django.conf.urls.static import static urlpatterns [ # 其他路由 ] static(settings.MEDIA_URL, document_rootsettings.MEDIA_ROOT)还有一点模板里引用图片时一定要用{{ pet.cover_image.url }}不要直接拼/media/ pet.cover_image.name。Django的FileField对象的url属性会帮我们拼接好完整路径手动拼接容易出现问题。开发模式下这个方法没问题部署到Nginx后static()这一行要删掉或者做环境判断否则会暴露静态文件服务。4.4 前端页面响应式处理这套系统虽然以PC端后台管理为主但前台列表页面有大量普通用户会用手机访问所以前端必须做响应式。我选用的方案是AdminLTE框架改前台不前台我用的是纯Bootstrap 5。后台则直接用Django Admin自带界面不额外写HTML。首页、宠物列表、宠物详情、申请表单这几个页面的HTML模板继承同一个base.html导航栏和页脚统一维护。模板引擎用Django自带的DTL不需要换成Jinja2原生的语法完全够用。4.5 邮件通知与提醒用户申请提交后管理员不一定马上登录后台看到项目里我加了一个基础的邮件通知功能申请提交成功后自动发一封邮件给管理员审核通过后发邮件通知申请用户。开发环境下邮件功能可以用console后台输出调试不会真的发出去EMAIL_BACKEND django.core.mail.backends.console.EmailBackend生产环境改成SMTP填入邮箱授权码就可以了。这一步很多人会遗忘但对真实运营场景来说非常重要管理员不可能一直盯着系统后台的。5. 常见问题与排查技巧实录5.1 数据库迁移报错自定义 User 模型后在设置AUTH_USER_MODEL之前如果已经执行过migrate后面会报类似AuthUser.userprofile: relation already exists的错误。这个错误的原因是把系统默认的auth_user表已经建出来了再切换自定义模型时Django不知道如何处理旧表。解决办法是开发初期就设置好AUTH_USER_MODEL然后删除旧的数据库文件开发环境重新迁移。如果已经部署了正式环境就要写数据迁移脚本同步数据麻烦不少。所以再次强调动手写代码前先把用户模型定下来。5.2 图片上传后404跑完python manage.py runserver后访问上传的宠物图片返回404。这个问题我至少见过不下五次原因基本都是MEDIA_ROOT路径配置不对。尤其注意如果BASE_DIR和MEDIA_ROOT拼接使用了相对路径Django的静态文件处理器会找不到目录。还有一种情况是开发时用了static()方法但忘了加document_root参数。第二参数不写Django就不知道去哪里找文件结果404。检查方法很简单打印一下MEDIA_ROOT指向的绝对路径看文件是否真的在那个目录下存在。5.3 重复提交申请测试时发现用户可以绕过前端页面用POST工具重复提交领养申请数据库里出现多条相同用户和宠物的记录。我在模型层加了unique_together约束后再用try-except捕获IntegrityError在视图里做了兜底这样就算绕过前端检查数据库层面也能拦住重复数据。5.4 表单提交后页面刷新报错如果你在帖子提交表单后按F5浏览器会提示“确认重新提交表单”用户点确认后可能导致生成重复的申请记录。这个问题的根源是用普通POST表单提交后页面没有做重定向。正确的写法是Post/Redirect/Get模式视图中处理完POST请求后立刻redirect到结果页面而不是render返回同一个模板。我在提交申请、注册账号、发布公告这几个表单里都严格执行了POST→Redirect→GET的流程。5.5 常见问题速查表现象可能原因解决方案登录后跳转到默认admin页而不是用户页LOGIN_REDIRECT_URL未配置在settings.py加LOGIN_REDIRECT_URL /pets/图片上传成功但列表页不显示MEDIA_URL和MEDIA_ROOT不匹配检查配置并重启服务清缓存Admin列表页出现重复记录缺少unique_together约束在模型中加约束并重新迁移表单提交重复未遵循PRG模式改为POST→Redirect→GET用户注册后无法发送验证邮件邮件后端配置错误开发环境使用console后端验证逻辑部署后静态文件404Nginx未配置静态目录配置location /static/和location /media/5.6 关于防爬虫和恶意提交系统上线后会被各种爬虫扫描注册接口容易被滥用。我做了几个基础防护注册接口加图片验证码。Admin后台URL不放在默认的/admin/路径下改成一个自定义路径在urls.py里用path(manage/, admin.site.urls)这样相对冷门的路径能挡掉一大部分自动化攻击。领养申请接口在服务端校验字段长度和内容不做简单的HTML过滤——用Django模板自动转义就够了。对频繁提交的IP做简单的频率限制用django-ratelimit这个第三方库几行代码就能配好。这些措施虽然不是企业级安全方案但对于一个宠物领养管理平台来说已经能挡住绝大多数恶意行为。6. 部署与环境配置要点6.1 从开发到生产的配置切换开发环境直接跑runserver没问题但生产环境必须用WSGI服务器。我推荐Gunicorn启动命令gunicorn config.wsgi:application --bind 0.0.0.0:8000 --workers 3workers的数量一般是CPU核心数加1不要盲目开更多进程否则内存占用会比较大。前面加上Nginx做反向代理/static/和/media/两个路径直接由Nginx处理静态文件Django只处理动态请求。部署到Linux服务器时settings.py里需要把DEBUG设为FalseALLOWED_HOSTS配置成服务器域名或IP。还有一个关键操作关闭static()的MEDIA路由否则会把资源请求转发给Python进程白白增加负载。6.2 数据库切换从SQLite切换到MySQL需要安装mysqlclient或者pymysql然后在settings.py里改数据库配置DATABASES { default: { ENGINE: django.db.backends.mysql, NAME: pet_adoption, USER: root, PASSWORD: 你的密码, HOST: 127.0.0.1, PORT: 3306, } }执行一下python manage.py migrate如果代码里没有使用SQLite特有的函数模型和数据迁移基本无缝切换。这一步Django的ORM优势体现得特别明显。7. 项目扩展方向与个人经验这套基础版本跑通后可以继续往这几个方向扩展宠物定位与地图服务给救助站宠物增加定位需要接入地图SDK。志愿者招募模块在公告之外增加专门的活动报名流程。微信小程序端把前台移植到小程序Django提供JSON接口。消息推送申请审核结果、宠物状态变化通过短信或微信模板消息通知。数据统计看板用Chart.js做一个后台统计页面展示每日申请量、领养成功率、宠物分类占比。我个人使用中觉得最舒服的一点是Django把这些功能扩展的门槛降得很低。加一个新模块就是“建App、写模型、做模板”三步走老模块几乎不用动。如果你在做类似的系统我建议先从“把核心领养流程彻底跑通”开始不要一上来就贪多。把用户注册、宠物发布、申请审核、状态流转这四个环节做到位系统就已经能用了。后面那些“智能推荐宠物”“实时聊天”功能都是锦上添花先稳住地基最重要。最后说一个我踩过的坑开发时一定要在主settings.py里尽早把时区配好不然created_at记录的时间和本地时间差8个小时排查审核记录时容易把自己绕晕。如果你是第一次做Django项目建议先用SQLite把整个流程跑通不要急着上MySQL。开发调试的速度差异很大等系统稳定了再切换生产数据库一步一个脚印这个项目的坑能少踩一半。 
长河君 · 2026/10/10 4:40:43 · 阅读 1.2k Django流浪宠物领养管理系统：从数据库建模到领养审核实现
接手这个“django基于python的流浪宠物领养管理系统”项目时我其实没有把它当成一个普通的课程设计或者毕业设计来做。市面上这类“宠物领养系统”模板一大堆但绝大多数都停留在“注册登录 宠物列表 提交表单”的层面真正把领养流程、审核机制和用户权限理顺的非常少。我自己早年帮某机构做过一个类似的救助站管理系统踩过不少坑所以这次决定用Django把整套逻辑完整地做出来从数据库建模到权限控制从领养申请到后台审批全部走一遍。这篇博文就是把整个项目的设计思路、关键技术点和实操过程整理出来给准备做同类系统的朋友一个可以直接参考的范本。先说一下这套系统最终能做什么管理员可以录入流浪宠物信息、维护领养公告、审核领养申请普通用户可以浏览宠物档案、提交领养意向、查看申请进度游客只能看基础信息无法提交申请。整个系统分为前台展示和后台管理两大部分前台面向公众后台面向管理员。技术上用的是Python 3 Django我这次用的4.x版本 SQLite起步后期可以平滑切换到MySQL。1. 系统整体设计与技术选型1.1 为什么用Django而不是Flask或Node选型这件事我基本没有犹豫。Django自带Admin后台、ORM、表单处理、认证体系和模板引擎这些对一个管理信息系统来说都是刚需。你要是拿Flask来做用户认证要自己写Admin后台要自己搭文件上传要自己配工作量翻倍不说安全性还容易出纰漏。Django把那些“每个项目都要重复一遍”的东西都内置好了我只需要把精力放在业务逻辑上。对比一下就更清楚了技术栈开发效率自带后台ORM适合场景Django Python高有完整Admin成熟稳定管理类系统、CMS、业务平台Flask Python中无自带后台可集成SQLAlchemy轻量接口、微服务Node Express中无Mongoose/Sequelize实时应用、前后端分离API这次项目我用了Django 4.2版本分应用开发整个工程分成“宠物管理”“用户中心”“领养申请”“公告系统”几个模块每个模块一个独立的Django App。这样后期扩展功能时不会把代码搅成一锅粥。1.2 项目目录结构规划一个清晰的目录结构能省掉后面80%的麻烦。我习惯在项目初期就把目录规划好而不是边写边改。下面是我在实际项目里使用的结构pet_adoption/ ├── manage.py ├── requirements.txt ├── config/ │ ├── settings.py │ ├── urls.py │ └── wsgi.py ├── apps/ │ ├── accounts/ # 用户注册登录、个人中心 │ ├── pets/ # 宠物档案管理 │ ├── adoption/ # 领养申请与审核 │ └── announ/ # 公告与新闻 ├── static/ │ ├── css/ │ ├── js/ │ └── images/ ├── media/ # 宠物图片上传目录 ├── templates/ │ ├── base.html │ ├── index.html │ ├── accounts/ │ ├── pets/ │ ├── adoption/ │ └── announ/ └── requirement.txt把App都放到apps目录下是我个人的习惯主要是为了让项目根目录干净一点App多了以后更好管理。config目录用来放全局配置和根路由media目录用来存放上传的宠物照片这些路径在settings.py里要提前配好不然生产环境会出现图片无法访问的问题。1.3 核心需求拆解这个项目的核心流程并不复杂但涉及的交互比较多。我把需求拆成四条主线和三条辅助线游客浏览查看首页、宠物列表、宠物详情、公告信息不需要登录。用户领养注册登录后浏览宠物详情并提交领养申请填写申请理由、居住情况、养宠经验。管理员审核在后台审核领养申请通过的申请进入“待领养”状态宠物被领养后下架。信息发布管理员发布宠物档案、领养公告、成功案例等。辅助功能包括用户个人中心的申请记录查看、收藏宠物、修改个人资料、密码重置等。这里我特别想强调一点领养申请必须要有审核流程不能提交了就完事。很多山寨系统就是一张表单丢到数据库里管理员连审核入口都没有这种系统做出来没有实际价值。我在设计时把申请状态设计成“待审核、已通过、已拒绝、已完成”四种每个状态变化都记录时间这样管理员和用户都能看到完整的流程进度。2. 数据库设计与核心模型2.1 数据表关系梳理数据库是整个系统的地基。我画了一下核心数据表的关系用户表自定义User模型、宠物表Pet、领养申请表AdoptionApplication、公告表Announcement、收藏表Favorite。表与表之间的关系我在这里直接说清楚一个宠物属于一个分类分类就是“猫、狗、其他”这种。一个用户可以提交多个领养申请但同一只宠物在“待审核/已通过”状态下不允许第二个用户重复申请。一个用户可以收藏多只宠物宠物和用户之间是多对多关系。公告表独立存在只由管理员操作。2.2 自定义用户模型Django自带的User模型能用但为了后续扩展性我强烈建议从一开始就自定义用户模型用AbstractUser继承。为什么因为在做这个领养系统时至少要给用户加上“联系电话”和“所在城市”这两个字段这些是线下交接宠物时必须的信息。如果默认模型已经迁移过数据库后期再改用户模型会非常痛苦。自定义用户模型代码如下from django.contrib.auth.models import AbstractUser from django.db import models class User(AbstractUser): phone models.CharField(max_length11, blankTrue, verbose_name联系电话) city models.CharField(max_length64, blankTrue, verbose_name所在城市) avatar models.ImageField(upload_toavatar/, blankTrue, verbose_name头像) created_at models.DateTimeField(auto_now_addTrue, verbose_name注册时间) class Meta: db_table user verbose_name 用户设置文件里别忘了加一行AUTH_USER_MODEL accounts.User这个配置必须在第一次migrate之前设置好否则后续改动需要重置数据库那真叫一个哭爹喊娘。2.3 宠物档案模型设计宠物档案是整个系统信息量最大的数据表。除了基本信息还要考虑状态流转。我设计的字段如下class Pet(models.Model): STATUS_CHOICES ( (available, 待领养), (adopted, 已领养), (pending, 待交接), ) name models.CharField(max_length32, verbose_name宠物昵称) category models.CharField(max_length16, choices((cat, 猫咪), (dog, 狗狗), (other, 其他)), verbose_name类别) breed models.CharField(max_length32, blankTrue, verbose_name品种) age models.IntegerField(default1, verbose_name年龄(岁)) gender models.CharField(max_length8, choices((M, 男孩), (F, 女孩)), defaultM, verbose_name性别) health_status models.TextField(blankTrue, verbose_name健康状况) story models.TextField(blankTrue, verbose_name救助故事) cover_image models.ImageField(upload_topets/, verbose_name封面图片) status models.CharField(max_length16, choicesSTATUS_CHOICES, defaultavailable, verbose_name状态) created_at models.DateTimeField(auto_now_addTrue, verbose_name发布时间) class Meta: db_table pet verbose_name 宠物档案这里有几个细节值得注意。status字段不要用布尔值“是否被领养”因为领养过程有中间状态——申请通过了但宠物还没被接走这个阶段叫“待交接”。只用布尔值会丢失关键信息后面做状态筛选就很费劲。2.4 领养申请表模型领养申请表是连接用户和宠物的核心桥梁设计质量直接决定审核流程能不能顺畅跑起来。我加了几个跟实际救助工作强相关的字段class AdoptionApplication(models.Model): STATUS_CHOICES ( (pending, 待审核), (approved, 已通过), (rejected, 已拒绝), (completed, 已完成), ) user models.ForeignKey(User, on_deletemodels.CASCADE, verbose_name申请人) pet models.ForeignKey(Pet, on_deletemodels.CASCADE, verbose_name申请宠物) reason models.TextField(verbose_name领养理由) has_experience models.BooleanField(defaultFalse, verbose_name有无养宠经验) family_agreement models.BooleanField(defaultTrue, verbose_name家人是否同意) address models.CharField(max_length128, verbose_name居住地址) status models.CharField(max_length16, choicesSTATUS_CHOICES, defaultpending, verbose_name审核状态) created_at models.DateTimeField(auto_now_addTrue, verbose_name申请时间) reviewed_at models.DateTimeField(nullTrue, blankTrue, verbose_name审核时间) remark models.TextField(blankTrue, verbose_name审核备注) class Meta: db_table adoption_application unique_together (pet, user)unique_together这个约束我用在了这让“同一用户对同一宠物只能提交一次申请”。如果不加这个约束用户重复提交申请会导致后台审核出现一堆冗余记录。当然被拒绝后是否允许重新申请这个需求我实现了分支判断在视图里单独处理而不是直接靠唯一约束锁死。3. 核心功能模块与实现要点3.1 用户注册、登录与权限控制用户模块我分了三个角色游客、普通用户、管理员。管理员就是is_staffTrue的用户用Django自带的认证系统就够了。不过登录后的跳转逻辑需要自己写一下。注册这块我额外接了验证码用的是Pillow生成的图片验证码。虽然是老技术但简单可靠能挡住大部分恶意注册脚本。视图逻辑大致是from django.contrib.auth import login from .forms import RegisterForm def register(request): if request.method POST: form RegisterForm(request.POST) if form.is_valid(): # 验证码校验 code request.session.get(captcha_code) input_code form.cleaned_data.get(captcha) if code and code.lower() input_code.lower(): user form.save(commitFalse) user.set_password(form.cleaned_data[password]) user.save() login(request, user) return redirect(pet_list) else: form.add_error(captcha, 验证码错误) else: form RegisterForm() return render(request, accounts/register.html, {form: form})权限控制上我用了Django自带的login_required装饰器没有登录的用户访问提交申请页面时会被自动弹回登录页。这个方案成熟、安全比自己在视图里判断request.user.is_authenticated靠谱得多。3.2 宠物信息的展示与筛选宠物列表页面做了三块内容搜索框、分类筛选、卡片式宠物列表。搜索功能我直接用ORM的icontains做模糊查询虽然数据量大以后效率一般但对于这种小型系统完全够用没必要上来就上Elasticsearch。def pet_list(request): pets Pet.objects.filter(statusavailable) keyword request.GET.get(keyword, ) category request.GET.get(category, ) if keyword: pets pets.filter(name__icontainskeyword) if category and category in dict(Pet.STATUS_CHOICES): pets pets.filter(categorycategory) return render(request, pets/pet_list.html, {pets: pets})这里有个小坑首页只展示“待领养”状态的宠物时如果直接用Pet.objects.all()会把“已领养”的老档案也展示出来让用户看到一只早被别人领走的宠物体验会很差。所以列表页一律过滤状态。宠物详情页我除了展示基本信息还增加了一个“收藏”按钮和“提交领养申请”按钮。收藏按钮通过AJAX异步请求实现不用刷新整个页面。领养申请按钮则判断当前用户是否登录未登录时弹窗提示去登录。3.3 领养申请流程的实现领养申请是整个系统的业务核心。我的流程是用户进入宠物详情页点击“申请领养”。系统检查用户是否登录、宠物是否处于“待领养”状态。检查用户是否已经提交过该宠物的申请防止重复提交。通过检查后跳转到申请表单页。用户填写领养理由、是否有养宠经验等信息提交。状态变为“待审核”管理员在后台处理。审核通过后宠物状态变为“待交接”用户和管理员可以协商线下交接。交接完成后管理员把申请状态改为“已完成”宠物状态改为“已领养”。login_required def submit_application(request, pet_id): pet get_object_or_404(Pet, idpet_id) if pet.status ! available: messages.error(request, 该宠物当前不可领养) return redirect(pet_detail, pet_idpet.id) existing AdoptionApplication.objects.filter(petpet, userrequest.user) if existing.exists(): messages.warning(request, 您已经申请过这只宠物请等待审核结果) return redirect(pet_detail, pet_idpet.id) if request.method POST: form ApplicationForm(request.POST) if form.is_valid(): app form.save(commitFalse) app.user request.user app.pet pet app.save() return redirect(my_applications) else: form ApplicationForm() return render(request, adoption/apply.html, {form: form, pet: pet})这段代码看起来简单但已经把三种异常情况都堵住了宠物状态不可领养、用户重复申请、表单校验失败。我见过很多项目在业务校验上偷懒结果数据库里出现一堆非法数据后面查问题查到头大。3.4 后台审核功能增强Django自带Admin很好用但原生Admin在处理业务审核时不够直观。我给领养申请在Admin里增加了一个列表筛选和自定义操作class AdoptionApplicationAdmin(admin.ModelAdmin): list_display (pet, user, status, created_at, reviewed_at) list_filter (status,) actions [approve_applications, reject_applications] def approve_applications(self, request, queryset): for app in queryset: if app.status pending: app.status approved app.reviewed_at timezone.now() app.pet.status pending app.pet.save() app.save() approve_applications.short_description 批量通过批量通过的时候连宠物状态一起更新这样管理员不需要进宠物表再改一次状态。批量操作按钮是我在生产中经常用到的功能强烈推荐大家给自己的Admin加上。3.5 公告模块与前端展示公告模块做起来不复杂但它是救助站向公众传递信息的窗口也影响整个系统看起来是否完整。公告模型就三个核心字段标题、正文、发布时间。首页在轮播图和宠物列表之间展示最新三条公告。我顺便做了一个“成功案例”栏目本质上也是公告但多一张配图字段。这个功能是为了鼓励更多人参与领养实际运营中效果很不错。4. 实操过程与核心环节实现4.1 开发环境准备这个项目用的所有依赖我都放在requirements.txt里Django4.2.7 Pillow10.1.0 django-crispy-forms2.1 gunicorn21.2.0开发时用Django自带服务器部署时换成Gunicorn Nginx。数据库先用SQLite方便本地调试发布时切到MySQL只需要改settings.py里的DATABASES配置Django的ORM会帮我们把所有SQL差异抹平。4.2 数据初始化的建议系统刚上线时数据库是空的直接给用户看一个空荡荡的页面非常掉价。我建议做两件事用python manage.py seed_data命令批量生成测试宠物数据脚本里用Faker生成名字、品种、描述。手动创建一个管理员账号把宠物分类等基础数据填好。创建管理员的命令是python manage.py createsuperuser测试数据生成脚本我放到了management/commands/seed_data.py里主要是为了测试列表页、搜索功能和详情页时不用一条条手动添加。注意这个脚本只用于开发环境正式生产环境还是得靠管理员人工录入真实宠物档案。4.3 宠物图片上传与访问配置这是新手最容易踩坑的地方。图片能上传成功但页面死活不显示原因通常是settings.py里的MEDIA_URL和MEDIA_ROOT没配对或者主urls.py没有挂载静态服务。# settings.py MEDIA_URL /media/ MEDIA_ROOT BASE_DIR / media# config/urls.py from django.conf import settings from django.conf.urls.static import static urlpatterns [ # 其他路由 ] static(settings.MEDIA_URL, document_rootsettings.MEDIA_ROOT)还有一点模板里引用图片时一定要用{{ pet.cover_image.url }}不要直接拼/media/ pet.cover_image.name。Django的FileField对象的url属性会帮我们拼接好完整路径手动拼接容易出现问题。开发模式下这个方法没问题部署到Nginx后static()这一行要删掉或者做环境判断否则会暴露静态文件服务。4.4 前端页面响应式处理这套系统虽然以PC端后台管理为主但前台列表页面有大量普通用户会用手机访问所以前端必须做响应式。我选用的方案是AdminLTE框架改前台不前台我用的是纯Bootstrap 5。后台则直接用Django Admin自带界面不额外写HTML。首页、宠物列表、宠物详情、申请表单这几个页面的HTML模板继承同一个base.html导航栏和页脚统一维护。模板引擎用Django自带的DTL不需要换成Jinja2原生的语法完全够用。4.5 邮件通知与提醒用户申请提交后管理员不一定马上登录后台看到项目里我加了一个基础的邮件通知功能申请提交成功后自动发一封邮件给管理员审核通过后发邮件通知申请用户。开发环境下邮件功能可以用console后台输出调试不会真的发出去EMAIL_BACKEND django.core.mail.backends.console.EmailBackend生产环境改成SMTP填入邮箱授权码就可以了。这一步很多人会遗忘但对真实运营场景来说非常重要管理员不可能一直盯着系统后台的。5. 常见问题与排查技巧实录5.1 数据库迁移报错自定义 User 模型后在设置AUTH_USER_MODEL之前如果已经执行过migrate后面会报类似AuthUser.userprofile: relation already exists的错误。这个错误的原因是把系统默认的auth_user表已经建出来了再切换自定义模型时Django不知道如何处理旧表。解决办法是开发初期就设置好AUTH_USER_MODEL然后删除旧的数据库文件开发环境重新迁移。如果已经部署了正式环境就要写数据迁移脚本同步数据麻烦不少。所以再次强调动手写代码前先把用户模型定下来。5.2 图片上传后404跑完python manage.py runserver后访问上传的宠物图片返回404。这个问题我至少见过不下五次原因基本都是MEDIA_ROOT路径配置不对。尤其注意如果BASE_DIR和MEDIA_ROOT拼接使用了相对路径Django的静态文件处理器会找不到目录。还有一种情况是开发时用了static()方法但忘了加document_root参数。第二参数不写Django就不知道去哪里找文件结果404。检查方法很简单打印一下MEDIA_ROOT指向的绝对路径看文件是否真的在那个目录下存在。5.3 重复提交申请测试时发现用户可以绕过前端页面用POST工具重复提交领养申请数据库里出现多条相同用户和宠物的记录。我在模型层加了unique_together约束后再用try-except捕获IntegrityError在视图里做了兜底这样就算绕过前端检查数据库层面也能拦住重复数据。5.4 表单提交后页面刷新报错如果你在帖子提交表单后按F5浏览器会提示“确认重新提交表单”用户点确认后可能导致生成重复的申请记录。这个问题的根源是用普通POST表单提交后页面没有做重定向。正确的写法是Post/Redirect/Get模式视图中处理完POST请求后立刻redirect到结果页面而不是render返回同一个模板。我在提交申请、注册账号、发布公告这几个表单里都严格执行了POST→Redirect→GET的流程。5.5 常见问题速查表现象可能原因解决方案登录后跳转到默认admin页而不是用户页LOGIN_REDIRECT_URL未配置在settings.py加LOGIN_REDIRECT_URL /pets/图片上传成功但列表页不显示MEDIA_URL和MEDIA_ROOT不匹配检查配置并重启服务清缓存Admin列表页出现重复记录缺少unique_together约束在模型中加约束并重新迁移表单提交重复未遵循PRG模式改为POST→Redirect→GET用户注册后无法发送验证邮件邮件后端配置错误开发环境使用console后端验证逻辑部署后静态文件404Nginx未配置静态目录配置location /static/和location /media/5.6 关于防爬虫和恶意提交系统上线后会被各种爬虫扫描注册接口容易被滥用。我做了几个基础防护注册接口加图片验证码。Admin后台URL不放在默认的/admin/路径下改成一个自定义路径在urls.py里用path(manage/, admin.site.urls)这样相对冷门的路径能挡掉一大部分自动化攻击。领养申请接口在服务端校验字段长度和内容不做简单的HTML过滤——用Django模板自动转义就够了。对频繁提交的IP做简单的频率限制用django-ratelimit这个第三方库几行代码就能配好。这些措施虽然不是企业级安全方案但对于一个宠物领养管理平台来说已经能挡住绝大多数恶意行为。6. 部署与环境配置要点6.1 从开发到生产的配置切换开发环境直接跑runserver没问题但生产环境必须用WSGI服务器。我推荐Gunicorn启动命令gunicorn config.wsgi:application --bind 0.0.0.0:8000 --workers 3workers的数量一般是CPU核心数加1不要盲目开更多进程否则内存占用会比较大。前面加上Nginx做反向代理/static/和/media/两个路径直接由Nginx处理静态文件Django只处理动态请求。部署到Linux服务器时settings.py里需要把DEBUG设为FalseALLOWED_HOSTS配置成服务器域名或IP。还有一个关键操作关闭static()的MEDIA路由否则会把资源请求转发给Python进程白白增加负载。6.2 数据库切换从SQLite切换到MySQL需要安装mysqlclient或者pymysql然后在settings.py里改数据库配置DATABASES { default: { ENGINE: django.db.backends.mysql, NAME: pet_adoption, USER: root, PASSWORD: 你的密码, HOST: 127.0.0.1, PORT: 3306, } }执行一下python manage.py migrate如果代码里没有使用SQLite特有的函数模型和数据迁移基本无缝切换。这一步Django的ORM优势体现得特别明显。7. 项目扩展方向与个人经验这套基础版本跑通后可以继续往这几个方向扩展宠物定位与地图服务给救助站宠物增加定位需要接入地图SDK。志愿者招募模块在公告之外增加专门的活动报名流程。微信小程序端把前台移植到小程序Django提供JSON接口。消息推送申请审核结果、宠物状态变化通过短信或微信模板消息通知。数据统计看板用Chart.js做一个后台统计页面展示每日申请量、领养成功率、宠物分类占比。我个人使用中觉得最舒服的一点是Django把这些功能扩展的门槛降得很低。加一个新模块就是“建App、写模型、做模板”三步走老模块几乎不用动。如果你在做类似的系统我建议先从“把核心领养流程彻底跑通”开始不要一上来就贪多。把用户注册、宠物发布、申请审核、状态流转这四个环节做到位系统就已经能用了。后面那些“智能推荐宠物”“实时聊天”功能都是锦上添花先稳住地基最重要。最后说一个我踩过的坑开发时一定要在主settings.py里尽早把时区配好不然created_at记录的时间和本地时间差8个小时排查审核记录时容易把自己绕晕。如果你是第一次做Django项目建议先用SQLite把整个流程跑通不要急着上MySQL。开发调试的速度差异很大等系统稳定了再切换生产数据库一步一个脚印这个项目的坑能少踩一半。