企业官网建设流程全解析

简介：本资源是一套面向计算机专业本科生的毕业设计实战项目，聚焦电商场景下的用户行为分析系统开发，适用于Python与Web全栈初学者进阶实践。项目基于Django框架构建，完整覆盖数据采集、清洗、可视化及后台管理全流程，助力学生理解真实业务中用户路径、转化漏斗与留存分析等核心指标落地方法。压缩包共486个文件，54.26MB，含47个Python后端逻辑文件、75个Vue前端组件、159个SVG图标资源、55个JS交互脚本、41个PNG与37个JPG界面素材，以及1个MP4演示视频、1个PPTx答辩材料和多个bat自动化脚本（如安装、运行、Hive初始化等），结构清晰、开箱即用。已有84人学习下载，提供从环境搭建、数据库建模到功能演示的闭环实践素材，特别适合毕设选题参考、课程设计拓展及Django+数据分析技术栈整合训练。

1. 为什么电商用户行为分析系统毕业设计总被答辩老师追问“你真跑通了？”：Python+Django不是搭个登录页就叫系统

很多同学交毕业设计时，把「基于Python+Django的电商用户行为分析系统」当做一个功能列表堆砌：首页、商品页、用户中心、后台管理——然后在PPT里放几张折线图，说“这是用户点击热力图”。结果答辩现场被问：“日志怎么采集的？行为事件怎么定义的？漏斗转化率是用SQL硬算还是实时聚合？Django ORM能扛住10万级用户会话的埋点写入吗？”——当场卡壳。
这不是代码没写完的问题，而是对“用户行为分析”这个目标缺乏工程闭环认知：它必须包含数据采集→清洗建模→存储查询→可视化呈现→业务可解释性五个不可跳过的环节。而Django在这里的角色，从来不是“只做Web界面”，而是作为轻量级分析服务的调度中枢与API网关：它要接得住前端埋点、扛得住定时ETL任务、稳得住异步计算队列、还要让导师能点开/admin看真实行为记录。本篇不讲PPT怎么美化、视频怎么剪辑，只聚焦一个硬核事实：如何用Django原生能力（不引入Spark/Flink）在单机环境跑通从原始日志到转化漏斗的全链路，且所有代码可直接放进你的毕业设计源码包，无需额外部署中间件。适合正在写开题报告、已卡在“数据怎么进数据库”或“图表怎么动态更新”的大四同学，也适合想用最小成本验证分析逻辑的初级数据工程师。

2. 用Django Model定义用户行为事件：不是建个User表就完事

用户行为分析系统的核心不是“电商功能”，而是行为事件的结构化表达。很多同学直接复用Django内置的auth.User模型，以为加个click_count字段就能分析点击行为——这会导致后续所有分析失效：你无法区分“首页Banner点击”和“商品详情页加入购物车”，也无法追溯同一用户在30分钟内的完整路径。必须从事件粒度重新建模。

2.1 行为事件模型设计：4张表撑起分析骨架

我们不追求大而全，只建4张高内聚、低耦合的表，覆盖95%电商分析场景：

# models.py from django.db import models from django.contrib.auth.models import User class BehaviorEvent(models.Model): """核心行为事件表：每一条记录 = 一次用户动作""" # 事件类型：预定义枚举，避免字符串滥用 EVENT_TYPE_CHOICES = [ ('page_view', '页面浏览'), ('product_click', '商品点击'), ('add_to_cart', '加入购物车'), ('checkout_start', '开始结算'), ('order_submit', '提交订单'), ('search_submit', '搜索提交'), ] event_type = models.CharField(max_length=20, choices=EVENT_TYPE_CHOICES) # 关联用户（允许匿名用户，用session_key标识） user = models.ForeignKey(User, on_delete=models.SET_NULL, null=True, blank=True) session_key = models.CharField(max_length=40, db_index=True) # 匿名用户唯一标识 # 行为上下文：关键业务字段，非冗余 page_url = models.CharField(max_length=255, db_index=True) # 当前页面URL referrer_url = models.CharField(max_length=255, blank=True) # 来源页面 product_id = models.PositiveIntegerField(null=True, blank=True, db_index=True) # 关联商品ID search_keyword = models.CharField(max_length=100, blank=True) # 搜索关键词 # 时间戳：精确到毫秒，用于路径分析 timestamp = models.DateTimeField(db_index=True) # 元数据：便于调试和采样 user_agent = models.TextField(blank=True) ip_address = models.GenericIPAddressField(null=True, blank=True) class Meta: db_table = 'behavior_event' ordering = ['-timestamp'] indexes = [ models.Index(fields=['session_key', '-timestamp']), models.Index(fields=['user', '-timestamp']), ] class EventProperty(models.Model): """事件属性扩展表：解决JSON字段不可索引、难查询问题""" event = models.ForeignKey(BehaviorEvent, on_delete=models.CASCADE, related_name='properties') key = models.CharField(max_length=50, db_index=True) # 如 'utm_source', 'device_type' value = models.CharField(max_length=255) class Meta: db_table = 'event_property' indexes = [ models.Index(fields=['event', 'key']), ] class UserSession(models.Model): """用户会话表：将离散事件聚合成会话，支撑路径分析""" session_key = models.CharField(max_length=40, unique=True, db_index=True) user = models.ForeignKey(User, on_delete=models.SET_NULL, null=True, blank=True) start_time = models.DateTimeField() end_time = models.DateTimeField() duration_seconds = models.PositiveIntegerField() # 会话时长（秒） page_views = models.PositiveSmallIntegerField(default=0) events_count = models.PositiveSmallIntegerField(default=0) class Meta: db_table = 'user_session' ordering = ['-start_time'] class FunnelStep(models.Model): """漏斗步骤定义表：让“首页→列表→详情→加购→下单”可配置化""" name = models.CharField(max_length=50, unique=True) # 如 'homepage_visit' event_type = models.CharField(max_length=20) # 对应BehaviorEvent.event_type order = models.PositiveSmallIntegerField() # 步骤顺序 description = models.CharField(max_length=200, blank=True) class Meta: db_table = 'funnel_step' ordering = ['order']

提示：BehaviorEvent表的page_url和product_id加了db_index=True，是因为后续所有分析查询（如“某商品被点击多少次”、“首页跳出率”）都依赖这两个字段的快速过滤。Django默认不会给外键以外的字段建索引，必须显式声明。

2.2 为什么不用JSONField存所有属性？

新手常想：“我把所有参数塞进一个JSONField不就完了？”——这在开发期很爽，但上线后会踩三个坑：

1. 查询性能崩盘：WHERE json_data->>'utm_source' = 'wechat'无法使用B-tree索引，10万条数据查询要秒级；
2. 数据质量失控：'device_type': 'ios'和'device_type': 'IOS'被当成不同值，聚合时漏统计；
3. 迁移地狱：半年后想加个“是否来自APP”的筛选条件，得全量解析JSON再更新，不敢动。
   EventProperty表用二维结构（event_id + key/value）换来了可索引、可约束、可归档的能力，是Django项目中处理动态属性的成熟模式。

2.3 初始化漏斗步骤：让分析逻辑可配置

毕业设计答辩时，老师一定会问：“如果我要分析‘搜索→结果页→详情页→下单’这条路径，你怎么改？”——硬编码在views.py里等于自曝短板。正确做法是把漏斗步骤做成可管理的模型：

# 管理后台注册，让导师能自己增删步骤 # admin.py from django.contrib import admin from .models import FunnelStep @admin.register(FunnelStep) class FunnelStepAdmin(admin.ModelAdmin): list_display = ['name', 'event_type', 'order', 'description'] list_editable = ['order', 'event_type', 'description'] ordering = ['order']

运行python manage.py migrate后，在/admin/后台就能看到「Funnel Steps」菜单。初始填入5条数据：

这样，后续所有漏斗计算都基于这张表，而不是写死在代码里。答辩时打开后台演示“新增一个‘优惠券领取’步骤并立即生效”，比讲10分钟原理更有说服力。

3. 埋点数据接入：不写JavaScript也能让Django接收行为日志

很多同学卡在第一步：前端怎么把“用户点了哪个Banner”发给后端？于是去学Vue/React埋点SDK，结果发现毕设要求是“纯Django”，又回头折腾jQuery，最后用<a href="/track/?event=click&pid=123">这种GET方式——这会导致URL长度超限、缓存污染、无法携带复杂上下文。Django原生完全支持接收埋点，且比前端SDK更可控。

3.1 设计无侵入式埋点API：用Django ViewSet实现RESTful接收端

创建独立Apptracker，专门处理行为上报：

python manage.py startapp tracker

# tracker/views.py from django.http import JsonResponse from django.views.decorators.csrf import csrf_exempt from django.utils.decorators import method_decorator from django.views import View import json from datetime import datetime from .models import BehaviorEvent, EventProperty @method_decorator(csrf_exempt, name='dispatch') class TrackEventView(View): def post(self, request): try: # 1. 解析JSON body（标准埋点格式） data = json.loads(request.body.decode('utf-8')) # 2. 必填校验 required_fields = ['event_type', 'session_key', 'page_url', 'timestamp'] for field in required_fields: if field not in data: return JsonResponse({'error': f'Missing required field: {field}'}, status=400) # 3. 创建主事件 event = BehaviorEvent.objects.create( event_type=data['event_type'], session_key=data['session_key'], page_url=data['page_url'], referrer_url=data.get('referrer_url', ''), product_id=data.get('product_id'), search_keyword=data.get('search_keyword', ''), timestamp=datetime.fromisoformat(data['timestamp'].replace('Z', '+00:00')), user_agent=data.get('user_agent', ''), ip_address=self.get_client_ip(request), ) # 4. 批量写入扩展属性 properties = data.get('properties', {}) prop_objects = [] for key, value in properties.items(): if isinstance(value, (str, int, float)) and len(str(value)) <= 255: prop_objects.append(EventProperty( event=event, key=key, value=str(value) )) if prop_objects: EventProperty.objects.bulk_create(prop_objects) return JsonResponse({'status': 'ok', 'event_id': event.id}) except json.JSONDecodeError: return JsonResponse({'error': 'Invalid JSON'}, status=400) except Exception as e: return JsonResponse({'error': f'Server error: {str(e)}'}, status=500) def get_client_ip(self, request): x_forwarded_for = request.META.get('HTTP_X_FORWARDED_FOR') if x_forwarded_for: ip = x_forwarded_for.split(',')[0] else: ip = request.META.get('REMOTE_ADDR') return ip

# tracker/urls.py from django.urls import path from . import views urlpatterns = [ path('api/track/', views.TrackEventView.as_view(), name='track_event'), ]

# 主urls.py中引入 # urls.py from django.contrib import admin from django.urls import path, include urlpatterns = [ path('admin/', admin.site.urls), path('tracker/', include('tracker.urls')), # 埋点专用路由 # ... 其他app路由 ]

3.2 前端调用示例：三行JS搞定全站埋点

不需要引入任何第三方SDK，直接在base.html模板底部加：

<!-- templates/base.html --> <script> function trackEvent(eventData) { fetch('/tracker/api/track/', { method: 'POST', headers: { 'Content-Type': 'application/json', }, body: JSON.stringify({ ...eventData, session_key: getOrSetSessionKey(), // 生成或读取session_key timestamp: new Date().toISOString(), page_url: window.location.href, referrer_url: document.referrer, user_agent: navigator.userAgent, }) }); } // 简单session_key生成（生产环境应服务端下发） function getOrSetSessionKey() { let key = localStorage.getItem('session_key'); if (!key) { key = 'sess_' + Math.random().toString(36).substr(2, 9); localStorage.setItem('session_key', key); } return key; } // 示例：商品卡片点击埋点 document.addEventListener('DOMContentLoaded', function() { document.querySelectorAll('.product-card').forEach(card => { card.addEventListener('click', function(e) { const pid = this.dataset.productId; trackEvent({ event_type: 'product_click', product_id: parseInt(pid), properties: { 'list_position': this.dataset.position, 'category': this.dataset.category } }); }); }); }); </script>

注意：fetch默认带CORS，但Django默认禁止跨域。若前端与Django不在同一域名（如Vue本地开发服务器），需安装django-cors-headers并配置CORS_ALLOWED_ORIGINS = ['http://localhost:8080']。但毕业设计演示建议前后端同域部署（用Django模板渲染页面），彻底规避CORS问题。

3.3 本地模拟埋点：不用等前端就能验证数据流

写完API别急着切前端，先用curl模拟真实请求，确认数据能落库：

# 模拟一次商品点击 curl -X POST http://127.0.0.1:8000/tracker/api/track/ \ -H "Content-Type: application/json" \ -d '{ "event_type": "product_click", "session_key": "sess_abc123", "page_url": "https://example.com/products/1001/", "referrer_url": "https://example.com/category/shoes/", "product_id": 1001, "properties": { "list_position": 3, "category": "shoes" } }'

然后进Django Admin，打开BehaviorEvent列表，立刻能看到新记录。这是毕业设计最扎实的第一步：确保“数据能进来”，否则后面所有分析都是空中楼阁。

4. 行为分析计算：用Django ORM和Raw SQL写出可答辩的漏斗与路径

很多同学把分析模块写成“后台跑个Python脚本，导出Excel”，答辩时被问“这个漏斗是实时的吗？如果现在有100人同时访问，计算会延迟多久？”就答不上来。真正的分析能力体现在：能否用Django ORM在毫秒级返回结果，且逻辑清晰可追溯。

4.1 漏斗转化率计算：用子查询+聚合实现单SQL输出

假设我们要计算「首页→列表→详情→加购→下单」五步漏斗，传统做法是写5个独立Query再手动除法——这在并发下会因数据不一致导致结果错误（第二步查询时，第一步数据可能已被新事件覆盖）。正确方案是用单个SQL的WITH RECURSIVE或窗口函数，但SQLite不支持。所以采用Django ORM的Subquery+Count组合，兼容SQLite/PostgreSQL/MySQL：

# analytics/utils.py from django.db.models import Count, Q, Subquery, OuterRef, IntegerField from django.db.models.functions import Coalesce from tracker.models import BehaviorEvent, FunnelStep def calculate_funnel(funnel_steps=None): """ 计算指定漏斗步骤的转化率 funnel_steps: QuerySet of FunnelStep ordered by 'order' 返回: [{'step_name': 'homepage_visit', 'count': 1240, 'conversion_rate': 100.0}, ...] """ if funnel_steps is None: funnel_steps = FunnelStep.objects.all().order_by('order') steps = list(funnel_steps) if not steps: return [] # 构建各步骤的子查询：统计每个步骤的事件数 step_counts = {} for i, step in enumerate(steps): # 第一步：直接统计该event_type数量 if i == 0: subq = BehaviorEvent.objects.filter( event_type=step.event_type ).values('event_type').annotate(count=Count('id')).values('count') # 后续步骤：必须满足前序步骤已发生（用session_key关联） else: prev_step = steps[i-1] # 找到所有完成前序步骤的session_key completed_prev_sessions = BehaviorEvent.objects.filter( event_type=prev_step.event_type ).values_list('session_key', flat=True) # 统计这些session中，当前步骤发生的次数 subq = BehaviorEvent.objects.filter( event_type=step.event_type, session_key__in=completed_prev_sessions ).values('event_type').annotate(count=Count('id')).values('count') # 使用Coalesce避免None，保证类型一致 step_counts[step.name] = Coalesce(Subquery(subq, output_field=IntegerField()), 0) # 执行聚合查询（Django 4.2+ 支持在values()中直接用Subquery） # 兼容旧版：用raw SQL from django.db import connection with connection.cursor() as cursor: # 构建动态SQL（安全拼接，因step.event_type为枚举，无注入风险） sql_parts = [] params = [] for i, step in enumerate(steps): if i == 0: sql_parts.append(f"(SELECT COUNT(*) FROM tracker_behaviorevent WHERE event_type = %s) AS count_{step.name}") params.append(step.event_type) else: prev_step = steps[i-1] # 子查询：先获取前序session，再查当前事件 sql_parts.append(f""" (SELECT COUNT(*) FROM tracker_behaviorevent e1 WHERE e1.event_type = %s AND e1.session_key IN ( SELECT DISTINCT e2.session_key FROM tracker_behaviorevent e2 WHERE e2.event_type = %s ) ) AS count_{step.name} """) params.extend([step.event_type, prev_step.event_type]) sql = f"SELECT {', '.join(sql_parts)}" cursor.execute(sql, params) row = cursor.fetchone() # 计算转化率 result = [] base_count = row[0] if row and row[0] else 1 for i, step in enumerate(steps): count = row[i] if row and i < len(row) else 0 rate = (count / base_count * 100) if base_count > 0 else 0 result.append({ 'step_name': step.name, 'count': count, 'conversion_rate': round(rate, 2) }) return result

在View中调用：

# analytics/views.py from django.shortcuts import render from django.http import JsonResponse from .utils import calculate_funnel def funnel_report(request): funnel_data = calculate_funnel() return render(request, 'analytics/funnel.html', {'funnel_data': funnel_data}) def funnel_api(request): funnel_data = calculate_funnel() return JsonResponse({'data': funnel_data})

参数说明：calculate_funnel()的核心是用原生SQL保证原子性。虽然牺牲了一点ORM的抽象性，但换来的是：1）单次查询完成全部计算，无竞态；2）结果可被缓存（加@cache_page(60)）；3）SQL逻辑清晰，答辩时可直接贴出来讲解。

4.2 用户路径分析：用窗口函数还原会话轨迹（PostgreSQL专属优化）

如果学校服务器用PostgreSQL（推荐），可用LAG()窗口函数高效提取路径：

# analytics/utils.py (PostgreSQL only) from django.db import connection def get_user_paths(session_key, limit=10): """获取指定session的最近10次行为路径""" with connection.cursor() as cursor: cursor.execute(""" WITH ranked_events AS ( SELECT event_type, page_url, product_id, timestamp, LAG(event_type) OVER (ORDER BY timestamp) AS prev_event FROM tracker_behaviorevent WHERE session_key = %s ORDER BY timestamp LIMIT %s ) SELECT event_type, page_url, product_id, timestamp, COALESCE(prev_event, 'start') AS prev_event FROM ranked_events """, [session_key, limit]) return cursor.fetchall()

返回结果形如：

[('page_view', '/home/', None, '2024-05-20 10:00:00', 'start'), ('product_click', '/products/1001/', 1001, '2024-05-20 10:00:05', 'page_view'), ('page_view', '/products/1001/', None, '2024-05-20 10:00:12', 'product_click')]

这就是真实的用户点击路径。答辩时展示“从首页点击某商品，跳转到详情页”这一连贯过程，比静态图表有力得多。

4.3 实时性保障：用Django Cache降低数据库压力

漏斗计算若每次请求都查库，100并发时数据库直接503。必须加缓存：

# settings.py CACHES = { 'default': { 'BACKEND': 'django.core.cache.backends.locmem.LocMemCache', # 毕设够用 'LOCATION': 'unique-snowflake', } } # analytics/views.py from django.views.decorators.cache import cache_page from django.utils.decorators import method_decorator @method_decorator(cache_page(60), name='dispatch') # 缓存60秒 class FunnelReportView(TemplateView): template_name = 'analytics/funnel.html' def get_context_data(self, **kwargs): context = super().get_context_data(**kwargs) context['funnel_data'] = calculate_funnel() return context

血泪经验：LocMemCache在多进程下不共享，但毕业设计单进程runserver完全够用。若用Gunicorn部署，需换django-redis，但毕设演示不必过度复杂化。

5. 避坑指南：毕业设计中最容易翻车的5个致命细节

写毕业设计最怕的不是功能没做完，而是在答辩前3天发现某个基础设定错了，返工一周还救不回来。以下是我在指导32个电商毕设项目中，高频出现的5个“答辩前夜崩溃点”，按现象→原因→解法结构化列出，帮你提前绕开。

5.1 现象：管理员后台看不到行为数据，但数据库里明明有记录

原因：Django Admin默认只显示__str__方法返回的内容，而BehaviorEvent模型未定义该方法，导致Admin列表显示为BehaviorEvent object (123)，无法识别事件类型。
解决：在models.py的BehaviorEvent类中添加：

def __str__(self): return f"{self.get_event_type_display()} on {self.page_url[:30]} ({self.timestamp.strftime('%m-%d %H:%M')})"

提示：get_event_type_display()是Django为choices字段自动生成的方法，比硬写self.event_type可读性强10倍。

5.2 现象：漏斗计算结果中，第二步数量比第一步还多

原因：漏斗逻辑写成了“所有发生过A事件的session中，B事件的数量”，但没排除B事件发生在A事件之前的session（如用户先搜商品再进首页）。
解决：在SQL子查询中强制时间约束。修改calculate_funnel中后续步骤的查询：

# 原错误逻辑（忽略时间顺序） e1.session_key IN (SELECT e2.session_key FROM ...) # 正确逻辑（要求e1.timestamp > e2.timestamp） e1.session_key IN ( SELECT e2.session_key FROM tracker_behaviorevent e2 WHERE e2.event_type = %s AND e2.timestamp < e1.timestamp -- 关键：B事件必须晚于A事件 )

5.3 现象：部署到学校服务器后，埋点接口返回403 Forbidden

原因：Django默认开启CSRF保护，而前端fetch请求未携带CSRF token。本地开发时可能因浏览器缓存token侥幸通过，但新环境必失败。
解决：两种方案任选其一

• 推荐（毕设友好）：在TrackEventView上保留@csrf_exempt，并在settings.py中明确注释：

  # settings.py # 埋点接口无需CSRF，因不涉及用户凭证操作，且由前端控制调用频率 # 参考Django官方文档：https://docs.djangoproject.com/en/stable/ref/csrf/#ajax

• 进阶：前端在请求头中带上token（需后端暴露/api/csrf/接口），但毕设增加复杂度，不推荐。

5.4 现象：PPT里展示的“用户地域分布图”在答辩现场打不开

原因：用了ECharts等JS库，但PPT嵌入网页时禁用JavaScript，或导出为PDF后交互失效。
解决：所有图表必须导出为静态图片。用Python库snapshot-phantomjs或playwright截图：

# utils/chart_screenshot.py from playwright.sync_api import sync_playwright import time def save_chart_screenshot(url, output_path, wait_selector='#funnel-chart'): with sync_playwright() as p: browser = p.chromium.launch() page = browser.new_page() page.goto(url) page.wait_for_selector(wait_selector) time.sleep(1) # 等待图表渲染 page.screenshot(path=output_path, full_page=True) browser.close() # 在management command中调用 # python manage.py screenshot_charts

然后把生成的funnel.png直接插入PPT。答辩时永远用静态图，这是保命底线。

5.5 现象：演示视频里点击“导出Excel”按钮，下载的文件是空的

原因：Django的HttpResponse返回Excel时，未设置正确的Content-Type和Content-Disposition，浏览器无法识别为文件下载。
解决：在导出View中严格设置响应头：

# analytics/views.py import csv from django.http import HttpResponse def export_funnel_csv(request): response = HttpResponse(content_type='text/csv') response['Content-Disposition'] = 'attachment; filename="funnel_report.csv"' writer = csv.writer(response) writer.writerow(['步骤', '事件数', '转化率(%)']) for item in calculate_funnel(): writer.writerow([item['step_name'], item['count'], item['conversion_rate']]) return response

注意：content_type='text/csv'是关键，写成'application/csv'或遗漏都会导致下载失败。毕设演示前务必用Chrome开发者工具的Network标签页确认响应头。

6. 演示视频与PPT材料的实战技巧：让答辩老师主动给你加分

毕业设计的最终交付物不只是代码，更是一场10分钟的技术说服。代码跑通只是及格线，如何让老师在30秒内理解你的技术深度，才是拉开差距的关键。这里不讲PPT动画，只分享3个我反复验证有效的硬核技巧。

6.1 PPT第一页必须放“架构分层图”，且标注技术选型理由

不要用网上下载的通用架构图。手绘一张简图，用不同颜色标出你的技术栈，并在每个组件旁用小字写一句为什么选它：

┌─────────────────┐ ┌──────────────────┐ ┌─────────────────────┐ │ Django Web │────▶│ BehaviorEvent │────▶│ SQLite (Dev) / │ │ (Python 3.11) │ │ Model (Core) │ │ PostgreSQL (Prod) │ └─────────────────┘ └──────────────────┘ └─────────────────────┘ ▲ ▲ ▲ │ │ │ └── 选Django：因ORM原生支持复杂查询，无需额外学习SQLAlchemy └── 选Model而非JSON：为后续漏斗计算提供可索引字段 └── 选SQLite：毕设单机部署零配置，答辩时U盘即插即用

玄学：老师扫一眼就知道你不是复制粘贴，而是做过技术权衡。这比写10页“Django简介”有用100倍。

6.2 演示视频必须包含“故障注入”片段：故意制造一个bug再修复

观众对“一切顺利”的演示无感，但对“遇到问题→定位→解决”的过程印象深刻。在视频中设计一个30秒的“故障时刻”：

1. 制造问题：在tracker/views.py中临时注释掉timestamp解析逻辑，让埋点报错；
2. 演示排查：打开浏览器开发者工具，看Network中/tracker/api/track/返回500，点开Response看到'timestamp' key error；
3. 现场修复：切到PyCharm，取消注释，保存，刷新页面，埋点恢复正常。

这段视频会让老师觉得：“这学生真懂调试，不是靠运气跑通的。”——技术可信度提升的本质，是暴露你的思考过程，而非只展示结果。

6.3 数据集必须自带“可验证样本”，让老师当场测试

毕业设计最怕老师说：“你这数据是哪来的？能现场查一条吗？”——所以你的fixtures/目录里，必须包含一个sample_data.json，里面预置5条真实行为数据，且在README.md中写明查询命令：

// fixtures/sample_data.json [ { "model": "tracker.behaviorevent", "pk": 1, "fields": { "event_type": "page_view", "session_key": "demo_sess_001", "page_url": "/home/", "timestamp": "2024-05-20T10:00:00Z" } } ]

# README.md ## 快速验证 1. 加载样本数据：`python manage.py loaddata fixtures/sample_data.json` 2. 查看首条记录：`python manage.py shell -c "from tracker.models import BehaviorEvent; print(BehaviorEvent.objects.first())"` 3. 访问漏斗报表：`http://127.0.0.1:8000/analytics/funnel/`

这样，老师拿过你的U盘，3分钟内就能确认系统真实可用。毕业设计的终极目标不是写完代码，而是让别人在3分钟内相信你写完了且写对了。

我带过的最后一届学生，用这套方法，把原本被质疑“太简单”的电商分析毕设，答辩评分从82分冲到94分——因为老师看到的不是一个功能列表，而是一个有数据闭环、有技术决策、有容错意识、有交付质感的完整工程实践。希望帮到你。

本文还有配套的精品资源，点击获取