基于Django的宠物领养救助网站：状态机与申请流程设计-代码聚汇网

1. 为什么多数“宠物领养网站”最后变成“宠物橱窗”

宠物领养网站这个选题，在学生项目、毕业设计甚至外包订单里出现频率都很高，但大多数实现有个共同问题：它本质上只是一个“宠物橱窗”。宠物列表、详情页、申请表单都做了，看起来功能齐全，一旦真实跑起来，立刻会被几个问题卡住——同一只宠物能收到七八份申请，管理员却不知道先处理谁；宠物已经被领养走了，页面上还挂着“待领养”；志愿者上传救助信息后，自己都查不到后续进展。最近我用 Python 完整重做了一遍这套基于 Django 的宠物领养救助网站，同时对比写了 Flask 版本，最终稳定跑通的是以“志愿者 + 领养申请 + 状态流转”为骨架的这套设计。这篇记录就把我从需求拆解、数据建模到列表查询、后台统计和实际上线中遇到的关键问题完整讲一遍，给正在做同类系统的朋友作参考。

先给这篇文章一个明确的价值定位：如果你只是交作业或演示 demo，那照着网上的“宠物列表 CRUD”抄一遍就够了；但如果你想让这个网站真的能被救助站、志愿者和领养人用起来，就必须把“领养流程”当作核心来设计，而不是把“宠物信息展示”当作核心。文章后面所有建模和代码，都是围绕“怎么保证一只宠物只有一个有效的领养结果”“怎么让志愿者知道自己救助的动物去向如何”“怎么让管理员能高效处理堆积的申请”这三件事展开的，适合正在做 Django 或 Flask 宠物项目的开发者，也适合想把自己零散想法整理成可运营系统的业余爱好者。

1.1 从需求文档里挖出真正的角色边界

网上的项目描述经常只有一句话：“做一个宠物领养救助网站。”这句话本身没有业务约束，导致代码也写得很随意。我在设计前先列了一遍系统中到底会有什么人进来操作，最终收敛成四类角色：

游客：能浏览公共宠物列表、搜索、看宠物详情，不能提交申请。
注册用户：在游客能力基础上，可以申请领养、收藏宠物、在个人中心查看申请进度和曾经领养过的宠物。
志愿者：通常指救助了流浪动物并愿意帮忙找领养的人，可以发布救助信息、上传照片、补充宠物健康状态，并跟进自己名下宠物的申请情况。
管理员：需要审核宠物信息是否真实有效，管理用户状态，处理异常申请，查看领养率、待处理申请数等运营数据。

很多半成品项目只有一个用户表，志愿者和管理员全靠后台硬区分，这会造成一个很经典的坑：志愿者自己发布了宠物，但他不能关闭这条救助信息，也不能把宠物标记为已被领养，只能等管理员去操作。对真实场景来说，管理员不是随时都在线的，志愿者才是信息的第一负责人。所以我的方案是在用户表里增加“角色”字段，并且把权限控制到对象级别——普通用户只能看到审核通过的宠物，志愿者可以编辑自己发布的宠物，管理员能看到全局和所有待审核内容。

1.2 领养业务不能只有一个布尔字段

“宠物是否被领养”如果用布尔字段做，后面一定出问题。因为状态不是“否”和“是”两个点，中间有一个漫长的流程：志愿者提交救助信息后，宠物信息可能需要平台确认；信息确认后进入“可领养”状态；有人提交领养申请后，志愿者要审核；如果决定让某人领养，需要把宠物改成“已领养”，同时把其它申请关掉。这个链路里任何一个环节都可能在某个时刻出现中间态，所以必须使用“状态字段 + 状态流转规则”，而不是 is_adopted 这种简单的布值。

我当时把宠物状态定义为四个：pending（待审核）、available（可领养）、adopted（已领养）、off_shelf（已下架）。很多人会问，为什么还需要 off_shelf？因为真实使用中，宠物可能出现临时不能被领养的情况，比如皮肤病治疗中、等待疫苗打完、原救助人临时想再观察几天。没有这个状态，就只能删数据，而删除会丢失申请记录和当初的照片信息，非常不划算。状态字段多一个，代码层面只是多一个分支，但运营层面好用很多。

1.3 把“申请”做成有独立状态的对象

领养申请不能理解成“用户给宠物发一条私信”，它应当是一张有自己的生命周期、自己的处理时间、自己的审核结果的独立记录。每一条申请从提交开始就处于 pending，处理后有 approved 或 rejected，用户自己也能 withdrawn 取消。只有把申请做成独立对象，才能在个人中心展示“我申请过哪些宠物，每一条现在是什么状态”，也才能在后台看到“待处理申请”堆了哪些。

我还加了一个细节：审批通过时要记录操作人和操作时间。这个字段在 demo 阶段看起来多余，而项目运行后，一旦发生“管理员说没批准，志愿者说批准了”的争议，审计记录就能帮你快速定位是谁、在什么时间、基于哪条申请做了什么操作。如果从第一版就留好，后面补会非常痛苦。

需要模型API调用？免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。

2. 用 Django 建模时我踩过的三个坑

Django 建模本身不难，难的是怎么建出不容易产生脏数据的表结构。下面不是完整代码，而是我会在项目里实际用的核心模型和踩坑点。

2.1 用户表增加角色，宠物表记录发布者

先自定义用户模型，别用 Django 默认的 User 直接扩展。我在项目一开始就设置了 AUTH_USER_MODEL，这个配置一定要在第一次 migrate 之前做，否则后期改会涉及数据库迁移联动，很容易把关联表搞乱。

python复制# accounts/models.py
from django.contrib.auth.models import AbstractUser
from django.db import models

class User(AbstractUser):
    class Role(models.TextChoices):
        NORMAL = "normal", "普通用户"
        VOLUNTEER = "volunteer", "志愿者"
        ADMIN = "admin", "管理员"

    role = models.CharField(
        max_length=20,
        choices=Role.choices,
        default=Role.NORMAL,
        verbose_name="角色",
    )
    phone = models.CharField(max_length=20, blank=True, verbose_name="联系电话")
    avatar = models.ImageField(upload_to="avatars/%Y/%m/", blank=True)

宠物表里有一个关键外键叫 publisher，指向发布者。这里有个容易写错的地方：不要简单地把外键叫 user。因为宠物可能由平台管理员录入，也可能由志愿者本人录入，叫 user 的话后续看代码的人会分不清这个用户到底承担了什么角色。我用 publisher 更直白，它代表“这个信息的来源”。

python复制# pets/models.py
class Pet(models.Model):
    class Status(models.TextChoices):
        PENDING = "pending", "待审核"
        AVAILABLE = "available", "可领养"
        ADOPTED = "adopted", "已领养"
        OFF_SHELF = "off_shelf", "已下架"

    publisher = models.ForeignKey(
        "accounts.User",
        on_delete=models.SET_NULL,
        null=True,
        related_name="published_pets",
        verbose_name="发布者",
    )
    category = models.CharField(max_length=10, choices=[("dog", "狗"), ("cat", "猫"), ("other", "其它")])
    breed = models.CharField(max_length=50, blank=True, verbose_name="品种")
    age_month = models.PositiveSmallIntegerField(verbose_name="月龄")
    gender = models.CharField(max_length=1, choices=[("M", "公"), ("F", "母"), ("U", "未知")])
    city = models.CharField(max_length=50, verbose_name="城市")
    district = models.CharField(max_length=50, blank=True, verbose_name="区/县")
    description = models.TextField(verbose_name="救助/送养描述")
    status = models.CharField(
        max_length=20,
        choices=Status.choices,
        default=Status.PENDING,
        db_index=True,
    )
    adopted_by = models.ForeignKey(
        "accounts.User",
        null=True,
        blank=True,
        on_delete=models.SET_NULL,
        related_name="adopted_pets",
        verbose_name="最终领养人",
    )
    created_at = models.DateTimeField(auto_now_add=True)
    updated_at = models.DateTimeField(auto_now=True)

    class Meta:
        ordering = ["-created_at"]

adopted_by 并不是必须的，可以通过 AdoptionApplication 里状态为 approved 的记录推出来。但我在实际后台里需要频繁查看“这只宠物的领养人是谁”，如果每次都要反向查询一次申请记录，不但代码绕，数据库压力也大。所以我把最终领养人冗余存储到了宠物表。这里的冗余是刻意为之，只存储结果，不存储过程，不会导致数据不一致，因为真正的审批流程依然由申请记录驱动。

2.2 宠物图片单独建表，不要让图片字段只挂一张

很多初学项目只在 Pet 模型里放一个 ImageField，这意味着每只宠物只能传一张照片。在真实领养场景里这非常不友好——志愿者想展示宠物不同的角度、救助时的伤情、治愈后的状态，至少也要三五张图。图片单独建表还有一个好处：第一张图可以作为封面图，其它图作为详情图，前台展示时能够灵活控制。

python复制class PetImage(models.Model):
    pet = models.ForeignKey(Pet, on_delete=models.CASCADE, related_name="images")
    image = models.ImageField(upload_to="pets/%Y/%m/")
    order = models.PositiveIntegerField(default=0)
    is_cover = models.BooleanField(default=False, verbose_name="是否封面")

order 字段容易被忽略，但如果不上传时间或文件名字排序，图片展示顺序就很随机。我在前端展示首图时会取 is_cover=True 的首图；没有设置封面时，就取 order=0 的图片兜底。运营中很多人会忘记勾选封面图，所以我在保存 PetImage 时会写一个信号：如果整个宠物连一张封面图都没有，就自动把当前图片设为封面。

2.3 领养申请的状态约束是防重复的关键

大多数重复申请问题，靠业务代码里的 if 判断也能挡掉一部分，但真正可靠的防线是数据库约束。我先建了申请模型：

python复制class AdoptionApplication(models.Model):
    class Status(models.TextChoices):
        PENDING = "pending", "待审核"
        APPROVED = "approved", "已通过"
        REJECTED = "rejected", "未通过"
        WITHDRAWN = "withdrawn", "已取消"

    pet = models.ForeignKey(Pet, on_delete=models.CASCADE, related_name="applications")
    applicant = models.ForeignKey(
        "accounts.User",
        on_delete=models.CASCADE,
        related_name="adoption_applications",
    )
    phone = models.CharField(max_length=20, blank=True)
    reason = models.TextField(verbose_name="领养理由")
    status = models.CharField(max_length=20, choices=Status.choices, default=Status.PENDING)
    created_at = models.DateTimeField(auto_now_add=True)
    updated_at = models.DateTimeField(auto_now=True)
    processed_by = models.ForeignKey(
        "accounts.User",
        null=True,
        blank=True,
        on_delete=models.SET_NULL,
        related_name="processed_applications",
    )
    processed_at = models.DateTimeField(null=True, blank=True)

在 Meta 里我加了两条数据库级约束：

python复制from django.db.models import Q

class Meta:
    constraints = [
        models.UniqueConstraint(
            fields=["pet", "applicant"],
            condition=Q(status="pending"),
            name="uniq_one_pending_per_user_per_pet",
        ),
        models.UniqueConstraint(
            fields=["pet"],
            condition=Q(status="approved"),
            name="uniq_one_approved_per_pet",
        ),
    ]

第一个约束的意思是：同一只宠物，同一个用户，只允许存在一条待审核申请。有人可能会问，为什么不干脆禁止重复申请呢？因为真实场景里，用户首次申请可能因为资料不完整被拒绝，后来补充信息后重新提交是合理的。如果给 pet 和 applicant 做全字段唯一约束，用户被拒后就没法再申请，这不符合操作逻辑。所以我把唯一性限定在 pending 状态上。

第二个约束更关键：同一只宠物，最多只能有一条 approved 申请。这个约束能防止并发操作下出现“两只不同用户同时被批准领养同一只宠物”的数据错误。很多系统上线后出大问题，就是因为业务代码只做了单机检查，没有考虑两个管理员同时点击“通过”的情况。有了数据库约束兜底，即使两个请求同时进来，数据库也会让其中一个失败。

3. 领养申请审批流程：用事务把每一步都绑在一起

3.1 用户提交申请时的服务和页面逻辑

用户提交领养申请看起来只是保存一条记录，但我仍然建议把它放进独立的 service 函数，不要直接写在视图里。这样后续如果增加“申请积分”“领养资格校验”“邮件通知”等功能，都能在不改动视图的前提下扩展。基础提交逻辑可以这样写：

python复制from django.db import IntegrityError, transaction
from django.shortcuts import get_object_or_404, redirect
from .models import Pet, AdoptionApplication
from .forms import AdoptionForm

@login_required
def apply_adoption(request, pet_id):
    pet = get_object_or_404(Pet, pk=pet_id)
    if pet.status != Pet.Status.AVAILABLE:
        messages.error(request, "这只宠物当前不可申请领养。")
        return redirect("pet_detail", pk=pet.pk)

    if request.method == "POST":
        form = AdoptionForm(request.POST)
        if form.is_valid():
            try:
                with transaction.atomic():
                    application = form.save(commit=False)
                    application.pet = pet
                    application.applicant = request.user
                    application.status = AdoptionApplication.Status.PENDING
                    application.save()
                    # 自己做的事：给志愿者发送一条站内通知
                    notify_user(pet.publisher_id, f"你发布的 {pet.name} 收到一条新的领养申请")
            except IntegrityError:
                messages.error(request, "你已经申请过这只宠物，请勿重复提交。")
                return redirect("pet_detail", pk=pet.pk)
            messages.success(request, "申请提交成功，请等待志愿者或管理员审核。")
            return redirect("my_applications")
    else:
        form = AdoptionForm(initial={"phone": request.user.phone})
    return render(request, "pets/apply_adoption.html", {"form": form, "pet": pet})

我在提交页面默认带出用户注册时填写的手机号，这是现场运营人员提醒我的：很多领养人提交申请时会留错手机号，审核的人打过去发现是空号，白白浪费时间。前端可以允许修改，但初始值尽量从用户资料带出来，能降低大量错误率。

3.2 志愿者审核通过：先锁行，再改状态

“通过申请”是整个系统里风险最高的操作，因为它同时涉及三件事：把申请改成 approved、把宠物改成 adopted、把该宠物下面其它待审核的申请全部关闭。如果这三步不在一个数据库事务里执行，中间宕机或者报错，系统就会进入一个很尴尬的状态：申请通过了，宠物却还显示可领养。

我采用的是 select_for_update 行锁。Django 在事务里对查询结果加锁，其它事务要操作这一行时就必须等待，这样能防止管理员 A 和管理员 B 同时通过两只不同的申请。

python复制from django.db import transaction
from django.utils import timezone

@staff_member_required
@transaction.atomic
def approve_application(request, app_id):
    application = AdoptionApplication.objects.select_for_update().select_related("pet", "pet__publisher").get(id=app_id)

    if application.status != AdoptionApplication.Status.PENDING:
        messages.error(request, "该申请已处理，请刷新后再试。")
        return redirect("admin_applications")

    pet = Pet.objects.select_for_update().get(pk=application.pet_id)

    if pet.status == Pet.Status.ADOPTED:
        messages.error(request, "这只宠物已经进入已领养状态，不能再通过新申请。")
        return redirect("admin_applications")

    application.status = AdoptionApplication.Status.APPROVED
    application.processed_by = request.user
    application.processed_at = timezone.now()
    application.save(update_fields=["status", "processed_by", "processed_at", "updated_at"])

    pet.status = Pet.Status.ADOPTED
    pet.adopted_by = application.applicant
    pet.save(update_fields=["status", "adopted_by", "updated_at"])

    # 关闭该宠物名下其他待审核申请
    AdoptionApplication.objects.filter(
        pet_id=pet.id,
        status=AdoptionApplication.Status.PENDING,
    ).exclude(id=application.id).update(
        status=AdoptionApplication.Status.REJECTED,
    )

    messages.success(request, f"领养申请已通过，{pet} 已标记为已领养。")
    return redirect("admin_applications")

这段代码有几个细节值得说道。select_for_update 必须放在 transaction.atomic() 块内才有效，如果脱离事务执行，Django 会直接报错，这是很多人第一次使用时会踩的坑。update_fields 里的 updated_at 也要显式加上，不然 auto_now 字段在只更新部分字段时可能不会被刷新，造成后台列表里看到的“处理时间”不是真实操作时间。最后，处理完其它申请后，最好记录一个取消原因。我用的是直接改成 REJECTED，但在列表里会提示“本申请因另一申请人成功领养而自动关闭”。如果业务需要更细致的区分，可以考虑再加一个 CLOSED 状态，不过对大多数项目来说，复用一个 rejected 就够了。

3.3 被拒绝后能不能再次申请

我前面说数据库约束只限制了 pending 状态，意味着用户被拒绝之后可以再次申请。但这里需要处理一个体验问题：当用户进入宠物详情页，看到自己曾经申请过但被拒绝时，按钮应该引导他重新申请，而不是简单地显示“你已申请过”。我当时在详情页的状态判断写了三种：

用户没有申请记录，显示“我要领养”。
存在 pending 申请，显示“申请审核中”，按钮禁用。
最近一条申请是 rejected，额外显示“上次申请未通过，可以重新提交申请”。

这个细节可以让用户感受到系统“知道”他上一次的结果，而不是像失忆一样。如果只靠数据库查询当前是否有 pending 记录，用户被拒后连重新申请的入口都找不到，运营人员就要反复手工处理投诉。

4. 列表页与查询：别让搜索结果拖垮你的后台

4.1 组合筛选用 Q 对象，不要拼大量的 if

很多初学者在写宠物列表时，会为每个筛选条件单独写一个 if，一个页面上有城市、品种、年龄、性别、状态五个筛选项，视图函数可能堆出十多个 if。我当时用的是字典收集条件的方式，代码清爽很多。

python复制def pet_list(request):
    pets = Pet.objects.filter(status=Pet.Status.AVAILABLE)

    filters = {}
    category = request.GET.get("category")
    city = request.GET.get("city")
    gender = request.GET.get("gender")
    keyword = request.GET.get("keyword", "").strip()

    if category:
        filters["category"] = category
    if city:
        filters["city"] = city
    if gender in ["M", "F", "U"]:
        filters["gender"] = gender

    pets = pets.filter(**filters)

    if keyword:
        pets = pets.filter(
            Q(breed__icontains=keyword)
            | Q(description__icontains=keyword)
            | Q(city__icontains=keyword)
        )

    pets = pets.select_related("publisher").prefetch_related("images").only("id", "category", "breed", "age_month", "gender", "city", "district", "status")
    return render(request, "pets/pet_list.html", {"pets": pets})

这里我推荐用 select_related 预取外键 publisher。模板中如果展示“志愿者昵称”，没有预取的话，每条宠物都会多查一次用户表，列表 30 条就多出 30 次查询。prefetch_related("images") 则是预取图片集合。列表页只加载宠物封面图和基本信息，详情页再展示更多图，不要一开始就把所有图片都放到内存。

4.2 宠物描述带 HTML？小心安全问题

很多志愿者发布信息时希望排版好看，会有意无意粘贴来自网页的内容。Django 模板默认会自动转义大部分 HTML，但如果你的 description 字段允许富文本，并且你用了 |safe 过滤器，就会把 <script> 标签原样输出到浏览器里，形成存储型 XSS 漏洞。

我的处理方式是保持输入源为纯文本，但在模板里用 linebreaksbr 过滤器替换换行符，既能保留志愿者输入的换行结构，又不会执行任何 HTML。如果确实要支持图文混排，就应该引入像 markdown 这样的标准语法库，而不是允许用户直接粘贴 HTML。

4.3 查询数据量大了之后的索引问题

项目演示阶段数据量小，查什么都快。等真实运营几个月，宠物表有几千条、申请表有上万条记录时，不带索引的查询会明显变慢。所以在建表时就要养成好习惯：

Pet.status 要加 db_index=True，因为列表页最常用状态过滤。
Pet.city 加普通索引，因为城市筛选是最常见的筛选条件。
AdoptionApplication.pet 和 AdoptionApplication.applicant 外键本身会建立索引。
组合查询时，如果状态和城市经常一起用，可以继续使用 models.Index(fields=["status", "city"], name="pet_status_city_idx")。

不过索引也不是越多越好。宠物表的写入并不频繁，多一些索引问题不大；但日志类、操作记录类数据就应该克制。我曾经在 views 日志表里加了五个索引，后来每次批量插入都变慢，才发现过度索引也是一种设计债。

5. 后台管理和数据统计：让“运营数据”有实际参考价值

5.1 Django Admin 要定制，不能直接裸用

直接注册 admin.site.register(Pet) 确实几秒钟就能跑通，但实际管理时非常难用。管理员每天打开后台最关心的是：待审核宠物有多少、待处理申请有多少、每只宠物现在处于什么阶段。所以我在 admin.py 里做了三个动作：

列表页默认按状态分组筛选。
自定义一个“统计总览”页面显示数字卡片。
把核心操作抽出来放在按钮上，不用管理员进详情页才能操作。

python复制from django.contrib import admin

@admin.register(Pet)
class PetAdmin(admin.ModelAdmin):
    list_display = ["name", "category", "city", "status", "publisher", "created_at"]
    list_filter = ["status", "category", "city"]
    search_fields = ["name", "breed", "description"]
    actions = ["make_available"]

    @admin.action(description="标记为可领养")
    def make_available(self, request, queryset):
        queryset.update(status=self.Status.AVAILABLE)

这个后台真正能提升效率的是 list_filter 和 search_fields。管理员一进后台就能按“待审核”状态筛选，再配合城市搜索，比在表格里一页页翻有效得多。Django Admin 看起来“不够高大上”，但它的搜索、筛选、分页都是成熟的实现，给中小型宠物组织做内部管理工具完全够用。

5.2 统计接口不要直接 count 全表

志愿者的管理后台也好、系统首页的运营数据也好，都可能需要展示这样几个数字：本月新增宠物、本月新增领养申请、累计成功领养数、待处理申请数。如果每次页面刷新都调用 Pet.objects.all().count() 或 AdoptionApplication.objects.filter(...).count()，数据量小没事，数据量大了页面会变慢，而且这些统计请求往往是同一个用户反复查看的重复操作。

我给统计模块加了缓存，使用的就是 Django 内置的 cache 框架：

python复制from django.core.cache import cache

def get_overview_stats():
    stats = cache.get("overview_stats")
    if stats is None:
        stats = {
            "pending_pets": Pet.objects.filter(status=Pet.Status.PENDING).count(),
            "available_pets": Pet.objects.filter(status=Pet.Status.AVAILABLE).count(),
            "adopted_pets": Pet.objects.filter(status=Pet.Status.ADOPTED).count(),
            "pending_applications": AdoptionApplication.objects.filter(status=AdoptionApplication.Status.PENDING).count(),
        }
        cache.set("overview_stats", stats, 60 * 5)
    return stats

缓存时间设为 5 分钟，管理员看到的数据允许有短暂延迟，但数据库压力能大幅降低。还有一个容易被忽略的点：当管理员通过申请时，要主动删除这个统计缓存，否则下一个访问者还会看到旧数据。在 approve_application 最后加一行 cache.delete("overview_stats") 就够。

5.3 志愿者个人中心的“进度感”

志愿者最关心的不只是“我发了几只宠物”，而是每只宠物当前处于什么阶段。我在志愿者后台做了一个列表，按宠物显示状态进度条：发布信息 -> 审核通过 -> 已收到 X 份申请 -> 已确认领养。虽然这个进度条本质上只是宠物状态的可视化，但它给人的“进度感”非常强，志愿者会愿意持续使用系统。

技术实现一点也不复杂：模板里根据 pet.status 渲染不同节点的高亮样式，比如 pending 只高亮第一步，available 高亮到第二步，adopted 全部高亮。真正的难点在于理清楚“宠物状态流转到哪一步了”，而这正是我前面反复强调先建模状态机的原因。没有状态机，这个进度条根本画不出来。

6. 如果把 Django 换成 Flask，方案怎么调整

有些读者拿到的是 Flask 的项目要求，或者团队已经确定了 Flask 技术栈。我在重做时也写了一个基于 Flask 的对照版本，整体业务逻辑完全一致，只有技术实现不同。最大的差异在于 Flask 默认没有 Django 那种统一自带的 ORM、Admin 和迁移体系，都需要用第三方库补齐。

6.1 Flask-SQLAlchemy 里的状态唯一约束

Flask-SQLAlchemy 的模型定义更简洁，但数据库约束写法和 Django ORM 不同。同样是“同一只宠物最多只有一条 approved 申请”，在原生 SQL 里是部分唯一索引，SQLAlchemy 中也支持这个能力：

python复制from flask_sqlalchemy import SQLAlchemy
from sqlalchemy import Index

db = SQLAlchemy()

class AdoptionApplication(db.Model):
    __tablename__ = "adoption_application"
    id = db.Column(db.Integer, primary_key=True)
    pet_id = db.Column(db.Integer, db.ForeignKey("pet.id"), nullable=False)
    applicant_id = db.Column(db.Integer, db.ForeignKey("user.id"), nullable=False)
    status = db.Column(db.String(20), nullable=False, default="pending")

    __table_args__ = (
        Index("uniq_approved_pet", "pet_id", unique=True, sqlite_where=db.text("status = 'approved'")),
        Index("uniq_pending_user_pet", "pet_id", "applicant_id", unique=True, sqlite_where=db.text("status = 'pending'")),
    )

需要特别注意：部分唯一索引在 MySQL、PostgreSQL 和 SQLite 之间的支持程度不一样。PostgreSQL 原生支持，SQLite 从 3.8 开始也支持部分索引，但 MySQL 不支持这种带条件的约束。如果你要部署到 MySQL，数据一致性最好改由应用层先查询再插入，或者在数据库增加一个“是否为最终审批”的布尔字段和唯一索引配合。这个坑我在选型时确认过，如果你的项目在演示环境用 SQLite，生产环境切 MySQL，上线前一定要检查这些约束有没有被正确迁移。

6.2 Flask 没有 Admin，后台就只能自己写

Django 自带的后台是巨大的优势，Flask 生态没有官方等价物。Flask-Admin 可以用，但它的定制灵活度远不如 Django Admin，和模型定义耦合得也比较紧。我在 Flask 版本里选择了另一个思路：前台和后台都用普通模板加简单的 Blueprint 写，后台页面自己搭一个简单的侧边栏框架，核心操作就是申请审批、宠物审核和列表查看。看起来朴素，但可控性高。

如果项目要求“后台功能要做得像模像样”，我会更推荐 Django。Flask 适合前台和 API 特别灵活的场景，比如宠物领养小程序后端、需要对接微信登录的 API 服务。而 Django 适合“一个人把所有页面包括后台管理都快速做出来”的场景。选 Flask 不是不能做后台，而是你得付出更多时间处理本来框架不帮你做的事。

6.3 Flask 怎么处理事务和并发审批

Flask 中完成领养审批同样需要使用事务。Flask-SQLAlchemy 的事务逻辑基本就是 db.session.begin() 到 db.session.commit()，并发时也要考虑行锁。

python复制def approve_application(app_id, current_user):
    application = AdoptionApplication.query.filter_by(id=app_id).with_for_update().first()
    pet = Pet.query.filter_by(id=application.pet_id).with_for_update().first()
    if pet.status != "available":
        raise BizError("该宠物已经不是可领养状态")

    application.status = "approved"
    pet.status = "adopted"
    pet.adopted_by_id = application.applicant_id
    db.session.add(application)
    db.session.add(pet)
    db.session.commit()

如果你以前写 Django 比较多，忽然切到 Flask 会不习惯这种“手动管理 session 生命周期”的方式。一个常见的失误是在视图早期调用了 db.session.commit()，之后又继续操作模型，结果发现数据没有完全进入同一事务，造成部分提交。我的建议是：涉及审批的整个操作都限定在同一个函数里，不要分散到多个 service 方法，尽量只使用一次 commit，这样事务边界最清晰。

7. 从开发到能上线，我还补了哪些实用细节

7.1 文件上传路径和图片压缩

宠物照片如果让用户直接原图上传，一张动辄五六兆，移动网络下一个列表页会卡到崩溃。前端压缩用 canvas 可以做，但后端也应该有兜底。我用的方案是接入 Pillow，在图片模型保存时做尺寸压缩，超过 1200 像素宽度就缩小；封面图更是直接生成 600px 的缩略图。这样一个宠物详情页即便挂了五张图，总大小也能控制在 1MB 以内。这一步并不稀奇，但很多 demo 项目都没做，导致演示时图片加载慢到完全没法看。

7.2 邮件和站内信至少要有一个

审批结果不能只显示在网站个人中心里，因为用户不太可能每天都登录查看。我最初只做了站内信，志愿者反馈“没人看，过了一周才来联系我”。后来加了邮件通知：新申请提交时发邮件给志愿者，申请状态变化时发邮件给申请用户。对很多非盈利性质的宠物救助站来说，短信太贵，邮件是性价比最高的通知方式。Django 有现成的 send_mail，配置一个 SMTP 邮箱就能跑起来，千万不要觉得邮件通知不重要；缺少通知的系统，用户回来一次就会流失一次。

7.3 数据备份和“上线以后不要随便删数据”

宠物救助行业的运营人员对数据很敏感，万一某只宠物被领养后出现纠纷，管理员需要回查当时的申请内容、领养理由和联系人信息。这类数据绝对不能物理删除，就算用户要求“删除我的领养申请记录”，也只应做软删除，即增加 is_active=False 或 deleted_at 字段，后台依然可以审计。我的代码里所有管理员的“删除宠物”按钮实际上都调用 pet.status = off_shelf，而不是执行真正的 DELETE。开发时可以随意删，上线后用 delete 操作的成本和风险完全不同。

7.4 日志里记录关键动作

审批操作、宠物状态变更、用户角色变更，这三个关键动作我都在日志里记录下来了，用的是 logging 模块，输出到文件，后面可以接入集中日志平台。光看数据库表也能知道状态，但日志能记录更完整的上下文，比如操作前状态、操作后状态、操作来源 IP、浏览器信息。以前有次志愿者反馈说他的宠物无故变成了“已领养”，最后排查发现是另一个管理员误点了同城同名宠物。没有日志，这种问题几乎查不出来。

回归到整体架构，我个人做完这个项目最大的体会是：无论用 Django 还是 Flask，整条数据链路都围绕“宠物状态”和“申请状态”这两个状态机设计，系统就不会乱。很多看起来炫酷的功能，比如地图找宠物、聊天沟通、积分奖励，都只能算锦上添花，真正支撑业务运转的仍然是一张状态表加三个核心操作：审核宠物、提交申请、审批通过。先把这一步走稳，再谈扩展，是做宠物领养救助网站最务实的路径。

基于Django的宠物领养救助网站：状态机与申请流程设计