企业官网建设流程全解析

做过管理系统开发的朋友应该都清楚，这类项目很多时候不是卡在功能写不出来，而是卡在“业务怎么拆、表怎么建、流程怎么走”。今天聊的这个“基于Python+Django的青岛开发区芳华美容院管理系统”，算是一个非常典型的中小型门店业务系统案例。它面向的是美容院这类服务型门店，核心围绕客户管理、项目预约、消费记录、会员卡管理、员工业绩等环节展开，技术栈是 Python 3 + Django + MySQL，前端用 Bootstrap 或 jQuery 那一套经典组合。

如果你正在准备类似的 Django 实战项目，或者你手上正好接了一个“门店管理系统”类的需求，那这篇内容值得你耐心看完。我会从业务模块设计、数据库表结构、核心功能实现、环境部署细节，再到常见坑的排查，一条线讲清楚。尤其是那些“文档里不会写、但你一定会遇到”的问题，我会重点说。

1. 内容整体设计与思路拆解

1.1 这类系统到底在解决什么问题

美容院的管理痛点，其实和理发店、健身房、宠物店很像。店里的项目多、员工多、会员多，如果靠 Excel 或者纸质记录，很容易出现几个问题：客户上次做了什么项目记不清、会员卡余额对不上、员工的业绩提成算不清楚、预约时间冲突没人管。

所以这个系统要解决的，不是“写几个页面展示数据”，而是把一条完整的业务链跑通：客户到店 -> 登记/识别会员 -> 选择服务项目 -> 消费计费 -> 会员卡扣费或现金结账 -> 记录员工业绩 -> 老板后台看报表。

这意味着，你不能一上来就写代码，得先把业务流程和数据关系理清楚。我见过很多人做管理系统，上来就建 User 表和 News 表，结果做完发现根本没法用，就是因为没站在业务角度思考。

1.2 为什么选择 Django，而不是 Flask 或 Spring Boot

这是一个很实际的问题。Flask 轻量，适合做接口或者极小的应用，但做这种多模块的管理系统，你需要自己折腾 ORM、Admin 后台、表单校验、分页、会话管理，工作量会翻倍。Spring Boot 也很强，但 Java 那套环境配置和部署成本，比 Python 高不少，对很多做毕设或中小项目的人来说不够友好。

Django 的优势在于“全家桶”式设计。自带的 ORM 能让你用 Python 类直接操作数据库表，不用写 SQL；自带的 Admin 后台能让你几分钟生成一个可用的管理界面，用来做数据维护和测试非常顺手；另外用户认证、CSRF 防护、ORM 防注入这些安全机制，Django 出厂就配好了，不需要自己造轮子。

对于美容院这类业务场景来说，Django 的模型继承、外键关联也很合适。比如客户表和会员卡表是一对一，消费记录表和员工表是多对一，这些关系用 Django ORM 表达起来非常直观。

1.3 前端方案怎么选才能省力

有人纠结要不要做前后端分离，比如 Django REST Framework + Vue。我的建议是，这种门店管理系统，完全没必要上前后端分离。你要的是快速交付、稳定运行、方便维护，不是炫技。

传统的服务端渲染模式，Django 模板系统 + Bootstrap + jQuery，已经足够覆盖这类项目的所有页面需求。模板可以继承和复用，一个 base.html 就能统一所有页面的头尾样式；jQuery 用来处理预约时间选择、会员卡余额自动计算这些交互，非常成熟，网上案例一大堆，遇到问题也好查。

如果你想在视觉上提升一点质感，可以在 Bootstrap 基础上套一个 AdminLTE 或者 SB Admin 这类免费后台模板，改一下模板继承就行，比从零手写 CSS 省太多时间。

2. 数据库设计与核心业务实现

2.1 表结构设计是第一个关键分水岭

业务系统最怕的就是表设计不合理，等代码写了一半再改表，那是灾难。基于美容院的业务场景，我建议把这些核心表建出来：用户表、员工表、客户表、会员卡类型表、会员卡表、项目表、预约表、消费记录表。

员工表建议和用户表分开，不要混在一起。Django 自带的 User 表用来处理登录账号、密码、权限，而员工表单独存员工姓名、职位、手机号、入职时间、提成比例等业务字段，这样后期就算员工离职，也只是把用户账号禁用，历史业绩数据还在。

客户表里需要存的字段包括姓名、手机号、性别、生日、来源渠道、备注。手机号建议加唯一约束，因为现实中基本上靠手机号识别客户身份。这里有个细节，很多新手会踩坑：不要用客户姓名当作唯一标识，重名的情况在美容院客户里太常见了。

会员卡表和会员卡类型表是分开的。类型表存的是“卡种”的定义，比如“银卡 2000 元 8.8 折”“金卡 5000 元 7.5 折”，而会员卡表是每个客户实际办的那张卡，存余额、开卡时间、到期时间、所属客户。如果不分开，每办一张卡都要重复录入折扣规则，数据冗余不说，后续调价也麻烦。

2.2 Django 模型代码示例与关键字段说明

直接看代码。这些模型定义基本可以覆盖美容院管理系统的核心业务。

from django.db import models from django.contrib.auth.models import User class Employee(models.Model): user = models.OneToOneField(User, on_delete=models.SET_NULL, null=True, blank=True) name = models.CharField(max_length=50, verbose_name='姓名') phone = models.CharField(max_length=11, unique=True, verbose_name='手机号') position = models.CharField(max_length=50, verbose_name='职位') commission_rate = models.DecimalField(max_digits=4, decimal_places=2, default=0.10, verbose_name='提成比例') hire_date = models.DateField(auto_now_add=True, verbose_name='入职日期') class Meta: verbose_name = '员工' verbose_name_plural = '员工' def __str__(self): return self.name class Customer(models.Model): name = models.CharField(max_length=50, verbose_name='客户姓名') phone = models.CharField(max_length=11, unique=True, verbose_name='手机号') gender = models.CharField(max_length=10, choices=(('female', '女'), ('male', '男')), verbose_name='性别') birthday = models.DateField(null=True, blank=True, verbose_name='生日') source = models.CharField(max_length=50, blank=True, verbose_name='客户来源') remark = models.TextField(blank=True, verbose_name='备注') created_at = models.DateTimeField(auto_now_add=True, verbose_name='创建时间') class Meta: verbose_name = '客户' verbose_name_plural = '客户' def __str__(self): return f'{self.name} ({self.phone})' class CardType(models.Model): name = models.CharField(max_length=50, verbose_name='卡种名称') discount = models.DecimalField(max_digits=3, decimal_places=2, default=1.00, verbose_name='折扣') min_amount = models.DecimalField(max_digits=10, decimal_places=2, verbose_name='开卡金额') duration_months = models.IntegerField(default=12, verbose_name='有效期(月)') class Meta: verbose_name = '会员卡类型' verbose_name_plural = '会员卡类型' class MemberCard(models.Model): card_no = models.CharField(max_length=20, unique=True, verbose_name='卡号') customer = models.ForeignKey(Customer, on_delete=models.CASCADE, verbose_name='所属客户') card_type = models.ForeignKey(CardType, on_delete=models.PROTECT, verbose_name='卡种') balance = models.DecimalField(max_digits=10, decimal_places=2, default=0, verbose_name='余额') created_at = models.DateField(auto_now_add=True, verbose_name='开卡日期') expire_at = models.DateField(verbose_name='到期日期') class Meta: verbose_name = '会员卡' verbose_name_plural = '会员卡' class ServiceItem(models.Model): name = models.CharField(max_length=100, verbose_name='服务项目') price = models.DecimalField(max_digits=10, decimal_places=2, verbose_name='门市价') duration = models.IntegerField(help_text='单位:分钟', verbose_name='耗时') description = models.TextField(blank=True, verbose_name='项目说明') class Meta: verbose_name = '服务项目' verbose_name_plural = '服务项目' class Appointment(models.Model): customer = models.ForeignKey(Customer, on_delete=models.CASCADE, verbose_name='客户') employee = models.ForeignKey(Employee, on_delete=models.SET_NULL, null=True, verbose_name='预约技师') service_item = models.ForeignKey(ServiceItem, on_delete=models.PROTECT, verbose_name='服务项目') appoint_time = models.DateTimeField(verbose_name='预约时间') status = models.CharField(max_length=20, choices=( ('pending', '待服务'), ('done', '已完成'), ('canceled', '已取消')), default='pending', verbose_name='状态') remark = models.TextField(blank=True, verbose_name='备注') class Meta: verbose_name = '预约' verbose_name_plural = '预约' class ConsumptionRecord(models.Model): customer = models.ForeignKey(Customer, on_delete=models.PROTECT, verbose_name='客户') employee = models.ForeignKey(Employee, on_delete=models.SET_NULL, null=True, verbose_name='服务员工') service_item = models.ForeignKey(ServiceItem, on_delete=models.PROTECT, verbose_name='服务项目') amount = models.DecimalField(max_digits=10, decimal_places=2, verbose_name='应收金额') discount = models.DecimalField(max_digits=3, decimal_places=2, default=1.00, verbose_name='折扣') paid_amount = models.DecimalField(max_digits=10, decimal_places=2, verbose_name='实收金额') pay_method = models.CharField(max_length=20, choices=( ('cash', '现金'), ('card', '会员卡'), ('wechat', '微信'), ('alipay', '支付宝')), verbose_name='支付方式') created_at = models.DateTimeField(auto_now_add=True, verbose_name='消费时间') class Meta: verbose_name = '消费记录' verbose_name_plural = '消费记录'

这里有几个设计细节，值得展开说一下。

员工表里的 commission_rate 字段，类型是 DecimalField 而不是 FloatField。金额和比例相关的字段，一定要用 Decimal，不然浮点运算会出现 0.1 + 0.2 = 0.30000000000000004 这类问题。虽然算钱的时候差一点点看不出来，但累计多了就是事故。

MemberCard 表的 card_no 字段加了 unique 约束，卡号建议手动生成，比如“HZ”开头加时间戳再加随机数。别用自增主键当卡号，太容易猜了，而且后期做活动发实体卡对应不上。

ServiceItem 里的 duration 字段，单位是分钟，数据类型用 IntegerField。这里不需要精确到秒，服务耗时是个大概时间，用来帮客户排预约。

ConsumptionRecord 表没有直接存“会员卡 ID”，而是通过 pay_method 字段区分支付方式。因为一笔消费可能有实际金额，也有卡内扣款，如果把扣款逻辑绑死在记录上，后面想统计现金流水和卡扣流水就会很麻烦。

2.3 会员卡消费的幂等性设计与业务闭环

会员卡扣款这类操作，最容易出 bug 的地方是“重复提交”。客户在页面上点了一下“确认扣款”，结果网络卡了，又点了一下，如果后端没做幂等处理，钱就扣了两次。

解决思路有两种。第一种是用 Django 的事务加 select_for_update 锁住会员卡记录，确保同一时刻只有一个请求在修改余额；第二种是在消费记录表加一个唯一订单号字段，生成订单号后先去数据库查一下，如果已存在就返回原结果。

实际项目里我建议两种配合用。订单号保证业务上不重复，行锁保证并发下数据不错乱。核心代码思路是这样的：

from django.db import transaction from django.db.models import F def card_payment(customer_id, card_id, service_item_id, order_no): with transaction.atomic(): # 先检查订单是否已经处理过 if ConsumptionRecord.objects.filter(order_no=order_no).exists(): return ConsumptionRecord.objects.get(order_no=order_no) card = MemberCard.objects.select_for_update().get(pk=card_id) service = ServiceItem.objects.get(pk=service_item_id) # 计算扣款金额 pay_amount = service.price * card.card_type.discount if card.balance < pay_amount: raise ValueError('会员卡余额不足') card.balance = F('balance') - pay_amount card.save(update_fields=['balance']) record = ConsumptionRecord.objects.create( order_no=order_no, customer_id=customer_id, service_item=service, amount=service.price, discount=card.card_type.discount, paid_amount=pay_amount, pay_method='card' ) return record

transaction.atomic() 把扣款和记录操作包在同一个事务里，任何一个步骤失败都会回滚。select_for_update() 会对这张卡对应的数据库行加锁，另一个同时提交的请求只能等在后面。这样就从根本上避免了余额被多扣的问题。

2.4 预约模块的时间冲突处理

预约模块的逻辑，其实就是先判断“这个时间段，这个技师有没有空”，再判断“这个客户有没有已经预约”。两个判断都通过，才能创建预约。

判断技师冲突的逻辑，最好用时间区间而不是精确到秒。设想一下，技师 14:30 有一个 60 分钟的预约，那 14:00 到 15:30 之间都不能再被预约。写成代码就是检查新预约的开始时间是否在已有预约的“开始时间到结束时间”区间内。

def is_employee_available(employee_id, start_time, end_time, exclude_id=None): queryset = Appointment.objects.filter( employee_id=employee_id, status='pending', appoint_time__lt=end_time, ) if exclude_id: queryset = queryset.exclude(pk=exclude_id) for appt in queryset: appt_end = appt.appoint_time + timedelta(minutes=appt.service_item.duration) if appt_end > start_time: return False return True

我第一次做这类判断的时候，想得很简单，以为只要查“预约时间等于新预约时间”就行，结果漏掉了“预约时间在中间重叠”的情况。后来把所有已约项目拉出来，逐个判断结束时间是否晚于新开始时间，才真正把逻辑补全。

3. 环境搭建与部署实操

3.1 本地开发环境的配置思路

Django 项目的本地环境配置，核心就三样：Python 解释器、虚拟环境、数据库。很多新手栽在第一步，直接在系统全局环境里装了一堆包，后面项目多了，依赖互相冲突，搞得一团糟。

建议每一步都用虚拟环境。创建项目文件夹后，先执行python -m venv venv，Windows 下激活用venv\Scripts\activate，macOS 或 Linux 用source venv/bin/activate。之后所有 pip 安装都装在这个虚拟环境里，跟系统 Python 完全隔离。

装依赖的时候，建议先用pip install django装上 Django 框架，再根据需要装 mysqlclient 或 PyMySQL。Django 版本建议选 3.2 或 4.x，不建议一上来就追最新版，有些第三方库还没跟上，反而麻烦。

数据库这里需要多说一句。开发环境用 MySQL 和 SQLite 都行，但生产环境建议上 MySQL。为了统一，我通常开发就直接连 MySQL，避免后期因为数据库差异出现 SQL 兼容问题。比如字段大小写敏感、日期处理方式，MySQL 和 SQLite 是有区别的。

3.2 项目创建与基本配置

创建项目并配置 settings.py，这些操作比较模板化，但有几个点很容易出问题，单独提一下。

django-admin startproject beauty_system cd beauty_system python manage.py startapp management

settings.py 里需要注册新增的 app，在 INSTALLED_APPS 列表里加上management，然后配置数据库连接：

DATABASES = { 'default': { 'ENGINE': 'django.db.backends.mysql', 'NAME': 'beauty_system', 'USER': 'root', 'PASSWORD': 'your_password', 'HOST': '127.0.0.1', 'PORT': '3306', } }

还有一个很多人忽略的地方：语言和时区。默认配置是英文和 UTC 时间，如果忘记改，你会发现自己明明存的是北京时间，显示出来却慢了 8 个小时，admin 后台也是英文界面。

LANGUAGE_CODE = 'zh-hans' TIME_ZONE = 'Asia/Shanghai' USE_TZ = True

USE_TZ 这个选项，建议保持 True。这样 Django 在数据库里存的是带时区的时间，展示给用户时再按当前时区格式化，逻辑更规范。如果业务不涉及多时区，也可以改为 False，但改动 date/datetime 字段的存储方式，旧数据可能会有差异，要谨慎。

3.3 数据迁移与超级用户创建

模型写完之后，执行迁移命令生成数据表：

python manage.py makemigrations python manage.py migrate

makemigrations 是根据你写的 models.py 生成迁移文件，migrate 才是真正把迁移文件应用到数据库。很多新手只跑 migrate，忘了 makemigrations，结果发现数据库里没有表，就是这个原因。

创建后台管理员账号：

python manage.py createsuperuser

按提示输入用户名、邮箱、密码。之后运行python manage.py runserver，浏览器打开http://127.0.0.1:8000/admin/就能看到 Django 自带的登录页面了。

登录之后你会发现 Admin 后台默认只有用户和组的管理，你自己写的模型还没显示出来。需要到对应 app 的 admin.py 文件里注册一下：

from django.contrib import admin from .models import Customer, Employee, ServiceItem, MemberCard, Appointment, ConsumptionRecord @admin.register(Customer) class CustomerAdmin(admin.ModelAdmin): list_display = ('name', 'phone', 'gender', 'created_at') search_fields = ('name', 'phone') @admin.register(ConsumptionRecord) class ConsumptionRecordAdmin(admin.ModelAdmin): list_display = ('customer', 'service_item', 'paid_amount', 'pay_method', 'created_at') list_filter = ('pay_method',)

注册之后，原本只有 User 模型的管理后台，就多了客户、员工、项目等菜单，可以直接录入和查询数据。

3.4 静态文件和媒体文件部署配置

Django 开发时能正常显示图片和 CSS，但部署到服务器上经常整个页面裸奔，多半是静态文件配置问题。

开发时，Django 会自动帮我们找每个 app 下的 static 目录，只要你在模板里正确使用{% load static %}就能引用。但生产环境跑python manage.py collectstatic时，它会把所有 app 的静态文件收集到 STATIC_ROOT 指定的目录里，然后由 Nginx 来提供访问。

图片上传这块，要在 settings.py 里配置 MEDIA_URL 和 MEDIA_ROOT：

MEDIA_URL = '/media/' MEDIA_ROOT = os.path.join(BASE_DIR, 'media')

然后把需要上传图片的模型字段写成models.ImageField(upload_to='customer/')这样，上传的图片会自动存到 media/customer/ 目录下。

如果部署后图片无法显示，先确认 Nginx 是否把 /media/ 路径指向了正确目录。这是一个频率很高的部署问题，大概率是路径写错了。

4. 常见问题与排查技巧实录

4.1 mysqlclient 安装失败

这个几乎是 Windows 环境下的必考题。直接在 Windows 上用pip install mysqlclient，大概率会报错，提示缺少 Microsoft Visual C++ 14.0 或 MySQL Connector/C 相关依赖。

解决方案通常有三种。第一种是安装微软的 Visual C++ 构建工具，然后重新 pip install，成功率最高但下载东西多；第二种是用 PyMySQL 替代，在项目的init.py 里加上一句：

import pymysql pymysql.install_as_MySQLdb()

然后把 settings.py 里的 ENGINE 保持django.db.backends.mysql不变，Django 会通过 PyMySQL 的适配层连 MySQL。这个方法最简单，兼容性也好，适合绝大多数场景。

第三种是直接下载别人编译好的 .whl 文件安装，但要注意 Python 版本和系统位数必须匹配，否则还是装不上。

4.2 时间字段的 8 小时之谜

系统中所有记录创建时间都是 auto_now_add，但页面上显示的时间总比当前时间少 8 小时。这个问题的根源不是代码，而是时区配置。

如果你设置TIME_ZONE = 'Asia/Shanghai'且USE_TZ = True，Django 在模板渲染时会自动把 UTC 时间转换成上海时间，显示是正常的。问题通常出在直接操作数据库或者用 Python 脚本输出时间时，查出来的是 UTC 时间，看起来就少了 8 小时。

解决办法是：在查看数据库里的 datetime 字段时，意识到 Django 存的是 UTC；在代码中需要输出本地时间时，用timezone.localtime()包裹一下；如果项目只在国内使用，干脆把 USE_TZ 设为 False，所有时间都以本地时间存储和读取，反而直观。

这里我要强调一点，不管你选哪种方案，不要在模型里用default=datetime.now()这类写法，应该用default=timezone.now，否则时区处理会出现双重偏移。

4.3 Admin 后台美化与扩展

自带的 Admin 后台功能是够用，但样式比较朴素，排版也不灵活。如果项目要求后台界面美观一点，有几种轻量方案。

最简单的方式是给 admin 集成第三方主题。比较常见的选择是 django-simpleui，它直接把界面替换成一个更现代的侧边栏布局，还自带一些统计图表组件，安装后只需要在 INSTALLED_APPS 里把simpleui放在django.contrib.admin之前，然后重启服务就能看到效果。

如果你不想依赖第三方库，也可以自定义 admin 的 base_site.html 模板，覆盖掉原有的标题和样式引用。这个方案的好处是零依赖，坏处是要手动处理的样式细节比较多。对于管理系统来说，我建议优先用 django-simpleui，省心很多，而且中文化做得好。

4.4 外键删除保护与数据完整性

删除客户、员工、服务项目这些基础数据时，如果被消费记录等业务数据引用，直接删除会导致数据关联断裂，甚至报错。

在模型定义中，我对外键字段的 on_delete 参数做了区分：

• Customer、ServiceItem 被消费记录和预约引用，用 CASCADE 删除客户时，其关联预约和消费记录也会删除，适合客户主动销户的场景。
• Employee 被预约和消费记录引用，用 SET_NULL，这样就算员工离职，历史订单还能保留员工信息。
• CardType 被 MemberCard 引用，用 PROTECT，有会员卡正在使用该卡种时禁止删除，避免出现“卡种没了但卡还在”的数据不一致情况。

有一回我测试时直接删了一个客户，结果发现消费记录也跟着没了。当时吓出一身冷汗，后来才意识到这是 CASCADE 的效果。做这类系统时，删除前最好用软删除，也就是给模型加一个 is_active 字段，删除时只把状态改成禁用，这样数据随时能恢复。

4.5 分页、搜索与列表页的性能细节

当消费记录、预约记录积累到几千条之后，列表页如果不做分页，加载会明显变慢。Django 自带的 Paginator 能解决分页，但分页只是手段，真正影响性能的是查询次数。

QuerySet 是惰性的，循环模板中访问外键关联对象时，会产生 N+1 查询。比如消费记录列表里要显示“客户姓名”“项目名称”“员工姓名”，每一次访问都是一个数据库查询。解决方法是使用 select_related：

records = ConsumptionRecord.objects.select_related('customer', 'service_item', 'employee').all()

select_related 适合外键这种一对一关系，会把关联表通过 JOIN 查询一次取回来；多对多关系要用 prefetch_related。别小看这个细节，数据量上来以后，查询时间能差几十倍。

搜索功能，建议使用 Django 的 Q 对象做联合查询。比如客户姓名和手机号两个条件同时搜索：

from django.db.models import Q keyword = request.GET.get('keyword', '') customers = Customer.objects.filter( Q(name__icontains=keyword) | Q(phone__icontains=keyword) )

Q 对象用|表示或逻辑，比写两个 filter 再合并查询集更直观，性能也好很多。

4.6 图片体积控制

客户头像、项目展示图，如果直接存储原始图片，过一段时间数据库和服务器硬盘都会被撑爆。我遇到过合作伙伴上传一张 20MB 的手机照片，直接把页面卡死的情况。

控制图片体积，可以在表单上传时用 Pillow 库做压缩，核心思路是在 save 之前将图片 open 后重新 resize。Django 的 ImageField 依靠 Pillow 读取图片，你可以在模型的 save 方法里重写图片处理逻辑：

from PIL import Image from io import BytesIO from django.core.files.base import ContentFile def save(self, *args, **kwargs): if self.image: img = Image.open(self.image) img.thumbnail((800, 800), Image.LANCZOS) buffer = BytesIO() img.save(buffer, format='JPEG', quality=85) self.image.save(self.image.name, ContentFile(buffer.getvalue()), save=False) super().save(*args, **kwargs)

这个逻辑不复杂，但实际省下的存储空间非常可观。对管理系统来说，图片不是越清晰越好，能看清就行。

4.7 重复数据处理

美容院系统的客户数据，非常容易出现重复录入，比如同一个客户，前台录入了一次，店长又录入了一次，导致两个 Customer 记录对应同一个人。

从技术上防重复，最有效的是给手机号加 unique 约束，录入时前端先查重。但老系统历史数据经常已经重复了，这时候需要写一个去重的脚本，找到相同手机号的记录，合并到最早那一条，其他记录引用外键的地方全部重新指过来。这个操作要非常谨慎，执行前一定要备份数据库。

我的习惯是写一个临时管理命令放在 management/commands 目录下，这样可以用python manage.py merge_customers来执行，而不是临时在一个视图里写逻辑。管理命令的好处是可重复执行、可调试、不会污染正常业务。

5. 部署上线要注意的细节

5.1 服务器环境准备

部署 Django 项目，我比较推荐的方式是 Gunicorn + Nginx 的组合。Gunicorn 负责运行 Python 应用，Nginx 负责接收外部请求、转发给 Gunicorn、处理静态文件。

服务器上需要用宝塔面板或者手动编译安装 Python 3 和 MySQL。这里建议直接用宝塔，因为 MySQL、PHP、Nginx 这些都能一键安装，省去很多编译的痛苦。安装完以后在命令行里确认 Python 版本，因为宝塔面板自带的 Python 版本可能不是你需要的版本。

python3 --version

如果版本不对，就不要在系统全局装包，依然用虚拟环境，装好项目依赖后，始终用虚拟环境里的 python 和 gunicorn 执行命令，这样跟面板自带环境互不影响。

5.2 Gunicorn 启动参数怎么调

Gunicorn 的进程数和线程数，直接决定并发能力。对美容院这种内部管理系统，几十个人同时在线已经是极限了，所以不用调得太夸张。

一个常见的启动命令：

gunicorn beauty_system.wsgi:application -w 3 -b 127.0.0.1:8000

-w 是 worker 进程数，一般经验值是 CPU 核心数的 2 倍再加 1。如果服务器的 CPU 是 2 核，那 5 个 worker 就够用了。不要盲目调大 worker 数，因为每个 worker 都会占用内存，服务器内存不够反而会频繁 swap，性能更差。

部署的时候还有一个很隐蔽的问题，就是代码修改后 worker 没重启。我用 supervisor 管理 Gunicorn 后，每次更新代码执行supervisorctl reload才能让新代码生效，如果忘了，上线时改了半天页面没变化，排查半天才发现。

5.3 Nginx 反向代理配置

Nginx 配置不复杂，但容易漏掉几个关键点。核心请求配置：

server { listen 80; server_name your_domain.com; client_max_body_size 20m; location /static/ { alias /home/your_project/static/; } location /media/ { alias /home/your_project/media/; } location / { proxy_pass http://127.0.0.1:8000; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; } }

client_max_body_size 20m 是很多人会漏掉的配置。默认 Nginx 只允许上传 1MB 的请求体，如果你在系统里上传项目图片，超过 1MB 就会报 413 Request Entity Too Large，而这个错误前端完全看不到原因，非常隐蔽。

location /static/ 和 /media/ 这两块，是为了让 Nginx 直接处理静态资源，不经过 Django，减轻应用压力。如果你没有配置，页面 CSS 和图片全部加载失败，但接口请求是正常的，这个现象很容易误导人往代码方向排查。

5.4 数据库备份策略

管理系统上线后，最值钱的东西就是数据。美容院的客户资料、会员余额、消费记录，一旦丢失，客户信任就没了。

备份我推荐用系统 crontab 定时执行 mysqldump，保留每天凌晨的备份文件。命令大致是：

mysqldump -u root -p your_password beauty_system > /backup/beauty_$(date +%Y%m%d%H%M).sql

注意备份文件要按日期留存，至少保留 7 天。我见过有人定时备份是做了，但备份文件一直在同一个路径，被第二天覆盖了，结果出问题时发现备份还是几天前的，等于没备份。

另外，mysqldump 备份在数据库有 MyISAM 表时可能锁表，而 InnoDB 表需要加上--single-transaction参数来保证一致性备份：

mysqldump -u root -p your_password --single-transaction --default-character-set=utf8mb4 beauty_system > /backup/beauty_$(date +%Y%m%d%H%M).sql

一句话，数据库编码用 utf8mb4，备份加 single-transaction，这两个习惯养成了，能省很多后续麻烦。

6. 项目管理与交付复盘

6.1 从零到交付的时间线与任务拆解

有人看到“源码+论文+部署文档+讲解”这几个词，就觉得这是个上千行的项目。实际上，一个合格的美容院管理系统，核心功能就那几个模块，按照合理的节奏，完整做下来大概在两周到三周之间。

大概拆解是这样的：业务调研和表结构设计 1-2 天，环境搭建和项目骨架 1 天，客户、员工、项目管理模块 2-3 天，会员卡和消费模块 3 天，预约模块 2 天，统计报表和仪表盘 2 天，Admin 后台优化 1 天，前后端联调和 bug 修复 2 天，写部署文档和论文 3-4 天。

这个节奏里最难的是第一周的表结构设计，因为表结构一旦定了，后面改起来是一个牵一发动全身的事情。我做这个项目时，光客户表、会员卡表、消费记录表之间的关系，就反复调整了三次，后面写功能的时候就顺利多了。

所以我的建议是，不要急着写代码，花足够的时间设计表和明确业务规则，比如：会员卡能不能退款？退款的金额返到哪里？预约爽约多少次要限制？这些问题提前想清楚，系统做出来才真正可用，而不是“能跑”而已。

6.2 部署文档怎么写才能不背锅

部署文档是这类项目交付物里非常关键的“隐形环节”。写得好的文档，照着一步步操作就能把项目跑起来；写得不好的文档，看的人每一步都在猜，遇到问题还会反过来问你。

我的经验是，部署文档里一定包含这几部分内容：环境要求（版本号写死）、安装步骤（每步附命令和预期输出）、数据库初始化（如何建库、导入数据）、配置文件修改（哪些配置项需要按实际环境改）、常见错误处理（至少列出三四个高频问题）。尤其是预期输出，很多人写文档会漏掉。写清预期输出，能让人在中间任何一步出错时快速定位问题在哪儿。

注意：部署文档不是写给“能看懂的人”看的，而是写给“完全不知道你在干什么的人”看的。降低阅读门槛，才能减少不必要的沟通成本。

6.3 功能测试清单

系统开发完上线前，我会过一遍核心功能测试清单，这个习惯帮我在项目上线阶段避免了很多临阵修 bug 的尴尬情况。

• 新客户注册/新增后能否立即办理会员卡
• 会员卡首次充值和二次充值的余额计算是否准确
• 预约时间冲突时系统是否拦截
• 消费记录里会员卡支付后，余额是否实时减少
• 员工提成计算的基数是否正确（有些店按实收金额算，有些按项目原价算，业务规则要确认清楚）
• 删除有消费记录的客户，系统是否给了明确提示
• 不同权限账号能否正确看到对应菜单和数据

测试清单的核心目的，是让你在交付之前，以用户视角走一遍所有业务场景，而不是只盯着代码逻辑做单元测试。某些逻辑正确但体验不合理的地方，只有走完整流程才能发现。

7. 写在最后的一点个人体会

做管理系统这类项目，说实话，技术难度并不高，Django 的 ORM 和 Admin 把很多底层事情都帮你处理了。真正的难点其实在于业务理解，你得把自己当成美容院的店长、前台、老板，去感受他们每天会遇到什么麻烦，然后让系统去解决这些麻烦。

我做完这个项目后最大的收获，不是学会了 Django 的某个高级特性，而是建立了一套“从业务到代码再回到业务”的思考方式。拿到一个需求，第一反应不再是“这个功能用什么技术实现”，而是“这个功能在业务流程里处于什么位置、牵扯到哪些数据、边界条件是什么”。有了这个思维方式，写起代码来自然顺畅很多。

最后再分享一个小技巧。整个系统里，我觉得性价比最高的功能其实是那几张统计报表。客户消费排行、项目受欢迎程度、员工业绩对比，这些报表就是老板最想看的“价值呈现”。用 Django ORM 的 annotate 加聚合查询，几十行代码就能搞定，但它是整个系统中最有说服力的部分，千万别只盯着增删改查，把统计报表做出来，整个项目的完整度立刻上一个台阶。

如果你正在做这个系统，或者打算开发类似的管理系统，建议先把本文提到的表结构、事务处理、时间冲突判断这几个核心点吃透，其他的页面装饰、交互特效，都是锦上添花的事。