企业官网建设流程全解析

每年到了毕设选题的季节，总会有人问我：“智慧社区”这种题目到底怎么做才不显得空？前端要不要上Vue、后端要不要搞微服务、数据库是不是得用Redis缓存一堆东西？我去年用 Python + Django 把整套智慧社区系统完整落地过一遍，源码、数据库脚本、设计文档都齐全，从选题到答辩前后折腾了三个多月。这篇就把我在这个项目里的功能拆解、数据库设计、落地过程以及那些不跑到最后根本发现不了的坑，一次性讲清楚。

这套东西适合几类人参考：正在做毕业设计或课程设计、想选智慧社区方向的同学；已经会了一点 Django、想通过一个完整项目把 ORM、Admin、表单、权限这些知识点串起来的人；还有纯粹想了解“小区物业管理信息化到底在管什么”的读者。我会尽量少说废话，多给能直接抄作业的内容。

1. 先搞清楚：一个智慧社区系统到底要做成什么样

1.1 它解决的是谁的问题

很多同学一上来就急着建表写代码，结果做着做着发现功能是凑出来的，不知道哪些该做哪些不该做。我做这个项目之前先花了整整两天去“拆需求”，核心只回答一个问题：智慧社区系统是为谁服务的，他要干什么。

在真实场景里，一个小区的日常事务大概是这样的：业主入住之后要去物业登记信息、绑定自己名下的房屋；家里水管漏了、门禁坏了，业主需要找物业报修；每个月物业费、水费、停车费要有人通知、有人缴纳；物业要发停水停电公告、小区活动通知；业主对物业服务不满意，还得有渠道投诉；来访的客人要登记。把这些前前后后的角色捋清楚，系统的边界就出来了。

所以智慧社区系统的本质不是“做一个花哨的网页”，而是把物业、业主、公共事务这三者之间的信息流和业务流搬到线上。核心角色就是两类：业主和物业管理员，外加一个用来做数据维护的系统管理员。我的项目里有业主端、物业端和管理后台三块界面，但底层共用同一个 Django 工程，靠登录角色和权限去控制能看什么、能操作什么。

1.2 功能模块怎么拆才不臃肿

功能拆分最忌讳的就是“大而全”，一个毕设项目不可能真的做到刷脸开门、智能门禁、物联网设备联动，硬做反而会把自己拖垮。我的做法是围绕高频事务，选五个核心模块：

• 房产管理：楼栋、单元、房号这些基础数据的维护，以及业主和房屋的绑定关系
• 报修管理：业主提交报修单，物业接单、处理、回写状态
• 缴费管理：物业生成账单，业主查看并标记缴费
• 公告管理：物业发布公告，业主在首页或列表页查看
• 投诉建议：业主提交投诉，物业进行回复处理

这五个模块围绕一个主线：业主在系统里能查房、报修、交费、看通知、提投诉，物业在后台能维护房屋、处理工单、发布公告、管理账单。逻辑闭环，答辩的时候也能讲清楚“你为什么要做这几个功能而不是别的”。

1.3 为什么选 Python + Django 而不是其他组合

我在选题时也纠结过要不要上 Spring Boot，后来还是选定了 Django，原因分三层。第一层是开发效率，Django 自带 Admin 后台、用户认证系统、ORM 数据库映射、表单处理和模板引擎，这些恰好是“传统管理信息系统”最需要的骨架功能。相当于一个毛坯房已经帮你砌好了承重墙，你只需要做内部装修。第二层是代码可读性，Python 的语法天然适合课程设计和毕设场景，从你手里接过项目代码的答辩老师，读起来也不会有太多障碍。第三层是生态成熟，Django 的文档、中文教程、第三方包的丰富程度在 Web 框架里属于第一梯队，卡住的时候搜一下基本都有现成解法。

前端方面我没有用前后端分离方案，没有上 Node 和 Vue，而是用 Django 模板语法 + Bootstrap 做的服务端渲染页面。我知道一部分人会质疑“这样是不是太土了”，但在毕设项目里，这套方案最大的优势是你不需要维护两套工程，不需要处理跨域，不需要额外写接口文档。页面可以直接在服务端渲染出来，演示的时候更稳定，也不会因为前端打包出问题导致整个系统跑不起来。如果后续想升级成前后端分离，现成的 Model 和 View 逻辑改造成 Django REST Framework 接口也不费劲。

2. 数据库设计：把“房、人、事”三者串起来

2.1 核心表结构是怎么定的

数据库是整个项目的底盘，表结构设计得清不清楚，直接决定后面写业务代码是顺手还是到处补丁。我在设计时没有一下子铺开十几张表，而是先画了一个“人楼事”的对应关系：人指的是用户（业主和物业），楼指的是房屋档案，事指的是报修、缴费、公告、投诉这些业务记录。几乎每一张业务表，都离不开用户和房屋这两个外键。

我最终落地的核心表大概如下：

• User：Django 自带的用户模型扩展，增加 phone、avatar 等字段
• House：房屋档案，包含楼栋、单元、房号、面积、户型等基础信息
• Owner：业主档案，关联 User 和 House，标记入住状态
• RepairOrder：报修单，关联业主、房屋、处理人，记录故障描述、处理状态、时间
• PaymentBill：缴费单，关联房屋、费用类型、周期、金额、状态
• Notice：公告，包含标题、正文、发布时间、发布人
• Complaint：投诉建议，关联业主、房屋、回复内容
• ParkingSpace：车位信息，关联业主和房屋，用于扩展演示

表数量控制在七到十张之间，既能撑起完整的故事线，又不会把自己困在数据维护的泥潭里。这也是为什么我没有一上来就加入访客登记、快递代收、社区团购之类的表——功能可以做文章里提，但表太多，前后期维护成本会成倍上升。

2.2 用 Django 模型定义这两张关键表的写法

下面我把报修单和缴费单的模型代码贴出来，因为这两张表是项目里最典型的“业务流数据表”。注意我加了 class Meta 里的 ordering 和 verbose_name，写明细字段时尽量把 help_text 也补上，后面后台和页面上提示会清晰很多。

from django.db import models from django.contrib.auth.models import User class House(models.Model): building = models.CharField('楼栋', max_length=20) unit = models.CharField('单元', max_length=20) room = models.CharField('房号', max_length=20) area = models.DecimalField('面积(㎡)', max_digits=8, decimal_places=2) owner = models.ForeignKey( 'Owner', on_delete=models.SET_NULL, null=True, blank=True, related_name='houses', verbose_name='业主' ) class Meta: verbose_name = '房屋档案' verbose_name_plural = verbose_name unique_together = ('building', 'unit', 'room') def __str__(self): return f'{self.building}栋{self.unit}单元{self.room}室' class RepairOrder(models.Model): STATUS_CHOICES = ( ('pending', '待处理'), ('processing', '处理中'), ('done', '已完成'), ('rejected', '已驳回'), ) owner = models.ForeignKey('Owner', on_delete=models.CASCADE, verbose_name='业主') house = models.ForeignKey('House', on_delete=models.CASCADE, verbose_name='房屋') title = models.CharField('报修标题', max_length=100) description = models.TextField('故障描述') status = models.CharField('状态', max_length=20, choices=STATUS_CHOICES, default='pending') handler = models.ForeignKey( User, on_delete=models.SET_NULL, null=True, blank=True, related_name='handled_repairs', verbose_name='处理人' ) created_at = models.DateTimeField('提交时间', auto_now_add=True) updated_at = models.DateTimeField('更新时间', auto_now=True) class Meta: verbose_name = '报修工单' verbose_name_plural = verbose_name ordering = ['-created_at'] def __str__(self): return f'{self.house}-{self.title}'

这里面有三个细节特别值得留意。第一个是 Owner 和 House 的关系，我最初考虑的是一个业主名下可能有多套房，一个房屋也可能夫妻两个人共有，这属于典型的多对多关系。但如果设计成 M2M 表，页面和表单的复杂度会明显增加，所以我最后用了一个折中方案：House 上保留一个外键 owner 字段，业务上按“一房一主”演示。答辩问起来，也可以坦诚说这是为了控制复杂度做的简化，真正生产环境应该用中间表。第二个细节是外键的 on_delete 参数，报修单关联的业主如果被删了，工单应该跟着删，用 CASCADE 没问题；但处理人属于员工，员工离职不应该影响历史工单，所以用 SET_NULL 配合 null=True。第三个是 created_at 和 updated_at 的自动时间字段，这类字段几乎是每张业务表的标配，别看简单，少了它后面做列表排序会很痛苦。

2.3 手写 SQL 还是直接相信 Django 迁移

因为项目交付物里包含数据库文件，我特意研究了一下怎么把数据库整理成可以分发的形式。Django 的迁移体系已经足够强大，只要在开发机上执行 makemigrations 和 migrate，所有表结构和索引都会自动生成。我并没有手写建表 SQL，而是把开发环境里已经初始化好演示数据的 SQLite 或 MySQL dump 导出，作为一个“初始数据库文件”随项目分发。

这里补充一个实操建议：如果你用 MySQL，导出的 SQL 里记得要带 utf8mb4 字符集设置；如果你为了方便演示直接使用 SQLite，那连数据库客户端都不用装，项目跑起来就能用。但毕设文档里建议还是写 MySQL，因为 MySQL 在企业场景里更常见，答辩时更有说头。两条路我都跑通过，最终交付时我保留了 MySQL 的建库脚本，也附了一个 SQLite 的免配置版本。

3. 把项目拉起来：环境配置到首次启动全流程

3.1 开发环境我用的什么版本组合

版本问题看上去不起眼，实际上是最容易卡住新手的环节。我的推荐组合是 Python 3.10 以上版本、Django 4.2 LTS 版本、MySQL 8.0。Django 4.2 属于长期支持版本，各种第三方库兼容性最好，网上资料也多。Python 千万别用 3.13 以上的最新版本搭配旧版 Django，有些依赖包编译不过去，你会浪费大量时间。

MySQL 用不用 Docker 全看个人习惯。我自己第一次配置时是直接在 Windows 上装的 MySQL 8.0，安装时勾选了“Use Legacy Authentication”，这一步很关键，否则后面 mysqlclient 连接时会验证插件报错。后来图省事也试过用 Docker 跑 MySQL，速度反而更快，命令就一行：

docker run --name community-mysql -e MYSQL_ROOT_PASSWORD=123456 -e MYSQL_DATABASE=community -p 3306:3306 -d mysql:8

3.2 创建虚拟环境、工程和 App

我一般会先在项目根目录建一个虚拟环境，把所有依赖装在里面，避免污染全局 Python 环境。Windows 下执行：

python -m venv venv venv\Scripts\activate

Linux 和 Mac 下对应的是 source venv/bin/activate。然后安装依赖包：

pip install django==4.2.9 mysqlclient==2.2.0 Pillow

这里 mysqlclient 在 Windows 上经常装不上，如果报错提示缺少 Visual C++ 构建工具，最简单的方式是改用 pymysql。pip install pymysql 之后，在项目目录的init.py 加上两行：

import pymysql pymysql.install_as_MySQLdb()

接下来创建工程和 App：

django-admin startproject smart_community cd smart_community python manage.py startapp community

我的项目结构是这样组织的：smart_community 是工程配置目录，里面放 settings.py、urls.py；community 是业务 App，models.py、views.py、urls.py 都在这里面。一开始只有一个业务 App，后续如果你要加“停车场管理”之类的新模块，可以再创建 park 之类的 App，但毕设阶段不建议拆太细，拆多了光是在多个 App 之间同步外键关系就够你喝一壶。

3.3 settings.py 里的几个关键配置

settings.py 是整个项目的配置枢纽，有五个地方必须改对，不然等会跑起来全是莫名其妙的毛病。

# 数据库配置 DATABASES = { 'default': { 'ENGINE': 'django.db.backends.mysql', 'NAME': 'community', 'USER': 'root', 'PASSWORD': '123456', 'HOST': '127.0.0.1', 'PORT': '3306', 'OPTIONS': { 'charset': 'utf8mb4', }, } } # 语言与时区 LANGUAGE_CODE = 'zh-hans' TIME_ZONE = 'Asia/Shanghai' USE_TZ = True # 静态文件和媒体文件 STATIC_URL = 'static/' STATICFILES_DIRS = [BASE_DIR / 'static'] MEDIA_URL = '/media/' MEDIA_ROOT = BASE_DIR / 'media' # 登录跳转 LOGIN_URL = '/login/' LOGIN_REDIRECT_URL = '/dashboard/' LOGOUT_REDIRECT_URL = '/login/'

LANGUAGE_CODE 设为 zh-hans 之后，Django Admin 后台会变成中文界面。TIME_ZONE 设置为 Asia/Shanghai，同时把 USE_TZ 保持为 True，这样数据库里存的是带时区的 UTC 时间，渲染时 Django 会自动转换成本地时间。有同学图省事直接 USE_TZ = False，短期看着没问题，但如果你在文档里强调数据模型规范，还是会有点心虚，所以我建议保持 True 并且在模板里用模板过滤器转换。

3.4 迁移建表、创建管理员、准备演示数据

配置完成后，执行三条命令把表结构建出来并创建管理员：

python manage.py makemigrations python manage.py migrate python manage.py createsuperuser

createsuperuser 需要输入用户名、邮箱和密码，这个超级管理员属于“系统管理员”，登录之后能访问 Django Admin 后台。我还会用 fixture 的方式准备一批演示数据。具体做法是先往开发库里录入几栋楼、十来套房、几个测试业主和几条报修记录，然后执行：

python manage.py dumpdata > initial_data.json

之后换环境部署时，执行 python manage.py loaddata initial_data.json 就能把整套带数据的初始状态还原出来。这种方式比分发 SQL 脚本要干净，因为它是 Django 原生的序列化格式，不会因为数据库类型不同而出问题。

一切就绪后，python manage.py runserver，浏览器访问 http://127.0.0.1:8000 就能看到系统首页。首次跑通整个流程的成就感还是很强的，但这才只是万里长征第一步，后面功能实现才是真正的重头戏。

4. 核心功能落地：绑定、报修、缴费、公告和管理后台

4.1 业主注册、登录与房屋绑定

Django 自带的认证系统已经覆盖了注册登录的核心逻辑，我们要做的只是扩展一个带手机号等字段的业主档案。注册表单我放在 community/forms.py 里，注册成功之后自动创建一个 Owner 记录并把当前 User 关联进去。这里最需要注意的是“房屋绑定”的设计，因为房子是后续所有业务数据的锚点。

我的做法是这样的：注册后进入“我的房屋”页面，页面显示当前账号绑定的房屋列表和一个“申请绑定”的表单，表单里选择楼栋、单元，输入房号。提交之后不会立即绑定成功，而是生成一条“绑定申请”记录，由物业管理员在后台确认后才能生效。这样做的好处有两点：一是防止有人恶意把自己绑到别人家房号上；二是在毕设答辩时可以讲到一个“流程审批”的场景，让系统有更完整的业务感。

当然，为了演示方便，我在初始数据里直接让一部分测试账号已经绑定了房屋。“先绑定，后报修”这个规则我在页面顶部写得很清楚，避免演示时手忙脚乱。

4.2 报修工单的状态流转

报修是最能体现“流程感”的模块，状态字段只有四个：待处理、处理中、已完成、已驳回。状态流转不是只改一个字符，而是对应不同角色的不同操作按钮。

业主提交报修单时，选择要报修的房屋，填写标题和故障描述。提交后工单状态为“待处理”，业主端页面只显示“撤单”按钮。物业端看到待处理列表后，点击“接单”，状态变为“处理中”，同时记录处理人。如果物业觉得描述不清楚或者不属于服务范围，可以填写驳回原因，状态变为“已驳回”。处理完成时状态变为“已完成”，业主端能查看整个流转时间线。

实现的时候，我直接在 views.py 里写了不同的处理函数，每个函数用权限装饰器限定角色。比如接单操作对应 handle_order 函数，里面判断 request.user 是否 staff 身份，再更新 handler 和 status。这样的代码逻辑非常直白，答辩时对着代码讲也比面面俱到的设计模式更有说服力。

页面上我用了不同颜色的 Bootstrap 标签区分状态，待处理是黄色，处理中是蓝色，已完成是绿色，已驳回是灰色。人都是视觉动物，红绿灯式的状态标签能让评委一眼看出系统有没有“活”起来。

4.3 物业缴费：账单生成与业主操作

缴费模块的关注点不在于“真实支付”，而在于账单的生成、查询和状态更新。物业管理员在后台选择房号、填写费用类型（物业费/水费/停车费）、金额和周期，创建一条缴费单。业主端登录后进入“我的账单”，能看到房屋下所有账单及状态，待缴费的账单旁边有一个“去缴费”按钮。

点击“去缴费”会进入一个确认页，如果选择“在线支付”，由于没有接入真实支付网关，系统会调起一个“模拟支付”的步骤——点击确认后，payment_status 从 unpaid 改为 paid，同时记录支付时间。这个逻辑虽然简单，但已经覆盖了一个完整支付流程的状态机。要是答辩老师问为什么不接入真实支付，你可以直接说：出于演示安全考虑以及支付资质问题，使用模拟支付网关完成闭环验证，如果项目需要，可以接入支付宝或微信支付的开放接口。

这里有一个细节值得注意：账单不要做成“一个房子只有一个账单”。我的 PaymentBill 表里加了 period_start 和 period_end 字段，也就是账单周期，这样每套房可以有多个月份的账单，费用明细也能按月拆开。加了这个字段以后，查询“某套房最近三个月账单”这种需求就非常简单了。

4.4 公告模块：让信息触达业主

公告模块看起来简单，但它是整个系统里边角料最少、最容易出效果的功能。物业发布公告之后，业主首页就展示最新三条公告，公告列表页展示全部，并且按发布时间倒序。我做了富文本支持，公告正文里可以包含图片链接和简单的 HTML 标签，展示效果比纯文本好很多。

发布公告是在 Django Admin 后台完成的，操作路径是：首页 -> 公告 -> 添加公告。为了让公告在业主端有“提醒感”，我在首页顶部做了一个 Bootstrap alert 组件，如果有未读公告（通过 id 大于本地记录判断），就显示一条蓝色提示条。这个“未读判断”如果做精细，需要建已读表，但毕设场景下用一个简单逻辑替代就行，我在 docs 里也单独说明过。

4.5 管理后台：用 Django Admin 扛起物业端一半功能

Django Admin 是这套技术栈最“白送”的价值。你只要在 admin.py 里注册对应的模型，后台就能自动生成增删改查界面。但默认界面比较粗糙，如果你不想被老师质疑“这个后台是不是自己做的”，一定要花一点时间做几件事。

首先是在 list_display 里配置要显示的字段，比如报修单里显示标题、房屋、状态、处理人、提交时间。其次是添加 list_filter，让后台左侧能按状态筛选。然后是 search_fields，给业主搜索加个按姓名、房号检索的能力。最后可以加一个 raw_id_fields，当外键的数据量比较大时，下拉框会卡，换成搜索框体验更好。

下面是我 admin.py 里报修单的部分配置，可见度和可操作性都提升了一截：

@admin.register(RepairOrder) class RepairOrderAdmin(admin.ModelAdmin): list_display = ('title', 'house', 'status', 'handler', 'created_at') list_filter = ('status', 'created_at') search_fields = ('title', 'house__building', 'house__unit', 'house__room') list_editable = ('status',) raw_id_fields = ('owner', 'house', 'handler') date_hierarchy = 'created_at'

list_editable 这个参数特别好用，它让你不需要点进详情页就能在列表页直接修改状态。物业端处理报修的场景，正好可以勾选状态、点击保存，效率非常高。我现在还记得第一次把这个配置加进去之后，处理报修单的速度提升了不止一倍，再也不用为了改一个状态点进详情页了。

5. 常见问题与排查实录

5.1 mysqlclient 安装失败、连接 MySQL 报错

这是环境阶段遇到最多的问题。Windows 下直接 pip install mysqlclient 很大概率报“Could not build wheels for mysqlclient”，原因是缺少 C++ 编译环境。我处理过两次：一次老老实实装 Visual Studio Build Tools，耗时很长；另一次直接用 pymysql 替代，三分钟搞定。如果你只需要在本地跑通项目，pymysql + install_as_MySQLdb() 是最省事的方式。但注意，如果项目要部署到 Linux 服务器，mysqlclient 的安装就顺畅得多，apt install 依赖后基本没问题。

另一个高频报错是：

django.db.utils.OperationalError: (2067, 'Specified key was too long; max key length is 3072 bytes')

这是 MySQL 5.7 或 8.0 的字符集默认配成了 utf8mb4，索引长度受限。解决办法是在 DATABASES 的 OPTIONS 里强制指定 charset='utf8mb4'，并确保数据库本身的字符集是 utf8mb4。如果建库时没指定，可以在 MySQL 里执行 ALTER DATABASE community CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci 修一下。

5.2 时间比本地区时间晚了 8 小时

这个坑我印象太深了。第一次跑通项目时，报修单创建时间显示比本地时间整整慢了 8 小时，我一度以为是 MySQL 时区问题，后来定位到是 Django 的 TIME_ZONE 和 USE_TZ 没配对。

正确姿势：settings.py 里 TIME_ZONE = 'Asia/Shanghai'，且 USE_TZ = True。这样 Django 会在存储时把本地时间转成 UTC 存进数据库，在模板渲染时再转回本地时间。如果你在模板里直接用 {{ order.created_at }}，输出的时间会根据当前时区自动显示成本地时间，不需要额外处理。只有当你在 Python 视图里手动格式化时间时，要记得使用 django.utils.timezone.localtime 做转换。

5.3 Admin 后台样式全部丢失、静态文件 404

DEBUG=True 时，Django 会自动帮你托管静态文件，包括 Admin 的 CSS 和 JS。但如果你在 settings.py 里把 STATICFILES_DIRS 配错了路径，或者其他静态文件引用顺序出了问题，就会导致后台页面裸奔。检查顺序是先确认 DEBUG 是 True，再看浏览器控制台里哪个静态文件 404，然后对照 STATIC_URL 和 STATICFILES_DIRS 的路径。实在不行，就执行 collectstatic 把文件收集到 STATIC_ROOT，再通过 whitenoise 或 nginx 托管。毕设阶段 90% 的问题出在 DEBUG 配置上，把 DEBUG=True 保持住，基本不会出现样式丢失。

5.4 表单提交报 403 CSRF verification failed

这个问题新手上路必踩。Django 默认开启 CSRF 防护，模板里的 POST 表单必须包含 {% csrf_token %}。如果用的是 AJAX 提交，还需要在请求头里带上 X-CSRFToken，从 cookie 里读取值。我在业主提交报修的表单里就吃过亏，后来统一在 form 标签内加了 csrf_token，同时给所有 AJAX 请求加了一个公共的 headers 设置，之后再也没有出现过 403。

5.5 删除外键关联数据时的 ProtectedError

这算是设计层面的问题。我在建巡检记录表的时候，给外键设了 on_delete=models.PROTECT，结果后期想删一条测试房产数据时，Django 抛了 ProtectedError。解决方案是明确每张表外键的删除策略：业务主表（如房屋）被业务明细表（如报修单）引用时，通常应该保护删除，防止误删导致数据链断开；但如果你确实要删除，应先在关联表里把对应记录清理掉，或者在 on_delete 里改成 CASCADE。关键是这个决策要在设计阶段想清楚，而不是等报错了再看。

5.6 问题排查速查表

6. 收尾阶段：文档交付、演示准备和一些实在建议

项目源码、数据库、文档三件套都齐了，不代表项目就完成了。我最后花了一整天时间专门整理交付文档，内容包括项目介绍、环境依赖清单、部署步骤、功能说明、表结构说明和测试账号。有些同学觉得文档是形式主义，但在实际答辩和评审里，文档决定了别人能不能顺利把你的项目跑起来，也决定了你对自己项目的理解深度。把部署步骤写到“傻瓜级”，把每个模块对应到代码路径，把测试账号列清楚，后续给老师演示时能省下大量解释成本。

演示之前有一件事特别值得做：建几个不同角色的测试账号。我的做法是准备三个账号：系统管理员 admin（密码 admin123）、物业工作人员 property01（密码 property123）、业主 owner01（密码 owner123）。然后分别在这三个账号下准备对应的演示数据，比如业主账号下有三条不同状态的报修单，物业账号下有待处理的投诉，管理员账号下有完整的房屋和账单数据。这样演示的时候不管从哪个入口进，都有东西可看。

在做这套系统的过程中，我最大的体会不是 Django 某个功能怎么用，而是“业务流程理解”比“代码技巧”重要得多。代码技巧可以搜、可以问，但如果你连物业和业主之间有哪些交互都说不清楚，那写出来的系统就是一堆 CRUD 拼凑的空壳。反过来，只要把“人和房子、房子和事务”这条主线想清楚了，Django 的 ORM 和 Admin 会帮你在很短时间内把想法变成看得见的系统。

最后分享一个我后来一直在用的小技巧：做这类管理系统，永远先写 Admin 后台再写前端页面。因为 Admin 能让你以最低成本验证数据模型设计对不对、字段缺不缺、外键关系串不串得起来，等后台里数据都维护顺了，再去做业主端页面的展示和交互就会特别顺。很多同学一上来就啃前端页面，结果页面调了半天，回头发现数据模型根本支撑不了要展示的内容，又推倒重来，那才是真的浪费时间。