基于Django的电商数据分析系统设计与实现全解析

1. 为什么选这个题目：说说我的真实想法

又到了毕业设计的季节，后台收到不少同学私信，问得最多的就是“数据分析类毕设到底怎么做才能拿高分”。我看了下大家普遍纠结的点：一是怕题目太大做不完，二是担心答辩时被老师问到技术细节答不上来。

这个“基于Django的电商数据分析系统的设计与实现”，是我去年带过的模拟项目X的真实选题，也是我认为性价比非常高的一个方向。先说结论：它踩中了三个关键点——有明确业务场景（电商）、有一眼可见的产出物（可视化大屏）、技术栈主流且好解释（Python + Django + ECharts）。这三点在答辩现场就是加分项，老师能直观看到你的系统在“干活”，而不是纯粹堆CRUD。

这套系统的定位很清晰：从电商平台的订单、用户、商品数据里抽取关键指标，通过图表把“卖了多少、谁在买、什么好卖、库存压力在哪”这些问题可视化出来。适合对Python有一定基础、想快速完成一个完整项目、同时还希望论文有东西可写的计算机专业同学。

我写这篇文章的目的，就是把整个系统的设计思路、核心模块、数据库表结构、关键代码、答辩常被问的问题，一条龙串起来讲清楚。里面有完整的实现步骤，也有我实战中踩过的坑。你不需要照抄，但照着这个思路走，自己完全能搭一套出来。

2. 系统整体设计与技术选型思路

2.1 为什么选Django而不是其他框架

很多同学纠结Flask和Django哪个更适合毕设。我的建议是：如果做数据分析类系统，直接用Django，别犹豫。原因有三点。

第一，Django自带Admin后台。这绝对是个大杀器。你和导师演示时，Admin可以现场展示数据录入、权限管理，这种“看得见”的功能会让系统显得完整。而Flask的Admin需要自己集成，增加了无谓的工作量。

第二，Django的ORM对嵌套查询、聚合计算支持非常友好。电商数据分析最核心的操作就是按时间、按分类分组聚合统计，用ORM的annotate()、values()配合Count、Sum、Avg这些聚合函数，三四行代码就能完成一条SQL要写半天的统计逻辑。

第三，Django的模板系统能直接渲染HTML页面，配合ECharts做可视化时，只需要在模板里通过JsonResponse把JSON数据传给前端，不需要额外搭建前端工程，单机演示完全够用。

2.2 为什么不做前后端分离

答辩项目中，前后端分离是“看上去很美”的选择——Vue + DRF（Django REST Framework）的组合确实很主流。但我不推荐在毕设阶段这么做，核心原因是一条“时间成本不等式”：前后端分离至少要多花一倍时间处理跨域、接口文档、联调、部署，而这些投入在答辩打分中的回报率很低。

导师评审系统时，关注的核心是“业务逻辑是否正确、数据处理是否合理、交互是否流畅”，而不是“是否用了微服务架构”。Django模板 + ECharts的方案，页面全部由后端渲染，逻辑集中、调试简单，我一个人两周就能完成核心功能。

如果后续想往简历上添加亮点，再花几天把数据接口用DRF重写一层即可，前面的数据统计逻辑完全不用动——这也是Django设计上比较舒服的地方。

2.3 四层结构设计：让答辩时讲得清

整个系统我采用了标准的四层划分：

• 数据采集层：通过脚本读取CSV数据文件或爬虫抓取数据，清洗后存入MySQL数据库。毕设阶段建议用CSV或公开数据集，不推荐做爬虫，一是耗时，二是稳定性不可控。
• 业务逻辑层：核心统计模块，负责处理用户管理、订单统计、销售趋势、商品分类聚合、用户活跃度分析等需求。
• 表现层：Django模板引擎渲染网页，通过ECharts绘制统计图表，包含大屏展示页、用户管理页、登录注册页。
• 数据存储层：MySQL数据库，通过Django ORM操作数据表。

这个层面最忌讳“想到哪写到哪”，答辩被问“你这个系统架构是什么”时，你直接抛这张分层图，老师第一印象就不会差。

3. 核心功能模块解析：每个模块要解决什么问题

3.1 模块清单与功能映射

系统拆成六个功能模块，每个模块必须回答“它到底解决了什么业务问题”，这部分是论文和答辩的灵魂。

电商数据分析系统的核心问题有四个：整体卖得怎么样、谁在买、什么东西好卖、库存压力在哪。所有模块都围绕这四个问题展开，不能有游离在主线外的功能。

3.2 用户登录注册模块：别小看它的作用

绝大多数同学以为登录注册只是个“凑功能”的模块，其实它承担着系统安全性的证明责任。答辩老师经常会问“系统权限是怎么设计的”“密码怎么存储的”“会话怎么维持的”。

我的做法是：使用Django内置的User模型，密码通过make_password进行哈希存储。登录成功后，将用户ID写入session，每个需要权限的视图函数都加上@login_required装饰器。这部分代码十分简单，却能在答辩时说清楚三种安全机制：密码加密、会话管理、访问控制。

3.3 销售趋势分析模块：最核心的功能

这个模块直接回答“整体卖得怎么样”的问题。它需要统计出三个时间维度的数据：

• 按日：统计最近30天每天的订单数和销售额，用于观察短期波动。
• 按月：统计近12个月的销售额趋势，用于识别季节性规律。
• 按小时：统计一天24小时内的订单分布，用于指导运营活动时段安排。

技术上要注意的是，电商平台的订单时间字段不能直接用DateTimeField做group by date，因为数据库存储的是完整时间戳。要先通过ORM的TruncDate转换成日期再分组。这是答辩的高频考点，我会在下一章节给出详细代码。

3.4 商品分析模块：找出“爆款”和“滞销品”

商品分析的维度是“什么东西好卖”。我用两个指标来完成：销售额TOP10商品排名、分类销售额占比。

这里有个容易踩坑的地方：分类层级问题。如果只用一级分类做统计，结果大而全，没有说服力。我建议至少拆到二级分类。订单表关联商品表，商品表关联二级分类表，用values('product__category__name')做嵌套关联聚合——这块也是体现“系统复杂度和深度”的关键点。

3.5 用户分析模块：回答“谁在买”

用户分析我拆成了两块：

• 新老用户占比：通过用户首次下单时间与当前时间对比，区分新老客群。这个逻辑实现时比较绕，需要先查出每个用户的最小下单时间，再回表计算占比。
• 复购率分析：统计“下单次数超过1次”的用户占全部用户的比例。这直接关系平台用户粘性，是电商业务中非常看重的指标。

复购率计算有标准口径：指某段时间内下单两次及以上或有两次及以上购买记录的用户占总购买用户的比例（统计周期内）。答辩时最好能清晰说出这个公式，专业感一下就出来了。

3.6 数据大屏模块：整套系统的“门面”

数据大屏是拿高分的利器。我个人体会是，答辩现场PPT翻得再花哨，不如一打开浏览器就跳转到一个自动刷新、图表丰富的数据大屏。视觉冲击力直接拉满。

大屏我用了四个核心图表：

大屏的配色我强烈建议用深色底+亮色图表（深蓝+青绿+亮黄），比浅色底更显质感，也更能掩盖ECharts默认样式“土味”的问题。每30秒通过AJAX请求接口刷新一次，模拟实时数据流。

4. 数据库表设计：扎实的数据基座

4.1 建表方案与字段说明

数据表设计是毕设论文的重点章节，字段名、类型、约束必须合理解释清楚。我总共设计了三张核心表：商品表（Product）、订单表（Order）、用户表（UserProfile），外加Django内置的用户表用于登录。表关系是典型的星型模型：订单表通过外键连接商品表和用户表。

订单表是事实表，字段尽量冗余设计，比如直接存储product_name快照。这里有个设计原则：如果商品改名，订单数据不能跟着变，所以订单中必须冗余商品名称和价格快照。我见过不少同学忽略这个细节，答辩被老师问住。

关键表结构如下：

商品表（Product）

订单表（Order）

4.2 冗余字段是“故意的”

不少同学会照搬范式设计的教条，认为冗余不可接受。但在电商分析场景，订单表冗余商品信息、用户昵称是刻意为之。核心原因在于，统计分析需要频繁关联表，每一次关联都是性能损耗。冗余字段可以让聚合查询直接命中事实表，不需要JOIN商品表，速度提升明显。

答辩时主动向老师解释这个设计，老师基本都会认可，因为这展示了你对“分析型系统”和“事务型系统”差异的理解。

4.3 造数脚本：没有数据怎么演示

系统做完了，数据库里没数据，答辩现场就是巨型翻车现场。我写了两个造数脚本：

• generate_goods.py：生成200条商品记录，涵盖日用百货、数码产品、女装、男装、食品等类目。
• generate_orders.py：循环生成过去一年约数万条订单记录，日期按正态分布往“双11”“618”附近集中，用户ID随机抽取。

造数时有个小窍门：模拟真实的购买频次分布。少数用户购买频率高，多数用户只买一两次，这样复购率才在20%~30%的真实区间。如果所有用户下单次数都一样，复购率计算出来会非常假，答辩时经不住细问。

5. 核心代码实现：这些坑我都帮你踩过了

5.1 Django项目初始化与依赖清单

我建议先建虚拟环境再装依赖，避免系统Python环境被污染。

# 创建虚拟环境 python -m venv env # 激活（Windows） env\Scripts\activate # 激活（Linux/Mac） source env/bin/activate # 安装依赖 pip install django==4.2 pip install mysqlclient pip install pymysql pip install pandas pip install matplotlib

再明确一下版本：Django 4.2是当前比较稳的版本，支持Python 3.10以上。mysqlclient在Windows上安装偶尔会报错，如果遇到问题，用pymysql，并在项目__init__.py中加入两行兼容代码：

import pymysql pymysql.install_as_MySQLdb()

5.2 我的项目目录结构参考

这里展示最终的项目目录，方便你对照组织自己的文件：

django_ecommerce_analysis/ ├── manage.py ├── requirements.txt ├── db.sqlite3 ├── ecommerce/ # 主业务应用 │ ├── __init__.py │ ├── models.py │ ├── views.py │ ├── urls.py │ ├── admin.py │ ├── apps.py │ ├── tests.py │ └── migrations/ ├── scripts/ │ ├── generate_goods.py │ ├── generate_orders.py │ └── clean_data.py ├── templates/ │ ├── base.html │ ├── login.html │ ├── register.html │ ├── dashboard.html │ ├── product_analysis.html │ └── user_analysis.html ├── static/ │ ├── css/ │ ├── js/ │ └── echarts.min.js ├── data_analysis/ │ ├── __init__.py │ ├── settings.py │ ├── urls.py │ └── wsgi.py └── README.md

5.3 模型定义：ORM映射核心代码

在models.py中定义三张核心表。这里我用自己的真实代码为例：

from django.db import models from django.contrib.auth.models import User class Product(models.Model): name = models.CharField(max_length=128, verbose_name='商品名称') category = models.CharField(max_length=64, verbose_name='商品分类') price = models.DecimalField(max_digits=10, decimal_places=2, verbose_name='单价') stock = models.IntegerField(default=0, verbose_name='库存') sales_count = models.IntegerField(default=0, verbose_name='销量') class Meta: db_table = 'product' verbose_name = '商品信息' def __str__(self): return self.name class Order(models.Model): order_no = models.CharField(max_length=64, unique=True, verbose_name='订单号') user = models.ForeignKey(User, on_delete=models.CASCADE, verbose_name='用户') product = models.ForeignKey(Product, on_delete=models.CASCADE, verbose_name='商品') product_name = models.CharField(max_length=128, verbose_name='商品名称快照') product_price = models.DecimalField(max_digits=10, decimal_places=2, verbose_name='商品单价快照') quantity = models.IntegerField(default=1, verbose_name='购买数量') total_amount = models.DecimalField(max_digits=12, decimal_places=2, verbose_name='订单金额') status = models.IntegerField(choices=((1, '已完成'), (2, '待付款'), (3, '已取消')), default=1) create_time = models.DateTimeField(auto_now_add=True, verbose_name='下单时间') class Meta: db_table = 'order' verbose_name = '订单信息' def __str__(self): return self.order_no

使用Meta的db_table显式指定表名，避免Django默认生成的应用名前缀，后面手写SQL或阅读日志都更方便，这也是答辩中容易获得印象分的细节。

5.4 数据导入脚本：用pandas快速完成清洗

造数脚本的核心逻辑，是利用pandas生成DataFrame，然后批量插入数据库。直接循环单条插入，数据量大时速度惨不忍睹。正确做法是bulk_create批量插入：

import pandas as pd import random from datetime import datetime, timedelta from ecommerce.models import Product, Order from django.contrib.auth.models import User def generate_orders(days=365): users = list(User.objects.all()) products = list(Product.objects.all()) order_list = [] for day_offset in range(days): date = datetime.now() - timedelta(days=day_offset) # 模拟周末和促销日单量波动 if date.weekday() >= 5: orders_per_day = random.randint(80, 120) elif date.day in [1, 11, 18]: orders_per_day = random.randint(300, 500) else: orders_per_day = random.randint(40, 90) for _ in range(orders_per_day): user = random.choice(users) product = random.choice(products) qty = random.randint(1, 3) order_list.append(Order( order_no=f'{date.strftime("%Y%m%d%H%M%S")}{random.randint(1000,9999)}', user=user, product=product, product_name=product.name, product_price=product.price, quantity=qty, total_amount=product.price * qty, status=1, create_time=date.replace(hour=random.randint(8, 23)) )) Order.objects.bulk_create(order_list, batch_size=1000)

这里在某天日期的判断里我特意把1号、11号、18号设为促销高峰，这样后面折线图会出现有规律的波浪形尖峰，视觉上比一条直线有说服力得多。

5.5 销售趋势统计：ORM聚合时注意TruncDate

这个模块是整个系统的数据核心。实现时使用Django的TruncDate函数，把create_time截断成日期进行分组统计：

from django.db.models.functions import TruncDate from django.db.models import Sum, Count from django.db.models import Q def get_sales_trend(request): # 最近30天按日统计销售额和订单量 last_30_days = datetime.now() - timedelta(days=30) trend_data = ( Order.objects .filter(create_time__gte=last_30_days, status=1) .annotate(day=TruncDate('create_time')) .values('day') .annotate( total_sales=Sum('total_amount'), order_count=Count('id') ) .order_by('day') ) dates = [item['day'].strftime('%Y-%m-%d') for item in trend_data] sales = [float(item['total_sales']) for item in trend_data] counts = [item['order_count'] for item in trend_data] return JsonResponse({'dates': dates, 'sales': sales, 'counts': counts})

这里有两个最常见的坑：

1. 必须显式指定status=1，只统计已完成订单，否则退款和取消的订单会把数据拉偏。答辩现场很可能被问“你这个统计口径是什么，包含哪些状态”，答不上来就尴尬了。
2. TruncDate后的字段名是day，后续values要用这个别名而不是create_time。很多同学在这里报错或者统计结果对不上日期，就是因为忘了这一步。

5.6 分类占比统计与嵌套关联

实现分类占比时，要跨越订单表、商品表、分类三个层级。我在表设计时没有独立分类表，直接用商品表里的category字段，因此逻辑简单许多：

def get_category_distribution(request): category_data = ( Order.objects .filter(status=1) .values('product__category') .annotate(total_sales=Sum('total_amount')) .order_by('-total_sales')[:10] ) categories = [item['product__category'] for item in category_data] sales = [float(item['total_sales']) for item in category_data] return JsonResponse({'categories': categories, 'sales': sales})

如果你用的是一级分类，直接这样做即可。如果有二级分类表，就需要product__sub_category__category这样的双外键关联。答辩时如果导师问“你这个分类统计支持多级吗”，你可以这样回答：当前以一级分类为主，设计上保留扩展——这就是“有边界意识”。

5.7 新老用户与复购率计算：口径要说清楚

新老用户统计的逻辑，需要先按用户聚合出首次下单时间，再按时间窗判断。实现如下：

from django.db.models import Min def get_user_analysis(request): # 每个用户的首次下单时间 first_order_time = ( Order.objects .filter(status=1) .values('user_id') .annotate(first_time=Min('create_time')) ) # 判断这个用户是否属于新用户（首单在30天内） new_user_count = 0 old_user_count = 0 for record in first_order_time: if record['first_time'] >= datetime.now() - timedelta(days=30): new_user_count += 1 else: old_user_count += 1 # 复购率：所有购买用户中，下单次数大于1的比例 user_order_counts = ( Order.objects .filter(status=1) .values('user_id') .annotate(order_num=Count('id')) ) total_buyers = user_order_counts.count() return_buyers = user_order_counts.filter(order_num__gt=1).count() return_rate = round(return_buyers / total_buyers * 100, 1) if total_buyers else 0 return JsonResponse({ 'new_user_count': new_user_count, 'old_user_count': old_user_count, 'return_rate': return_rate, 'total_buyers': total_buyers, 'return_buyers': return_buyers })

循环逐条处理在数据量大时性能一般，但毕设规模完全没问题。答辩时如果被问到性能优化，你可以说后续可以改为纯SQL或窗口函数实现——这就是“知道下一步怎么走”的加分回答。

5.8 登录注册，以及session控制代码

核心视图如下，代码其实非常简洁：

from django.contrib.auth import authenticate, login, logout from django.contrib.auth.decorators import login_required from django.shortcuts import render, redirect from django.contrib.auth.models import User from django.contrib.auth.hashers import make_password def register_view(request): if request.method == 'POST': username = request.POST.get('username') password = request.POST.get('password') if User.objects.filter(username=username).exists(): return render(request, 'register.html', {'error': '用户名已存在'}) User.objects.create( username=username, password=make_password(password) ) return redirect('login') return render(request, 'register.html') def login_view(request): if request.method == 'POST': username = request.POST.get('username') password = request.POST.get('password') user = authenticate(request, username=username, password=password) if user is not None: login(request, user) return redirect('dashboard') return render(request, 'login.html', {'error': '用户名或密码错误'}) return render(request, 'login.html') @login_required def dashboard(request): return render(request, 'dashboard.html')

5.9 数据大屏与ECharts绘图

大屏页面在dashboard.html中，嵌入ECharts的方式很简单。这里我提供核心模板片段思路：

<!-- dashboard.html 核心结构 --> <style> body { background: #0f1c2e; color: #fff; font-family: 'Microsoft YaHei', sans-serif; } .chart-container { display: flex; flex-wrap: wrap; gap: 20px; padding: 20px; } .chart-box { background: rgba(255,255,255,.08); border-radius: 8px; padding: 16px; } </style> <div class="chart-container"> <div id="trendChart" style="width: 55%; height: 360px;"></div> <div id="categoryChart" style="width: 40%; height: 360px;"></div> <div id="userChart" style="width: 48%; height: 300px;"></div> </div> <script src="/static/js/echarts.min.js"></script> <script> function loadTrend() { fetch('/api/sales-trend/') .then(response => response.json()) .then(data => { let chart = echarts.init(document.getElementById('trendChart')); chart.setOption({ title: { text: '近30天销售趋势', textStyle: { color: '#fff' } }, tooltip: { trigger: 'axis' }, xAxis: { data: data.dates, axisLabel: { color: '#aaa' } }, yAxis: { axisLabel: { color: '#aaa' } }, series: [ { name: '销售额', type: 'line', data: data.sales, smooth: true, lineStyle: { color: '#00d4ff' }, itemStyle: { color: '#00d4ff' } } ] }); }); } loadTrend(); setInterval(loadTrend, 30000); // 每30秒刷新 </script>

大屏的视觉效果，说实话比功能代码更容易拉开差距。同样一份数据，别人用默认白底表格，你用深色大屏+平滑曲线+自动刷新，感官上就是两个档次的系统。这也是我想特别强调的“低成本高收益”操作。

6. 答辩高频问题与排查技巧实录

6.1 答辩时老师最喜欢问的5个问题

根据我个人以模拟评审身份参与的多次答辩经验，这5个问题被问到的概率极高，提前准备好处极大：

1. “订单表中的product_name为什么要冗余保存？”回答思路：防止商品改名或删除导致历史订单报表数据不准确。订单是事实，必须保留下单时的商品快照。这是分析系统的务实设计。

2. “复购率是怎么计算的？统计口径是什么？”回答思路：清晰说出公式——统计周期内下单次数大于1次的用户数 除以 总有购买行为用户数。强调分母是“有购买行为”的用户，不是注册用户数。

3. “销售趋势统计时，为什么用TruncDate而不是DateField？”回答思路：订单时间原为精确到秒的DateTimeField，直接按天分组会因时间戳不同而无法聚合。需要用TruncDate截断到天再分组。

4. “你的系统如何保证数据安全？”回答思路：密码哈希存储、session超时管理、未登录无法访问数据页、前端只展示聚合数据不外泄原始订单明细。

5. “分析结果如何验证正确性？”回答思路：抽取某一天或某一分类的数据，与SQL手工查询结果对比验证；造数阶段会核对主要节点的汇总值。

6.2 系统部署启动过程中的常见报错

这部分是实操中非常容易卡壳的点，按出现频率从高到低排列：

报错一：ModuleNotFoundError: No module named 'MySQLdb'原因：未安装mysqlclient或pymysql。 解决：优先装pymysql，并在data_analysis/__init__.py中写入import pymysql; pymysql.install_as_MySQLdb()。

报错二：django.core.exceptions.ImproperlyConfigured: SQLite isn't supported原因：某些Django版本或库要求数据库支持特定功能，SQLite兼容性不足。 解决：切换配置为MySQL，确认MySQL服务已启动，并创建空的数据库实例。

报错三：RuntimeError: Model class ecommerce.models.Order doesn't declare an explicit app_label and isn't in an application in INSTALLED_APPS原因：项目目录下有两个应用，或应用未注册到INSTALLED_APPS。 解决：在settings.py的INSTALLED_APPS中追加'ecommerce'。

报错四：TemplateDoesNotExist: dashboard.html原因：模板目录未注册，或模板放在应用内但路径不对。 解决：在settings.py的TEMPLATES字典中设置'DIRS': [BASE_DIR / 'templates']，模板文件统一放项目根目录下。

6.3 性能优化小技巧：统计查询如何提速

大数据量下，聚合查询会变慢，有三个立刻有效的方法：

• 在Order表的create_time、status字段上建立数据库复合索引，查询过滤速度提升明显。
• 对高频统计接口增加cache_page装饰器。大屏数据30秒内无需重复查询数据库，直接走缓存：

from django.views.decorators.cache import cache_page @cache_page(30) def get_sales_trend(request): ...

• 将统计结果物化为独立汇总表，定时刷新，避开频繁动态聚合。这个方案最彻底，但也最复杂，论文中写到“后期优化方向”即可。

6.4 论文写作时该重点着墨什么

论文结构不一定是标准的“绪论→技术→设计→实现→测试”。指导老师更看重你“为什么做这个设计”的思考过程。我建议四个地方重点着墨：

• 需求分析：写清三类用户（管理员、运营人员、普通访客）的痛点，每个功能对应一个业务问题。
• 数据库设计：画ER图，写清每张表的用途和冗余策略。这是给老师展示你掌握数据建模能力的最佳章节。
• 核心代码设计：不要把全部代码贴进去，只挑销售趋势统计、用户复购率这类带有一定算法逻辑的代码讲解。
• 系统测试：除了功能测试，增加“数据准确性验证”环节——把系统统计的结果和手写SQL查询的结果做对比，这个很有专业感。

6.5 命中高分的现场演示顺序

答辩现场演示建议按这个顺序走，整个逻辑极其顺畅：

1. 登录页面入场，输入账号密码，强调“密码经过哈希加密”。
2. 进入数据大屏，先让全场看视觉效果，讲解四个核心指标是“站在管理层视角看业务”。
3. 切到销售趋势分析页，讲解近30天销售额波动，指出大促日尖峰。
4. 切到商品分析页，展示TOP10排名和分类占比，引出“滞销品”问题。
5. 切到用户分析页，展示新老用户占比和复购率，说明平台的用户粘性情况。
6. 结尾展示Admin后台，现场修改一条商品价格或新增一个用户，再回大屏看数据变化。

整套演示控制在10分钟以内，完全围绕“数据分析”这个核心主题，不拉扯无关功能。

7. 实测效果与个人经验总结

我拿这套系统做了稳定性测试。用造数脚本生成了约5万条订单，在普通笔记本（8G内存，i5处理器）上，数据大屏接口平均响应时间在300ms以内，完全满足演示需求。这个量级已经足够支撑一场完整的答辩演示，完全不用担心性能问题。

有一次我演示时翻了个车，印象很深刻：因为忘记在销售趋势查询里过滤status=1，结果页面把“已取消”的订单也统计进去了，销售额虚高了差不多10%。现场导师一眼就看出来趋势曲线起伏不太正常。从那以后我长了个记性：一切统计先定口径，再写代码。这个习惯也让我在后续的数据分析工作里受益很多。

关于技术方案，Django + MySQL + ECharts这套组合，对毕设场景而言是“够用且好讲”的。如果后续有同学想扩展，比较顺的方向有这几个：引入Redis做缓存层、用Celery做定时统计任务、把前端大屏换Vue重构、增加预测算法模块（用历史销售数据做回归预测）。这些扩展不会推翻现有架构，都是在现有骨架上叠加，这也是当时选型时比较满意的一步。

最后分享一个小技巧：早上写核心算法，下午写页面调整，晚上整理日志和测试数据。看起来是时间管理，其实是在培养项目记录的习惯。答辩老师翻到你的开发日志，看到完整的“需求→设计→踩坑→解决”链路，比任何花哨包装都有说服力。这趟过来，这套系统不止是一个毕设，更是你理解“数据如何产生价值”的起点。