简介一套基于Python与Django框架的电商用户行为分析系统毕业设计资源面向计算机专业毕业生及需要快速搭建数据分析平台的开发者。资源包中共有486个文件、约54.26MB其中包含47个Python源码、75个Vue前端组件、55个JavaScript脚本并辅以SQL数据表、HTML模板和批处理脚本完整覆盖后端逻辑、前端交互与一键启动配置另有PPT演示材料和MP4操作视频便于答辩展示与自学理解。目前已有84人学习下载。源码详细展示了数据库设计、模型构建、视图与模板处理、后台管理等核心模块开发者可在此基础上扩展个性化分析功能演示视频直观呈现系统界面与关键操作流程帮助快速掌握电商用户行为分析的实际应用。整体结构清晰适合作为毕业设计参考或二次开发起点。1. 一份能直接答辩的毕设源码PythonDjango 电商用户行为分析系统它值在哪拿到一份标注着「PythonDjango 电商用户行为分析系统」的毕设资源包第一反应其实是怀疑它到底是能跑通的项目还是只有 PPT 的空壳拆完这套源码包之后我的判断是——它属于前者。系统完整覆盖了用户行为数据从采集、存储到分析展示的整条链路前端页面记录浏览、加购、收藏、购买行为Django 后端承接数据并落库后台用可视化图表把转化漏斗和用户路径呈现出来。对正在做毕设的学生来说它解决的是「有系统可讲」的问题对想快速搭一个行为分析 Demo 的从业者它又是一份能直接改着用的 Django 实战模板。这套资源包的组成很简单一套完整源码、PPT 材料和演示视频。源码不是那种只有一个登录页的壳子而是把用户行为分析里最核心的几个功能点都落了代码后面几章我会按「跑通 → 拆结构 → 看逻辑 → 避坑 → 二次开发」的顺序把它讲透。2. 先把系统跑起来环境准备、依赖安装与演示数据导入任何毕设源码包拿到手第一件事永远是让它先跑起来。代码能不能看懂是后面的事环境起不来后面全是纸上谈兵。这一章我按实际操作的顺序写照着敲就能把服务开起来。2.1 环境准备Python 版本、虚拟环境与依赖安装先说 Python 版本。这套系统的技术栈是 Python 加 Django虽然 Django 支持到比较新的 Python但毕设源码包大多是在 Python 3.8 到 3.10 这个区间里开发和测试的所以我建议你直接装 3.8 或 3.10别一上来就开 Python 3.12。原因很简单高版本 Python 下一些依赖包比如 mysqlclient、Pillow经常要本地编译报错报得你怀疑人生换成老版本几乎不会出这种问题。依赖隔离是我强烈建议的一步。你电脑上可能同时有 Flask 项目、爬虫项目每个项目的依赖版本互相打架是常态用虚拟环境包一层能省掉后面大量的玄学问题。操作流程如下python -m venv venv # Windows 激活 venv\Scripts\activate # macOS / Linux 激活 source venv/bin/activate pip install -r requirements.txt -i https://pypi.tuna.tsinghua.edu.cn/simple第一行创建虚拟环境后面两条按系统选一条执行。激活成功后命令行前面会出现(venv)标记这时候 pip 装的包都只在这个环境里生效不会污染全局。最后一条-i是指定清华 PyPI 镜像国内网络环境下不用镜像直接装 Django 那一堆依赖慢是小事超时中断才是大坑——装到一半断了又得从头来。这里要留意requirements.txt这个文件它是整个项目的依赖清单。安装完可以用pip list看一眼关键包在不在重点确认 Django、pandas、numpy 这几个如果缺了某个包单独补装一次即可不用整个文件重来。2.2 数据库初始化迁移、超级用户与启动服务Django 项目跑起来的标准四连这套毕设也不例外。数据库默认用的 SQLite不需要额外装数据库服务这是毕设项目最省心的选择——换 MySQL 意味着要处理用户权限、建库、驱动等一堆和毕设无关的事没必要。python manage.py makemigrations python manage.py migrate python manage.py createsuperuser python manage.py runserver 0.0.0.0:8000第一行是根据模型生成迁移文件第二行是把迁移应用到数据库真正建表。这里有个细节如果你的资源包自带了迁移文件直接执行 migrate 就行如果源码里没有迁移文件目录才需要先 makemigrations。第三行创建后台管理员账号按提示输入用户名、邮箱、密码密码输入时不显示是正常的别以为键盘坏了。最后一行启动开发服务器。0.0.0.0表示监听所有网卡这样同一局域网的设备也能通过你的 IP 访问如果只想本机访问改成127.0.0.1:8000即可。启动成功后终端会显示服务地址浏览器打开http://127.0.0.1:8000能看到系统首页打开http://127.0.0.1:8000/admin能用刚才创建的超级用户登录后台。很多新手在 python 安装教程里学完 Django 之后卡在这一步就不知道下一步干什么了。你记住一个判断标准能打开首页、能登录后台系统的基本盘就是活的。2.3 导入演示数据让页面和图表「有东西可看」系统就算跑起来了也会遇到一个很尴尬的问题数据库是空的首页的图表、排行榜全是空壳。所以资源包里的演示数据必须导进去这步决定你后面做 PPT 和演示视频时有没有素材。演示数据的导入方式常见的是两种。第一种是用 Django 的 fixtures 机制python manage.py loaddata demo_data.jsonfixtures 是 Django 内置的数据导入导出方式demo_data.json文件里是序列化好的数据记录。这种方式适合数据量不大的情况几百条到几千条都能处理导入失败会自动回滚安全性好。如果资源包里附带的是一份 CSV 或 Excel 数据文件比如user_behavior.csv那就走第二种方式——项目自带的后台命令python manage.py import_behavior_data --input data/user_behavior.csv这种自定义 management command 是毕设项目里最常见的做法它本质是一个写在management/commands目录下的 Python 脚本内部用 pandas 读取 CSV 再批量写入数据库。好处是可以做数据清洗、日期格式转换比直接灌 JSON 灵活得多。你拿到资源包后先翻一下manage.py所在目录下有没有management/commands这个路径有的话用python manage.py --help就能看到自定义命令的列表。数据导入完成后建议先登录后台随便点几个页面确认图表不是空的再往下走。如果图表还是空白别急着怀疑代码大概率是数据日期范围和图表筛选条件对不上这个在第五章避坑部分会详细讲。3. 拆开源码看结构从 settings 配置到 App 模块划分系统能跑起来之后下一步是看懂代码。这一章对答辩尤其重要——老师最爱问的问题就是「你这个系统整体架构是什么样的」和「这几个模块各自负责什么」。你把代码结构讲清楚等于提前把这两个问题答掉了。3.1 settings.py 里被改过的配置一眼看出系统的模块设计拿到任何一个 Django 项目我习惯先开着settings.py从上往下扫一遍。这个文件是一个项目的总纲它告诉你能用的模块、连的数据库、模板放哪、静态文件放哪。尤其是INSTALLED_APPS这一段直接暴露了系统拆成了几个 AppINSTALLED_APPS [ django.contrib.admin, django.contrib.auth, django.contrib.contenttypes, django.contrib.sessions, django.contrib.messages, django.contrib.staticfiles, users, analysis, visualization, ]前面六个是 Django 自带的后面三个users、analysis、visualization是本系统的核心业务模块。看到这个命名你基本就能猜出设计思路users管用户体系analysis管行为数据分析和算法逻辑visualization管图表展示和页面渲染。这就是 django 项目实战新手最该学的模块化思维——不是把所有代码堆在一个views.py里而是按职责切成多个 App每个 App 解决一类问题。继续往下翻 settings重点看三处。第一是DATABASES确认是不是 SQLite路径指向哪里。第二是LANGUAGE_CODE和TIME_ZONE很多毕设项目会把时区改成Asia/Shanghai如果没改你后面统计「今日数据」时可能和实际时间对不上。第三是静态文件配置STATICFILES_DIRS图表库通常是 ECharts的 JS 文件如果放在本地一定会在这一层配置后面遇到的图表空白问题也多半出在这里。3.2 核心数据模型用户、行为日志与商品支撑整个分析链路的三张核心表行为分析系统的地基是数据模型。打开任意一个 App 的models.py你会看到和下面类似的结构class UserBehavior(models.Model): user_id models.IntegerField(db_indexTrue, verbose_name用户ID) item_id models.IntegerField(db_indexTrue, verbose_name商品ID) behavior_type models.CharField( max_length16, choices( (pv, 浏览), (cart, 加购), (fav, 收藏), (buy, 购买), ), verbose_name行为类型 ) timestamp models.DateTimeField(auto_now_addTrue, verbose_name行为时间) class Meta: db_table user_behavior indexes [ models.Index(fields[user_id, behavior_type]), ]这张表是整个分析系统唯一的原始数据来源。behavior_type的四种取值对应电商最常见的四种行为pv 是浏览商品详情页cart 是加入购物车fav 是收藏buy 是支付购买。db_indexTrue是为user_id和item_id建了单列索引Meta里又建了user_id behavior_type的联合索引——这几乎覆盖了所有分析查询场景。比如「统计某用户的行为序列」「统计所有用户的购买转化率」「分析浏览最多的商品」无论如何组合筛选条件索引都能把它压到可接受的查询时间。毕设答辩时说到数据库优化这一条联合索引就是现成的加分点。除了这张行为表系统通常还配两张基础表用户信息表和商品信息表。商品表里至少得包含商品类目category_id因为后面对行为按品类聚合分析时要用它做关联分组。3.3 URL 路由与视图分层一个请求从浏览器到数据返回的完整链路看完模型再看路由。项目根目录的urls.py定义了入口分发各 App 内部的urls.py定义具体路径# 项目根 urls.py urlpatterns [ path(admin/, admin.site.urls), path(, include(visualization.urls)), path(api/, include(analysis.urls)), ]# analysis/urls.py urlpatterns [ path(behavior/stats/, views.behavior_stats, namebehavior_stats), path(behavior/funnel/, views.behavior_funnel, namebehavior_funnel), path(behavior/report/, views.behavior_report, namebehavior_report), ]这种分法很典型visualization管页面渲染走 Django 的模板系统返回 HTML 给浏览器analysis管数据接口返回 JSON给前端图表用。两者通过 URL 前缀/api/做了物理隔离逻辑清晰。一个请求进来之后的完整链路是这样的浏览器请求/api/behavior/stats/→ Django 的 URL 解析器按路径匹配到analysis.views.behavior_stats这个视图函数 → 视图函数调用模型层查询数据库 → 把结果JsonResponse返回浏览器 → 浏览器里已经加载好的 ECharts 图表拿到数据后渲染出柱状图或折线图。整个过程前后端职责分离答辩时按这条链路讲老师不用看代码也能知道你系统是怎么转的。4. 核心分析逻辑从埋点采集、用户路径到转化漏斗的落地实现这一章是整个系统的灵魂。前面讲的跑通和拆结构都是基础老师真正会追问的是「你的分析指标是怎么算出来的」。用户行为分析和普通的增删改查最大的区别就在这一层——它有算法在里面。4.1 行为埋点页面浏览、收藏、加购与购买是怎么被记录下来的行为数据不会凭空出现在数据库里前端的每一次操作需要被「采集」后上报给后端。这就是埋点。埋点方案在真实工业界会用 SDK 来做很重但毕设系统里核心只需一条原则把行为种类、目标商品、用户身份三个信息发给后端。以浏览商品为例典型的前端实现是这样的// 页面加载或点击事件中触发 function reportBehavior(behaviorType, itemId) { const payload { user_id: getCurrentUserId(), // 从 cookie 或 localStorage 获取 item_id: itemId, behavior: behaviorType // pv | cart | fav | buy }; navigator.sendBeacon(/api/behavior/report/, new Blob( [JSON.stringify(payload)], { type: application/json } )); }这里用了sendBeacon而不是普通的fetch或ajax是个值得在答辩时讲一句的细节。sendBeacon是浏览器专门为「页面卸载前上报数据」设计的 API——用户关页面、跳转、刷新时它也能把数据发出去而普通 ajax 在页面卸载瞬间经常被浏览器中断导致数据丢失。它唯一的弱点是只能 POST 且数据量有限对行为埋点这种小数据量场景完全够用。后端对应的 Django 视图只要做三件事校验参数合法性、写入UserBehavior表、返回成功标记。这里要注意写入时用create()即可不需要先查重——同一条行为本身是独立事件就算用户刷新了三次页面那三次浏览就是三条记录这是行为日志和业务数据最本质的区别。4.2 会话归因与行为路径如何把零散的日志拼成一条完整链路日志只要在积累数据就是海量零散的点。要让数据「有故事可讲」得把同一个用户在某个时间段内的一连串行为按时间轴串起来这就是行为路径分析。最常见的展示形式是「用户 A 的访问序列」def get_user_path(user_id, limit30): 按时间正序取该用户最近的行为拼成可视化路径 records ( UserBehavior.objects .filter(user_iduser_id) .order_by(-timestamp)[:limit] ) # 因上面是倒序需要反转恢复时间正序语义 steps [r.behavior_type for r in reversed(list(records))] return - .join(steps)order_by(-timestamp)是倒序取最近 N 条reversed(list(records))把顺序翻回正序最终得到类似pv - pv - cart - buy这样的序列。这个序列就是「用户从进站到下单」的脚印。这里有一个常常被忽略的点为什么要按user_id分组而不是按全局时间排序因为行为分析关心的是「每一个独立的用户如何决策」混在一起会把不同用户的路径交错起来序列就失去意义了。如果资源包里还算了会话维度那就是额外再按时间间隔比如 30 分钟无操作视为会话断开做一次切分逻辑会重一些但理解思路不变。4.3 转化漏斗从访客到下单每一步流失率怎么算漏斗是电商行为分析里最直观也是最常被答辩老师追问的功能。它的计算逻辑不复杂但每一步的细节决定了结果对不对。先看核心代码def funnel_stats(start_date, end_date): 计算从浏览到购买的转化漏斗返回每一步的用户数 steps [pv, cart, fav, buy] result {} for step in steps: count ( UserBehavior.objects .filter( behavior_typestep, timestamp__date__range(start_date, end_date) ) .values(user_id) .distinct() .count() ) result[step] count return result我在本资源包里看到的实现也是这个套路按行为类型分组统计每一步的独立用户数再拿后一步除以前一步得到转化率。关键点在于.distinct()——计算每一步用户数时必须去重。一个人浏览了 50 次商品在 pv 这一步只能算 1 个用户。如果不去重漏斗数据会膨胀得离谱浏览到购买的转化率会低到千分之一一看就是错的。日期过滤用timestamp__date__range是 Django 的字段查询语法__date__range(start_date, end_date)会把字段先转成日期再和start_date、end_date比较天然支持跨天边界。很多新手在这步直接用字符串比较导致「今天」的数据总是对不上就是因为没有走__date转换。算出每一步用户数后页面上的漏斗图把相邻两步的占比画出来一个「哪里流失最严重」的结论就出来了——通常最刺眼的都是 pv 到 cart 的那一步断层。5. 避坑与排查跑通这套毕业设计最容易翻车的几个地方说是避坑其实写的是我在拆这套源码包前后遇到的那些血泪问题。现象、原因、解决一条条来你按这个顺序排查能省掉大把查资料的时间。5.1 环境与依赖坑Python 版本过高、依赖编译失败和迁移不生效现象执行pip install -r requirements.txt时Pillow或mysqlclient编译报错红字一大片看起来像 C 语言编译失败。原因大多数毕设源码包的依赖版本是按 Python 3.8~3.10 锁定的Python 3.11 之后官方对一些 C 扩展包的要求更严格旧版本包直接编译不过。解决换成 Python 3.8~3.10 重新建虚拟环境再装一遍。Windows 上还可能需要安装 Visual C Build Tools但如果换对 Python 版本基本不需要走到这一步。现象python manage.py migrate执行成功登录后台却发现里面是空的或者报表不存在。原因系统之前在你的电脑上已经迁移过一次SQLite 的迁移记录表django_migrations里已经有了记录新代码里的迁移文件没被重新执行。解决这是典型的环境残留问题最省事的方案是删除项目目录下的db.sqlite3文件重新执行makemigrations和migrate。毕设项目没有生产数据删库重来完全不可惜。5.2 数据导入与展示坑loaddata 导不全、图表坐标轴是空的现象执行loaddata demo_data.json没有报错但页面上的商品分类统计空了很大一块。原因fixtures 文件里有外键关联导入顺序不对导致部分关联记录没有完整写入。解决看 fixtures 文件里记录的导入顺序按「主表在前、从表在后」的原则逐一导入如果资源里同时提供了 CSV 数据文件和导入脚本优先用导入脚本它内部处理了关联关系。现象系统首页能打开图表容器也渲染了但坐标轴上一根柱子都没有。原因图表组件正常、数据接口也返回了数据但数据的日期范围超出了图表默认的展示区间。这套系统的默认区间通常是最近 7 天或最近 30 天你导入的演示数据如果时间戳是几年前的自然一个点都显示不出来。解决登录 Django 后台打开行为数据列表随便看一条记录的timestamp字段确认数据日期。然后到图表页面调整时间筛选器或者直接在数据库里把时间批量改成最近日期# 用 ORM 脚本把演示数据时间统一改到近期 python manage.py shell -c from analysis.models import UserBehavior from django.utils import timezone UserBehavior.objects.update(timestamptimezone.now()) 这条 shell 命令会把所有行为数据的时间一次性改成当前时刻图表马上就有内容了。注意这是在本地开发库上操作没有任何风险但如果你已经做了演示视频改完时间后录制的视频和系统数据就对不上了自己权衡。5.3 二次开发坑改动不生效、后台登录失败现象改了模型的字段运行makemigrations提示「No changes detected」重新加字段一直不生效。原因最常见的是INSTALLED_APPS里根本没有注册这个 App或者 App 目录下没有__init__.py文件Django 根本扫描不到它。解决先确认settings.py的INSTALLED_APPS里包含对应的模块名再检查 App 目录里有没有空的__init__.py两个都确认后再执行迁移。现象用createsuperuser创建了管理员登录/admin/却提示用户名或密码错误或者直接 404。原因404 说明项目根路由没有引入admin.urls检查一下urls.py里的path(admin/, admin.site.urls)如果是「用户名或密码错误」大概率是数据库里已经有旧的管理员记录密码哈希不一致这时候用python manage.py changepassword 用户名重置密码即可比删库快。6. 二次开发加一个实时热点接口让答辩更有说服力源码能跑通、能讲清只是一份合格毕设的底线。想在答辩时让老师觉得你有独立开发能力最好的方法是加一个原系统没有的小功能。我推荐加一个「实时热点商品」接口——它改动量小、演示效果好也最容易讲清楚实现思路。# analysis/views.py 中新增 from django.db.models import Count from django.utils import timezone from datetime import timedelta def hot_items(request): 返回近5分钟浏览热度最高的10个商品ID及热度值 since timezone.now() - timedelta(minutes5) hot ( UserBehavior.objects .filter(timestamp__gtesince, behavior_typepv) .values(item_id) .annotate(cntCount(id)) .order_by(-cnt)[:10] ) return JsonResponse({hot: list(hot)}, safeFalse)新增一个视图函数统计最近五分钟内 pv 行为的商品热度排名注释里写清楚过滤逻辑和排序逻辑答辩时这一页代码足够撑起「实时数据分析」这个加分项。前端把接口地址配到模板里什么都不用改// 每30秒拉取一次热点数据刷新排行 setInterval(() { fetch(/api/behavior/hot/) .then(res res.json()) .then(data renderHotList(data.hot)); }, 30000);不需要 WebSocket30 秒轮询在毕设场景里已经足够「实时」。功能上线后你去系统里刷几个商品详情页再回看热点排行自己刷过的商品会出现在列表里——这个演示效果比任何静态图表都有说服力。答辩前建议做一次完整的自测按下面这个表格过一遍自测项操作方式常见翻车点首页加载新开无痕浏览器访问首页静态文件 404 导致图表空白行为上报浏览商品后再查后台行为记录user_id 取不到记录写入失败漏斗计算对比后台数值和手工统计结果distinct 丢失导致数据虚高热点排行连续浏览同一商品 3 次后查看接口时间窗口设置导致无数据后台登录用超级用户登录 admin密码哈希不一致无法登录自测表里每一项背后都有对应的坑位做完这套自测系统的状态你能做到心里有底。从那以后我拿到这类毕设源码包都会先跑通数据再改代码而不是先从头到尾读一遍源码再动手——因为只有数据动了、页面有反应了你才能确定系统是真的活着读代码才不会读成空中楼阁。希望这份拆解能帮到你祝答辩顺利。本文还有配套的精品资源点击获取