企业官网建设流程全解析

毕业设计做到宠物领养管理系统，Django确实是最稳妥的选型之一。这个题目标号 46798 我一看就有印象，属于典型的 Web 全栈管理类毕设：既有用户端的内容展示，又有管理端的审核闭环，技术栈集中、业务逻辑清晰，用来答辩非常能说明问题。这篇文章我就以这个项目为蓝本，把从数据库设计、页面流程、审核状态机到部署上线的完整实现过程拆开讲一遍，并附上真实开发中容易踩的坑。如果你正在做同类系统，或者准备用 Django 做毕设，可以直接照着这套思路去搭。

1. 毕设题目拆解：领养系统到底要做什么功能

先别急着写代码。宠物领养管理系统这个题目，第一件事是把系统拆成两条使用主线：普通用户（访客/领养人）和后台管理员。很多同学一上来就建一堆表，最后自己都说不清每张表存在的意义，答辩的时候一问一个卡壳，那是典型的“需求没拆干净”。

用户端要做的事，站在一个想领养宠物的人角度想非常直观：注册登录、浏览待领养宠物列表、按品种或年龄筛选、点进宠物详情页看性格描述和照片、提交领养申请、查看申请审核进度、收藏喜欢的宠物、查看平台公告。这些功能对应的就是一个“内容消费 + 互动申请”的流程，缺了任何一个环节，用户都会觉得系统不完整。

管理端要做的事，就是保证这个流程合规流转：管理员发布和管理宠物信息（上架、下架、修改资料）、查看所有用户的领养申请、审核并给出通过或拒绝的意见、管理用户账号和公告内容。这一端的核心不是功能数量，而是“审核闭环”——用户提交申请后，管理员必须在后台能处理，处理结果必须能回传给用户端，宠物状态必须同步变化。这个闭环做不到，系统就是个半成品。

这里有个很重要的定位问题：毕设系统不需要做得像淘宝那样大而全，但流程必须自洽。我做过不少毕设指导，见过最普遍的问题就是功能列表写得很长，实际上一堆按钮是摆设。这个题目真正的得分点就三个：领养申请状态流转是否完整、宠物与申请之间的数据关联是否严谨、后台管理是否顺手。这三个点抓住了，后面所有开发工作都是围绕它们铺开的。

技术栈方面，题目限定 Django，那么前端就用服务端渲染的模板系统配合 Bootstrap，数据库默认 SQLite，后续需要可以切 MySQL，文件存储用本地 static/media。这套组合对毕设来说非常合适：Django 自带的 ORM、Admin 后台、Form 校验、用户认证能省掉大量重复造轮子的工作，你省下来的时间应该投入到业务逻辑和界面细节上。

2. 为什么偏偏是 Django：框架选型与项目结构设计

选 Django 做这类管理系统，不是因为它花哨，是因为它规整。拿 Flask 对比你就明白了：Flask 太灵活，模型、表单、权限这些都要自己搭或者装第三方库，明明我们想做一辆整车，结果还要自己焊轮子，对毕设来说这不是自由，是负担。Django 则是默认给你一整套基础设施，而且大而全的东西一般都对新手友好——它替你做了大部分工程化决策，你只需要按它的约定写业务。

具体到我们这个题目，Django 有四个点直接命中需求：

• 自带 Admin 后台。宠物表、领养申请表、用户表建好之后，Django Admin 几乎零成本就有一个可以操作数据的管理界面。虽然我们还是会自己写管理页面，但 Admin 在开发期调试数据、在答辩期现场展示，都是保底方案。
• 用户认证开箱即用。注册、登录、会话、权限这些代码不需要从零写，auth应用里全都有。你只需要自定义一个注册页，用UserCreationForm改一改就能用。
• ORM + 迁移机制。改模型字段后执行makemigrations和migrate就同步数据库结构，不用手写 SQL，对不熟悉数据库的同学非常友好。而且 Django 的 QuerySet 在后期优化查询（比如避免 N+1 问题）时优势很明显。
• Form 与 CSRF 防护。Django 表单负责渲染、校验、错误回显一条龙，模板里加{% csrf_token %}就能防跨站请求伪造，这些安全细节在毕设答辩时是能拿出来说的加分点。

项目结构上，我用的是传统但非常清晰的目录布局：

pet_adoption/ ├── manage.py ├── config/ # 项目配置（settings/urls） ├── apps/ │ ├── users/ # 用户注册登录、个人中心 │ ├── pets/ # 宠物信息、分类、收藏 │ ├── adoption/ # 领养申请、审核状态 │ └── notice/ # 公告内容 ├── static/ # 前端资源 ├── media/ # 上传的宠物图片 └── templates/ # 页面模板

把功能拆分成多个 app，而不是所有逻辑堆在一个app里，这是 Django 工程化的基本素养。每个 app 只负责自己的领域，后期维护、排查问题、答辩讲解都更清晰。比如领养审核的逻辑只会在adoption这个 app 里出现，别人问你“审核状态存在哪”，你直接说在adoption.models.AdoptionApplication.status，一句话就能讲明白。

3. 数据模型设计：四张核心表撑起整个系统

模型设计是整个项目的地基。这地方如果设计错了，后面写视图、写页面全会被拖累。领养管理系统的核心表我建议就这四张：用户表、宠物分类表、宠物信息表、领养申请表，另外再配一张公告表做信息展示。

3.1 用户表

不需要自己建 User 表，Django 的auth.User已经包含用户名、密码、邮箱、权限等字段。如果你还需要额外的用户信息，比如手机号，就用OneToOneField扩展一张Profile表。毕设层面，直接用auth.User就够了，少做多余的事。

3.2 宠物分类表

class PetCategory(models.Model): name = models.CharField(max_length=50, unique=True, verbose_name="分类名称") description = models.TextField(blank=True, verbose_name="分类描述") created_at = models.DateTimeField(auto_now_add=True) class Meta: verbose_name = "宠物分类" verbose_name_plural = verbose_name

这张表不要做得太重，里面存“狗”“猫”“兔子”这种级别就好，具体到品种可以放到宠物表的字段里。

3.3 宠物信息表

class Pet(models.Model): PET_STATUS_CHOICES = ( ('available', '待领养'), ('adopted', '已领养'), ('off_shelf', '已下架'), ) category = models.ForeignKey(PetCategory, on_delete=models.PROTECT, verbose_name="分类") name = models.CharField(max_length=50, verbose_name="宠物昵称") breed = models.CharField(max_length=50, blank=True, verbose_name="品种") age = models.PositiveIntegerField(verbose_name="年龄(月)") gender = models.CharField(max_length=10, choices=(('male','公'),('female','母')), verbose_name="性别") is_vaccinated = models.BooleanField(default=False, verbose_name="是否已打疫苗") is_neutered = models.BooleanField(default=False, verbose_name="是否已绝育") description = models.TextField(verbose_name="性格描述") avatar = models.ImageField(upload_to='pets/', blank=True, verbose_name="照片") status = models.CharField(max_length=20, choices=PET_STATUS_CHOICES, default='available', verbose_name="状态") created_at = models.DateTimeField(auto_now_add=True, verbose_name="发布时间")

这里有个关键点：on_delete=models.PROTECT。分类一旦绑定了宠物，就不允许随便删，防止出现宠物指向一个不存在分类的脏数据。宠物状态用status字段而不是直接删记录，是为了保留历史痕迹——一只宠物被领养后，你仍然能在系统里看到它的档案，这在展示效果上比“消失”更合理，也方便管理员统计领养数据。

3.4 领养申请表

class AdoptionApplication(models.Model): STATUS_CHOICES = ( ('pending', '待审核'), ('approved', '已通过'), ('rejected', '已拒绝'), ('completed', '已完成'), ) user = models.ForeignKey(settings.AUTH_USER_MODEL, on_delete=models.CASCADE, verbose_name="申请人") pet = models.ForeignKey(Pet, on_delete=models.CASCADE, verbose_name="宠物") reason = models.TextField(verbose_name="领养理由") housing = models.CharField(max_length=200, verbose_name="居住情况") experience = models.TextField(blank=True, verbose_name="养宠经验") status = models.CharField(max_length=20, choices=STATUS_CHOICES, default='pending', verbose_name="审核状态") admin_remark = models.TextField(blank=True, verbose_name="管理员备注") created_at = models.DateTimeField(auto_now_add=True) updated_at = models.DateTimeField(auto_now=True)

这张表是系统的“心脏”。所有审核相关的页面、状态判断、宠物状态联动，都是围绕它展开。注意我加了completed（已完成）状态：审核通过后，领养关系还需要一个“确认完成”的动作，这样状态机才是完整的，从申请到最终成交都有据可查。

数据模型设计完了之后，自己去验证一下逻辑：用户提交申请 -> 申请表生成pending；管理员点击通过 -> 申请表变approved，同时宠物status变adopted；管理员点击拒绝 -> 申请表变rejected，宠物保持available可以继续被别人申请。这个流转想清楚，写视图逻辑就有把握了。

4. 用户端开发：从注册登录到提交领养申请

模型层稳定之后，用户端的开发其实是顺着流程走的。我按一个真实用户的使用顺序来讲，这样你写代码的时候也有代入感。

4.1 注册与登录

用 Django 内置的auth应用做认证。注册视图用UserCreationForm定制一下，增加邮箱字段，保存用户后直接登录：

def register(request): if request.method == 'POST': form = CustomUserCreationForm(request.POST) if form.is_valid(): user = form.save() login(request, user) return redirect('pets:pet_list') else: form = CustomUserCreationForm() return render(request, 'users/register.html', {'form': form})

登录就用LoginView，加一个模板就行，不需要自己从头写会话逻辑。模板里用{{ form.as_p }}快速输出表单，再自己控制一下样式即可。这里有个小细节：一定要在视图里加登录之后的重定向逻辑，否则用户登录完还停在登录页，体验很差，答辩演示的时候也会显得不专业。

4.2 宠物列表和筛选

宠物列表是游客也能访问的公开页面，但只有登录用户能提交申请。列表页要展示宠物卡片，包含照片、昵称、品种、状态标记。筛选功能的实现比想象中简单，用基础的filter链式查询就够了：

def pet_list(request): pets = Pet.objects.filter(status='available').select_related('category') category = request.GET.get('category') gender = request.GET.get('gender') vaccinated = request.GET.get('vaccinated') if category: pets = pets.filter(category_id=category) if gender: pets = pets.filter(gender=gender) return render(request, 'pets/pet_list.html', { 'pets': pets, 'categories': PetCategory.objects.all(), })

select_related在这里要养成习惯。宠物表外键关联了分类表，列表页要显示分类名，如果不做关联查询，每渲染一个宠物卡片就会多一次数据库查询，宠物多了页面就卡，这叫 N+1 问题。select_related一条语句把分类数据带出来，这是个值得在答辩时主动讲出来的优化点。

4.3 宠物详情与申请提交

详情页除了展示宠物信息，还要根据当前状态显示不同内容：宠物可领养且用户已登录，显示“申请领养”按钮；不可领养则显示“已找到温暖的家”；用户已经申请过，显示“您已提交申请，等待审核”。

提交申请的表单需要把user和pet跟表单里的内容一起保存：

class AdoptionForm(forms.ModelForm): class Meta: model = AdoptionApplication fields = ['reason', 'housing', 'experience'] widgets = { 'reason': forms.Textarea(attrs={'rows': 3, 'placeholder': '请说明您为什么想领养它'}), 'housing': forms.TextInput(attrs={'placeholder': '例如：自有住房，60平米小区房'}), } def apply_adoption(request, pet_id): pet = get_object_or_404(Pet, id=pet_id) if pet.status != 'available': messages.error(request, '这只宠物已经名花有主啦') return redirect('pets:pet_detail', pet_id=pet.id) if AdoptionApplication.objects.filter(user=request.user, pet=pet, status='pending').exists(): messages.warning(request, '您已经提交过申请，请等待审核') return redirect('pets:pet_detail', pet_id=pet.id) if request.method == 'POST': form = AdoptionForm(request.POST) if form.is_valid(): application = form.save(commit=False) application.user = request.user application.pet = pet application.save() messages.success(request, '申请提交成功，我们会尽快审核') return redirect('adoption:my_applications') else: form = AdoptionForm() return render(request, 'adoption/apply.html', {'form': form, 'pet': pet})

这段逻辑里有三个关键判断，分别是宠物状态校验、重复申请校验和表单数据绑定。尤其第二个判断，如果不做，同一个用户可以反复提交几十条申请，管理端审核页面会炸掉。这属于典型的“边界条件处理”，写的时候多一点思考，后面省的是大量返工时间。

4.4 个人中心：我的申请和收藏

个人中心页至少包含两块：我的领养申请列表、我的收藏。申请列表要展示每只宠物、申请时间、当前审核状态。状态建议用颜色标签区分：待审核黄色、已通过绿色、已拒绝红色、已完成蓝色。这样的 UI 细节看似简单，但直观性非常重要，答辩演示时评委一眼就能看懂流程。

收藏功能的实现也不复杂，因为收藏本质上是一个多对多关系：

class Favorite(models.Model): user = models.ForeignKey(settings.AUTH_USER_MODEL, on_delete=models.CASCADE) pet = models.ForeignKey(Pet, on_delete=models.CASCADE) created_at = models.DateTimeField(auto_now_add=True) class Meta: unique_together = ('user', 'pet')

unique_together确保一只宠物只能被同一个用户收藏一次，这是数据层面的防重。页面上的收藏按钮用传统的 POST 提交或 Ajax 都可以，毕设阶段用普通 POST 比较省事，演示也稳定。

5. 管理端开发：审核状态机的完整闭环

管理端是这个项目最体现功力的地方，也是答辩时最容易被深挖的部分。Django Admin 虽然好用，但直接拿来当毕设管理界面会显得诚意不足，建议自己写一套精简的管理页。注意这里说的是“精简”，不上很多复杂框架，用 Django 模板加一点 Bootstrap 就足够。

5.1 后台首页与数据概览

管理后台入口用装饰器做权限控制：

from django.contrib.auth.decorators import login_required, user_passes_test def is_admin(user): return user.is_staff @login_required @user_passes_test(is_admin) def admin_dashboard(request): context = { 'pet_count': Pet.objects.count(), 'pet_available_count': Pet.objects.filter(status='available').count(), 'application_pending_count': AdoptionApplication.objects.filter(status='pending').count(), 'application_approved_count': AdoptionApplication.objects.filter(status='approved').count(), 'recent_applications': AdoptionApplication.objects.order_by('-created_at')[:10], } return render(request, 'admin_pages/dashboard.html', context)

首页放四个统计卡片，外加最近十条申请记录，这既满足管理系统的基本需求，又让管理端看起来不是空壳子。数据统计这块如果还想加点料，可以用“近7天新增申请”这种数字，但不需要引图表库，纯数字展示完全足够。

5.2 宠物管理：上架与下架的完整生命周期

管理员发布宠物信息时，表单要包含：分类、昵称、品种、年龄、性别、是否疫苗、是否绝育、性格描述和照片。保存时status自动置为available，这样新发布的宠物会立刻出现在用户端列表中。

下架操作不要直接删宠物，而是要提供一个“下架”按钮，把status改为off_shelf。这个设计的合理性在于：管理员可能是临时下架，而不是要彻底移除这只宠物；而且以后做数据分析时，下架的宠物记录还留存在系统里，有迹可循。用户在列表页通过filter(status='available')自然看不到下架宠物，数据上又不会丢，这才是正规做法。

5.3 审核领养申请：最核心的管理功能

这个页面列出的待审核申请是管理端的头号任务。审核页面要展示申请人信息（用户名、注册时间）、申请理由、居住情况和宠物完整信息，方便管理员判断是否通过。审核动作就两个按钮：通过、拒绝。拒绝时必须要填备注，这是强制项，原因很简单：用户需要知道自己为什么被拒。

def review_application(request, app_id): application = get_object_or_404(AdoptionApplication, id=app_id) if request.method == 'POST': action = request.POST.get('action') remark = request.POST.get('remark', '') if action == 'approved': application.status = 'approved' application.admin_remark = remark application.save() pet = application.pet pet.status = 'adopted' pet.save() # 同时拒绝同一只宠物下其他待审核申请 AdoptionApplication.objects.filter( pet=pet, status='pending' ).exclude(id=application.id).update( status='rejected', admin_remark='该宠物已被领养' ) elif action == 'rejected': application.status = 'rejected' application.admin_remark = remark application.save() return redirect('admin_pages:application_list') return render(request, 'admin_pages/review_application.html', { 'application': application })

这里的亮点在通过审核后的联动逻辑：同一只宠物可能同时有多条pending申请，通过一条之后，其余全部要自动置为rejected。这个操作往深了说是防止数据冲突——宠物已标记领养，就不能再有任何悬挂的待审申请。这是整个系统最核心的一个逻辑判断，也是业务复杂度的主要体现。我建议所有做这个题目的同学，答辩时主动讲讲这段代码，因为它是最好的一块“亮点展示面”。

5.4 完成领养闭环

审核通过不等于流程结束。管理员还需要一个“确认完成”的入口，把approved状态改成completed。这样用户端“我的申请”页面的状态会从绿色标签变成蓝色标签，宠物页面显示“已被人领养”。加这个环节的意义在于流程完整性，一个完整的状态机应该是pending -> approved -> completed，或者pending -> rejected，不应该是pending -> approved就戛然而止。

管理端的导航结构建议做成：控制台、宠物管理、领养审核、申请列表、用户管理、公告管理。每个菜单对应一个 URL 和视图，模板统一继承一个base_admin.html，左侧固定侧边栏，右侧内容区，整体看起来就像个正规的后台系统。这套布局不复杂，但对答辩展示效果提升巨大。

6. 页面模板与交互细节：让毕设看起来“不像是交作业”

页面做得好不好看，直接决定了答辩时评委的第一印象。技术栈上用 Bootstrap 5 的 CDN 加 Django 模板继承就够了。我建议做三个基础模板：base.html（面向用户端）、base_admin.html（面向管理端）、base_auth.html（面向登录注册页）。模板继承的好处是所有页面头部尾部统一，改一处全站生效。

用户端首页要的是那种有温度、有氛围的感觉。大 Banner 放一张宠物合照，下面加一句“用领养代替购买”这类标语，下面再放最新上架的宠物卡片。卡片上要突出显示状态标签，比如橙色标签写“待领养”，灰色写“已领养”，一眼就能分辨。这个细节看似简单，但直接影响用户浏览效率。

表单页面要处理好的问题是错误提示。Django Form 自动生成的错误消息默认样式很丑，在模板中用field.errors定制一下展示样式：

<div class="mb-3"> <label class="form-label">{{ field.label }}</label> {{ field }} {% if field.errors %} <div class="text-danger small">{{ field.errors }}</div> {% endif %} </div>

这种细节做与不做，对整个答辩的效果差别很大。评委现场点“提交空表单”，看到的是整齐的红色错误提示，和看到一坨 Python 报错，对项目的评价会完全不一样。

模板层的另一个重点是消息提示。用django.contrib.messages显示操作结果：

{% if messages %} {% for message in messages %} <div class="alert alert-{{ message.tags }}">{{ message }}</div> {% endfor %} {% endif %}

提交成功、审核通过、操作失败，都要有对应的用户反馈，这是专业系统和练习项目的一个明显分水岭。

7. 本地开发到线上部署：给毕设一个可访问的 URL

这个项目做完在本地跑通，只是完成了 70%，剩下 30% 是部署上线。即使毕设不强制要求线上演示，我也强烈建议你部署到线上——答辩现场直接在浏览器里打开公网地址演示，比在本地跑起来要亮眼得多，也更能应对“随机应变”的提问场景。

7.1 开发阶段的 settings 配置

开发展阶段要改的配置集中在settings.py：

• INSTALLED_APPS里追加自己的 app 和'django.contrib.humanize'
• LANGUAGE_CODE = 'zh-hans'
• TIME_ZONE = 'Asia/Shanghai'
• MEDIA_URL = '/media/'，MEDIA_ROOT = BASE_DIR / 'media'
• STATIC_URL = '/static/'，STATICFILES_DIRS = [BASE_DIR / 'static']

这里有个经常被忽略的点：时区设置。不设置TIME_ZONE的话，数据库存的创建时间会跟本地差八个小时，用户提交申请的时间显示是错的，这个在答辩时非常尴尬。用Asia/Shanghai并且USE_TZ = True，Django 在模板层会按当前时区渲染时间，问题就解决了。

7.2 部署前的调整

本地用runserver没问题，但正式部署就不要再用了，那是个开发服务器，性能不行也不安全。标准做法是gunicorn + nginx。

部署前的必要配置调整：

• DEBUG = False，这个不改，线上会把错误堆栈直接暴露给访客，非常丢人
• ALLOWED_HOSTS = ['你的域名或IP']
• STATIC_ROOT = BASE_DIR / 'staticfiles'，然后执行collectstatic把所有静态文件收集到一个目录
• 数据库迁移要在服务器上执行一遍，首次部署就是migrate之后创建超级用户
• media 目录要确保有写权限，否则管理员传不了宠物照片

参考的 gunicorn 启动命令：

gunicorn config.wsgi:application --bind 127.0.0.1:8000 --workers 3

nginx 配置负责监听 80 端口并转发给 gunicorn，同时把/static/和/media/的请求直接交给文件系统处理：

server { listen 80; server_name your_domain_or_ip; location /static/ { alias /path/to/staticfiles/; } location /media/ { alias /path/to/media/; } location / { proxy_pass http://127.0.0.1:8000; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } }

如果你用的是国内云服务器，记得在云控制台的安全组放行 80 端口，这个排查起来很容易被忽略掉。另外如果申请了自己的域名，建议用域名而不是 IP，答辩环境如果临时需要切换网络，域名访问会更稳。

7.3 部署前的数据准备

上线前一定要准备几组“看起来真实”的数据：五六个宠物分类，每类两三只宠物，配好真实感的照片和性格描述，再加几条领养申请。你可以在 Django Admin 或者自己的管理后台里手工录入，也可以写一个data init的 management command 一次性灌入。总之不要部署完是空数据库，演示效果会大打折扣。

8. 开发中绕不过的坑：实测验证过的排错清单

最后这部分，我把这个项目开发过程中最容易踩、最耽误时间的坑集中列一下，都是我实际验证过的，能帮你在 debug 上少花很多时间。

8.1 图片上传后不显示

本地开发时，<img src="/media/xxx.png">访问不到文件，十有八九是 urls 里没有配media的静态服务。必须在config/urls.py中加：

from django.conf import settings from django.conf.urls.static import static urlpatterns = [...] if settings.DEBUG: urlpatterns += static(settings.MEDIA_URL, document_root=settings.MEDIA_ROOT)

部署环境如果也不显示，多半是 nginx 的/media/location 没写对，检查 alias 的路径和MEDIA_ROOT是否一致。

8.2 CSRF token 报错

模板里的所有 POST 表单，<form>标签内必须写{% csrf_token %}。如果你用了 Ajax 提交，需要先在页面里读取 csrf token 再放到请求头里，否则 Django 会拒绝请求。这是 Django 的安全防护机制，报错时不要关闭 CSRF，正确做法是补齐 token。

8.3 安装 Pillow 失败

ImageField依赖 Pillow 库。Windows 上如果pip install pillow失败，多半是 Python 版本和 Pillow 版本不匹配，建议直接升级 Python 到 3.10+，再pip install --upgrade pillow重装。这个问题新手经常遇到，没什么复杂的，装不上就升级环境。

8.4 外键删除导致的数据异常

Pet 关联 Category，如果分类被删除，Pet 外键就会悬空。你可以在Pet模型里用on_delete=models.PROTECT，这样有宠物引用时分类不允许删除。反过来，如果删除 User，他的领养申请怎么办？on_delete=models.CASCADE会级联删除申请记录，这样用户的个人页不会出现申请已失效但宠物还在的情况，属于合理选择。

8.5 列表页查询性能

宠物列表页如果渲染了分类名称、状态标签，每次循环都会触发数据库查询，数据量小看不出来，数据量大了页面就很慢。记得用select_related('category')做关联查询，这是对 QuerySet 最基本的性能优化。答辩时如果评委问“你这个系统的数据库设计有什么考虑”，这绝对是一个应答点。

8.6 重复申请与并发问题

我在实现时用“查询是否存在 pending 申请”来防止重复提交，但这种检查在并发场景下并不完全可靠。如果有两个请求同时通过检查，可能会出现重复记录。更严谨的做法是在数据库层面加UniqueConstraint(fields=['user', 'pet'], condition=Q(status='pending'))做条件唯一约束。毕设阶段你的并发压力很小，普通检查足够，但如果想做得更讲究，用条件唯一约束是更专业的方案。

8.7 登录状态下权限控制

用户端页面要做两个检查：未登录用户点击“申请领养”要跳转到登录页；管理员页面非 staff 用户要禁止访问。装饰器@login_required和@user_passes_test分别处理这两种情况。千万不要只在前端隐藏按钮，后端不校验，否则别人直接拼 URL 照样能访问到受保护的功能。

个人最后再提醒一句：做完功能后，一定要写一份 README，把自己搭建环境的步骤、账号密码、测试数据路径都写清楚。这不仅是给评委和后续维护的人看的，也是给自己留下的完整记录。一个系统能做出来是一回事，能让人快速跑起来是另一回事，后者在答辩中的分量比很多人想象中重得多。按照这套流程走下来，这个题目的实现难度并不算大，但完成度和专业度都会在平均水平之上。