企业官网建设流程全解析

做了一段时间Django相关的Web和小程序项目后，我最大的感受是：Django这种自带Admin、ORM、迁移体系的全栈框架，用来做“数据展示类”的毕业设计或者课设，真的能省掉很多重复造轮子的时间。今天要拆解的这个项目——基于Python的Django后端 + 学生移动端小程序 + 数据分析，就是一个典型的“数据采集、统计、可视化、移动端展示”闭环。它的目标用户很明确：学生会用小程序查看自己的成绩趋势和排名区间，老师可以查看班级维度的成绩分析报表。适合谁看？准备做同类毕设的学生，想快速搭建小程序数据分析后端的开发者，以及想了解Django和小程序如何串联的初学者。全文会用“需求→设计→实现→踩坑”的顺序来讲，尽量把每个关键决策背后的原因说透。

1. 项目骨架与技术选型思路

1.1 先把需求拆清楚：这个“数据分析”到底想分析什么

很多同学拿到“学生移动端数据分析小程序”这种题目，第一反应是打开编辑器直接写代码，这其实是大忌。你连分析的对象、分析的维度、给谁看都没定义清楚，写出来的东西大概率是一个四处拼凑的“假项目”。

我习惯先拆需求。题目里的三个关键词各有侧重：Django负责“后端服务”，小程序负责“移动端载体”，数据分析才是这个项目的灵魂。换句话说，如果只是把数据库里的学生信息增删改查搬到小程序端，那不叫数据分析小程序，那叫“学生信息管理系统换了个壳”。要让答辩老师或者评审认可，你必须有“分析”的动作：从一堆原始数据里算指标、看分布、找趋势。

具体到这个项目，我建议把分析场景定为“学生成绩分析”，这是最稳妥也最好讲的场景。原始数据是学生的成绩明细，分析对象可以拆成三个层面：

• 个体层面：单个学生的总分、平均分、排名区间、成绩趋势；
• 班级层面：班级平均分、及格率、优秀率、分数段分布，班级与班级之间的横向对比；
• 课程层面：各门课程的平均分、难度差异、选课人数分布。

这三个层面正好对应小程序的三个核心页面，也对应后端Django要提供的三类接口。这种拆分方式的好处是：每个人都有数据可看，老师关心班级整体情况，学生关心自己的位置，功能职责非常清晰，答辩时也很好解释。

1.2 为什么是Django + 小程序，而不是别的组合

选型环节可能是被低估最多的一步，很多同学直接沿用别人的方案，但心里并不清楚为什么。我在这类项目里推荐的组合是 Django + 微信小程序 + Python数据分析三件套，理由有三个。

第一个理由是 Django 非常适合“数据后端”。它有自带 Django Admin 后台，数据录进去之后可以直接在后台管理，不用额外写一个管理前端。对于毕设来说，这能节省至少两天的前端开发工作量。另外 Django 的 ORM 写统计类查询时非常顺畅，比如按班级分组算平均分，用 annotate 加一个 Avg 就能搞定，代码量小、逻辑直观。

第二个理由是 Python 数据分析生态。pandas 负责清洗和聚合数据，matplotlib 负责生成统计图表，Django 只是把分析结果以接口形式暴露出去。这样你就可以把“数据分析”这个亮点真正落地，而不是只放一个表格。

第三个理由是微信小程序作为移动端的载体，对校园场景很合适。学生不用装独立App，扫码就能用，前端页面也轻量。加上小程序本身的 API（如 Canvas 绘图、图表组件）足够支撑数据展示需求。

当然这并不意味着这套方案没有缺点，后面我会把跨域、域名校验、图表适配这些坑也一并讲清楚。整体来说，它的收益远大于成本，特别适合一个人在一到两个月内完成从零到上线。

1.3 整体架构设计：一条数据是怎么跑通全链路的

架构层面我把它分成四层：数据源 → 后端分析 → API接口 → 小程序渲染。

数据源就是数据库里的原始表，最核心的是一张成绩表，关联学生表和课程表。Django 的 models 定义好之后，可以用自带的 migration 机制快速建表，也可以用脚本把 CSV 格式的模拟数据批量导入。

后端分析这层，要写一个专门的服务模块（比如分析工具类），它负责从数据库里取原始数据，用 pandas 做分组统计，算出平均分、及格率、分数段人数这类指标，再用 matplotlib 生成图表。图表有两种交付方式：一种是生成 PNG 图片，通过 URL 或 base64 返回前端；另一种是返回纯数值，前端用 ECharts 渲染。我后面会对比这两种方式的优缺点。

API 接口层用 Django REST Framework，也就是常说的 DRF，把分析结果序列化成 JSON。这里要注意设计好返回结构，让前端拿到数据后可以直接绑定，不需要再做二次加工。

小程序渲染层就是用户最终看到的界面，通过 wx.request 请求后端接口，拿到 JSON 后用数据绑定渲染页面，图表部分用 canvas 或者渲染图片的方式呈现。

四层链路跑通之后，整个项目的边界就非常清晰了。我见过不少同学把分析逻辑写在小程序端，后端只存数据，这是不合理的。数据分析的计算压力应该放在服务端，小程序只负责展示，否则真机上卡的还是用户的手机。

2. 后端Django的精髓：建模、统计接口与图表生成

2.1 先跑通工程骨架和基础配置

拿到项目建议先执行两条命令：django-admin startproject student_data创建工程，python manage.py startapp analysis创建分析应用。项目名用下划线，不要用中划线，否则后面 import 的时候会直接报错。然后记得在settings.py的INSTALLED_APPS里注册analysis和rest_framework，不注册后面迁移和接口路由全都不生效。

如果用的是 Django 5.x 配合 Python 3.11 以上版本，需要留意pymysql和mysqlclient的兼容性。我的建议是开发阶段直接用默认的 SQLite，足够支撑几千条以内的模拟数据；等要部署上线再切换 MySQL 也来得及。切换时只要改DATABASES配置，模型层代码不用动，这是 Django ORM 带来的最大优势。

2.2 数据模型怎么设计最省心

Django 的模型设计决定了后面所有分析逻辑的写法，先想清楚关联关系再动手，可以避免后期反复改表。

我给出的最简设计是三个模型：Student（学生）、Course（课程）、Score（成绩）。Student 包含学号、姓名、性别、班级、入学年份字段；Course 包含课程编号、课程名称、学分字段；Score 是关联表，包含学生外键、课程外键、成绩数值、学期、考试类型（比如期中/期末）。

代码大概是这样的：

from django.db import models class Student(models.Model): student_no = models.CharField(max_length=20, unique=True, verbose_name="学号") name = models.CharField(max_length=50, verbose_name="姓名") gender = models.CharField(max_length=10, choices=[("M", "男"), ("F", "女")], verbose_name="性别") class_name = models.CharField(max_length=50, verbose_name="班级") enroll_year = models.IntegerField(verbose_name="入学年份") class Meta: verbose_name = "学生" verbose_name_plural = verbose_name def __str__(self): return f"{self.student_no} - {self.name}" class Course(models.Model): code = models.CharField(max_length=20, unique=True, verbose_name="课程编号") name = models.CharField(max_length=50, verbose_name="课程名称") credit = models.FloatField(verbose_name="学分") def __str__(self): return self.name class Score(models.Model): student = models.ForeignKey(Student, on_delete=models.CASCADE, related_name="scores", verbose_name="学生") course = models.ForeignKey(Course, on_delete=models.CASCADE, related_name="scores", verbose_name="课程") score = models.FloatField(verbose_name="成绩") semester = models.CharField(max_length=20, verbose_name="学期") exam_type = models.CharField(max_length=20, default="期末", verbose_name="考试类型") class Meta: unique_together = ("student", "course", "semester", "exam_type") def __str__(self): return f"{self.student.name} {self.course.name} {self.score}"

三个细节值得注意。第一，Score 表一定要设置 unique_together 联合唯一约束，防止同一个学生在同一学期同一门课存在重复成绩，这个是数据质量的底线。第二，外键要用 related_name，这样反向查询会很顺手，比如拿到一个学生对象后直接 student.scores.all() 就能取出他所有成绩。第三，字段类型上成绩用 FloatField 而不是 IntegerField，因为后面可能算加权平均分，小数精度会很有用。

建好模型之后，执行 python manage.py makemigrations 和 python manage.py migrate 就能生成数据库表。默认的 SQLite 对毕设来说完全够用，没必要上 MySQL，除非你的导师明确要求。

2.3 模拟数据怎么造：直接写脚本或命令

模型建完，表是空的，分析无从谈起。我建议写一个 Django management command 来批量生成模拟数据，这样生成完随时可以清空重建，比手动在后台录数据高效一百倍。

操作方法是：在 app 的 management/commands 目录下新建一个 fill_data.py 文件，然后定义一个 Command 类，里面的 handle 方法负责生成数据。生成逻辑很简单：先造 30 名学生，分布在3个班级；再造 5 门课程；然后对每个学生、每门课程随机生成一个 40 到 100 之间的成绩，按两个学期分别生成。随机可以用 Python 的 random.uniform，生成后再 round 到一位小数。

这里我补充一个实操经验：模拟数据一定要“有规律、有差异”，而不是纯随机。比如让 A 班整体平均分偏高一些，B 班偏中，C 班偏低一些，这样后面做班级对比时，图表效果才明显，答辩演示的时候也更好讲。纯随机的数据画出来，所有柱子都差不多高，观感很差，也体现不出“分析”的价值。想让某班成绩偏高，造数时给这个班的随机分数加一个偏移量即可。

数据生成之后，还可以用 Django shell 里验证一下总记录数。实测填充 30 人 × 5 门课 × 2 学期 = 300 条成绩记录，已经足够支撑后续所有统计分析了。

2.4 数据分析逻辑：从“算数”到“找出结论”

数据分析模块是整个后端的核心亮点。我第一次做的时候，发现很多同学只知道把数据列出来，然后画个图，但图为什么要这么画、从图里能得出什么结论，完全说不出来。这里我给出一个非常实用的思路：所有分析指标都围绕“比较”和“分布”两个关键词。

“比较”指的是不同维度之间的对比，比如各班平均分对比、各课程平均分对比、同班两个学期的成绩变化。“分布”指的是成绩落在各个分数段的人数情况，比如不及格、60-69、70-79、80-89、90-100 的人数占比。围绕这两个关键词，后端需要输出以下几类核心指标：

• 总分、平均分、最高分、最低分、及格率、优秀率（优秀率通常按 90 分及以上计算）；
• 班级维度各科平均分的横向对比；
• 单科成绩分数段分布；
• 某个学生两个学期的成绩趋势对比。

用 Django ORM 写这些统计非常方便。比如统计各班级的平均分，核心代码是：

from django.db.models import Avg from analysis.models import Student class_scores = ( Student.objects.values("class_name") .annotate(avg_score=Avg("scores__score")) .order_by("class_name") )

这里的关键是 values("class_name").annotate() 实现的分组聚合，scores 是 Student 上通过 related_name 建立的反向关系。如果希望统计各班级的人数，还可以加一个 Count("scores__id") 来统计记录数。

分数段分布可以用 Case-When 或者 filter 参数来实现：

from django.db.models import Count, Q fail_count = Score.objects.filter(score__lt=60).count() good_count = Score.objects.filter(score__gte=90).count()

不过，如果分析逻辑变得更复杂，比如要做加权平均、百分位排名、多表宽表汇总，纯 ORM 写起来会非常绕。这种情况我建议把数据 load 到 pandas DataFrame 里统一处理，代码可读性好得多。

2.5 pandas 和 matplotlib 的引入时机

就这个项目来说，pandas 的主要作用是生成宽表和做复杂计算。比如要算每个学生在班级里的排名，可以先按班级分组，再用 rank 方法生成排名列。ORM 做这类操作会比较别扭，pandas 一行就解决了。

matplotlib 的作用是生成图表。这里有一个非常重要的方案选择：后端生成 PNG 图片返回前端，还是前端用 ECharts 自己画？

我两种都试过，总结一下利弊：

• 后端先生成图片，优点是代码简单、前端渲染压力小、学生对图片没法乱改，缺点是图片无法交互，也没有 Tooltip，且需要处理中文字体路径、高清图 DPI 等问题。
• 前端用 ECharts 渲染，优点是图表可以交互、缩放、提示，视觉效果好，答辩时观感更高级，缺点是需要引入组件库、协调接口返回的数据格式。

我最终的推荐是：如果时间紧，后端生成图片足够；如果想把项目做成精品，建议用前端 ECharts 方案。这个项目标题强调“数据分析”，答辩时图表的交互性是一个加分项，所以我更倾向于前后端配合，后端提供聚合后的数值接口，前端负责图表绘制。

2.6 DRF接口封装：让小程序拿到的数据直接用

接口层用 Django REST Framework。安装依赖后，在 settings 里注册 rest_framework，然后设计几个视图集。我建议按照小程序的页面需求来规划接口：

• /api/overview/ 返回整体概览：学生总数、课程数、平均分、及格率；
• /api/class-stats/ 返回各班级的平均分、人数、及格率，用于柱状图；
• /api/score-distribution/ 返回分数段分布，用于饼图或环图；
• /api/course-stats/ 返回各课程平均分；
• /api/student/ / 返回单个学生的成绩明细和趋势。

写视图时，最简单的方式是用 @api_view 装饰器加上函数视图，统计逻辑直接调用前面写的分析服务类，返回 Response(JSON)。也可以使用 DRF 的 ViewSet，配 ModelSerializer 做标准接口。考虑到这是一个面向小程序的接口服务，我建议统一使用 JSONRenderer，并在响应的最外层包一个统一的格式，比如：

{ "code": 0, "message": "success", "data": {...} }

前端拿到这个结构后，判断 code 是否为 0，然后取 data 渲染页面，错误处理会非常统一。这个习惯看起来很基础，但对于小程序这种多端环境非常关键，因为前端不可能像网页那样直接在浏览器控制台看到完整的异常输出。

写视图的时候还要注意，不要在每个接口里都粘贴一大段统计数据计算逻辑。正确做法是抽出一个 analysis_service.py 模块，把“统计+图表生成”的复杂函数都放进去，视图层只负责调用和返回。这样代码结构清晰，答辩被问“你的分析逻辑在哪一层”时也回答得上来。

3. 微信小程序端：从列表到图表的呈现

3.1 页面规划与目录结构

小程序端我规划了三个 Tab 页面：首页（数据概览）、分析（数据图表）、我的（个人信息或说明页），加一个学生列表详情页作为子页面。

页面目录大概是这样的：

pages/ index/ // 首页：展示整体指标卡片 analysis/ // 分析页：班级对比柱状图、分数段环形图 students/ // 学生列表：可点击进入个人详情 student-detail/ // 学生详情：个人成绩趋势

pages 配置在 app.json 里完成。这里有个容易踩的坑：小程序的 tabBar 页面必须是 app.json 中 pages 列表的前几个，且 tabBar 的图标是必需的。如果不想准备图标，也可以不设 tabBar，改用自定义首页的轮播或导航按钮来跳转。对毕设来说，三个 Tab 的方式最直观，评审打开小程序就知道项目有哪些功能。

我用过 uniapp 也用过原生小程序开发。如果只是做这个项目，原生小程序足够；如果以后想多端复用，可以用 uniapp 编译。但要注意，uniapp 里引用 canvas 图表库时，canvasId 的管理和原生开发不太一样，同一页面多个 canvas 容易冲突，建议一个页面只放一个图表，需要多个图表时用多个页面承载。

3.2 网络请求封装与数据绑定

小程序的 wx.request 是基础能力，但直接在每个页面里写 wx.request 会非常痛苦，因为回调嵌套一多代码就特别乱。我的习惯是在 utils/request.js 里封装一个 promise 风格的请求工具：

const BASE_URL = "http://127.0.0.1:8000/api"; function request(path, method = "GET", data = {}) { return new Promise((resolve, reject) => { wx.request({ url: `${BASE_URL}${path}`, method, data, header: { "Content-Type": "application/json" }, success: (res) => { if (res.data && res.data.code === 0) { resolve(res.data.data); } else { reject(res.data); } }, fail: reject, }); }); } module.exports = { request, BASE_URL };

页面里调用就非常清爽了：

const { request } = require("../../utils/request"); Page({ data: { overview: {}, }, onLoad() { request("/overview/").then((data) => { this.setData({ overview: data }); }); }, });

这里需要强调一个基础但致命的细节：小程序的 wx.request 在开发阶段必须在小程序开发者工具中勾选“不校验合法域名、web-view（业务域名）、TLS 版本以及 HTTPS 证书”，否则请求会直接报错。如果使用手机真机预览，那就必须在公众平台的“开发设置”里配置服务器域名，而且只支持 HTTPS。对本地调试来说，勾选“不校验”就可以正常运行。

3.3 图表方案：wx-charts 还是 ECharts？

小程序内画图表，目前主流方案有两个：wx-charts 和 echarts-for-weixin。

wx-charts 是一个轻量图表库，上手快，内置柱状图、折线图、饼图，API 风格和文档都比较简单，适合学习项目。缺点是交互能力弱，很多自定义配置支持不好。

echarts-for-weixin 是 ECharts 官方为小程序提供的适配方案，基于 Canvas 2D 渲染，可以支持绝大多数 Web 端 ECharts 配置。引入方式稍复杂一些，需要把 ec-canvas 组件放进项目，并在 Page 里初始化图表。不过演示效果好了不止一个档次，答辩时手指划过图表会有 Tooltip 提示，这视觉冲击力很强。

我个人建议用 echarts-for-weixin 作为主力图表方案。下面是一个典型的柱状图初始化代码：

import * as echarts from "../../ec-canvas/echarts"; function initChart(canvas, width, height, dpr) { const chart = echarts.init(canvas, null, { width, height, devicePixelRatio: dpr }); canvas.setChart(chart); chart.setOption({ xAxis: { type: "category", data: ["A班", "B班", "C班"] }, yAxis: { type: "value", min: 0 }, series: [ { type: "bar", data: [82.5, 75.2, 68.9], itemStyle: { color: "#4f8ff7" }, }, ], }); return chart; }

这里的 dpr 参数很关键，真机上如果不设置 devicePixelRatio，图表会显示模糊。很多同学遇到“图表发虚”的问题，就是这个原因。实际调用时，页面里需要一个 canvas 标签并绑定 ec 组件事件。

3.4 学生个人详情页：趋势线与数据洞察

个人详情页是这个小程序里比较能体现“数据分析”精髓的地方。不只是展示这个学生考了多少分，而是要展示连续两个学期各科成绩的对比趋势，以及他的各科成绩在班级中的相对位置。比如显示一条折线图：横轴是课程，纵轴是分数，分别画大二上学期和大二下学期的线，两条线一对比，立马上一个档次。

后端接口需要返回学生各学期的成绩字典。前端拿到后，把两个学期的数据分别转成数组，传给 ECharts 的 series 即可。这里要注意空数据显示的处理，比如某个学生某门课没有成绩，接口返回 None，前端要过滤掉，否则图表会断线。可以在后端就统一处理成 0 或者 null，建议处理成 null，这样 ECharts 会自动跳过空值点连接前后数据。

4. 联调实战与高频问题排查

4.1 前后端联调的基本流程

前后端开发完成后，联调是绕不开的一步。完整的流程是：先启动 Django 开发服务器，确认接口用浏览器访问能看到 JSON；再打开微信开发者工具，在项目配置里修改 BASE_URL 指向你的开发机 IP 或 localhost；然后运行小程序逐个页面测试接口是否正常返回，如果报错就打开 Console 面板看具体错误信息。

我强烈建议在联调阶段就用 Wi-Fi 下局域网 IP（比如 http://192.168.1.101:8000）而不是 localhost。因为微信开发者工具模拟器虽然可以访问本地 localhost，但如果你用手机真机预览，localhost 指向的是手机自己，根本连不上你的电脑。真机调试时，使用电脑的局域网 IP 才能通。

4.2 跨域问题：Django 端需要配置什么

这里要分清楚一个关键点：小程序的 wx.request 不受浏览器同源策略限制，所以小程序开发时一般不需要处理 CORS。但你如果用浏览器直接访问 Django 接口，或者网页端也接同一个后端，那 CORS 就躲不掉了。

处理方式是在 Django 里安装 django-cors-headers，然后把需要的域名加到配置里：

INSTALLED_APPS = [ ... "corsheaders", ] MIDDLEWARE = [ "corsheaders.middleware.CorsMiddleware", ... ] CORS_ORIGIN_ALLOW_ALL = True # 开发阶段可以放开，上线再收紧

如果接口是给微信小程序专用，这一步可以省掉，但为了保险我还是会加上。因为评审老师可能自己在浏览器里打开接口地址验证，如果弹出 CORS 报错，体验会很差。

4.3 matplotlib 中文乱码与图片清晰度

后端生成图片方案里，最大的坑是 matplotlib 中文字体。默认字体不支持中文，你在柱状图上写“班级平均分”，会看到一堆方框。解决方案是显式指定支持中文的字体。Windows 下常见的是 SimHei 或 Microsoft YaHei，也可以把字体文件放到项目目录里统一管理：

import matplotlib matplotlib.use("Agg") import matplotlib.pyplot as plt plt.rcParams["font.sans-serif"] = ["SimHei"] plt.rcParams["axes.unicode_minus"] = False

第二行关闭 Unicode 负号显示，是为了避免负号显示成方块。这个设置必须放在所有绘图代码之前，而且要多次确认生效。另外保存图片时，建议设置 dpi=150 以上，同时用 bbox_inches="tight" 裁剪空白，否则图表四周会有大片留白，在小程序里的显示效果很懒散。

4.4 小程序真机预览的几类怪问题

真机预览出现的问题通常比模拟器多，我遇到过的典型场景有三个。

第一个是 network request failed，多半是服务器没启动、IP 不对或者域名没备案。排查顺序：先确认 Django 服务进程活着，再确认手机和电脑在同一局域网，再确认防火墙允许 8000 端口。Windows 防火墙经常拦截开发服务器的端口，测试时可以在防火墙规则里临时放行 python 进程。

第二个是图表空白或加载不出来，先看 Console 是否有 ec-canvas 相关报错。常见原因是未在 Page 的数据里配置 canvasId，或者 Canvas 高度为 0，导致图表渲染区域不可见。需要给 canvas 标签显式设置宽度和高度。

第三个是 setData 渲染过慢导致卡顿。因为小程序的 setData 每次都是全量更新视图层，如果你把一个很大的列表一次性绑到界面上，真机就会卡顿。解决办法是分页加载或使用 observer 组件按需渲染。

4.5 常见问题速查

我把高频问题整理成一个速查表，方便对照排查。

5. 从毕设到实用：扩展与经验复盘

5.1 三个值得做的扩展方向

这个项目做完后如果还有精力，或者想让答辩更有亮点，我建议往三个方向扩展。

第一个方向是增加预测能力，比如基于历史成绩用 scikit-learn 做一个简单的线性回归，预测学生下次考试的成绩区间。这个扩展可以直接把项目从“统计展示”提升到“分析与预测”，在数据分析类毕设中属于典型加分项。后端新增一个接口，前端在首页加一个“成绩预测”入口即可。

第二个方向是图表维度的丰富，加入雷达图展示学生多维能力（各科成绩对比），加入热力图展示各班级各科的表现强弱，这些视觉形式比普通柱状图、饼图更容易让人记住。

第三个方向是引入用户角色权限。目前系统是所有人看所有数据，不太符合真实场景。可以给 Django 引入一个简单的登录机制，老师账号看班级汇总，学生账号看个人详情。移动端可以结合微信登录手机号授权流程，小程序端通过 wx.login 获取用户身份，服务端签发 token，之后每个请求带上 token 标识角色。这一步能显著增加项目完整度。

5.2 时间规划建议

我在接手这种项目时会给学生一个课时建议：需求拆解与实际调研 5 到 7 天，Django 建模和接口开发 10 天，小程序页面与图表开发 7 天，联调与修复 bug 5 天，写论文和准备答辩 5 天。总计大概 30 个工作日。如果时间紧张，可以先用后端生成图片的方案顶上，后续再替换成 ECharts，功能迭代的优先级不能乱。

5.3 踩坑总结：哪些教训最值钱

最后把我在实际开发和辅导项目过程中踩过最深的几个坑拎出来说一遍。

第一，不要高估 Django Admin 的作用。毕设演示时，很多同学喜欢打开 Admin 后台给老师看数据录入功能，但 Admin 的默认界面非常简陋，如果不做样式优化，观感不会太好。我通常建议 Admin 只当作内部管理工具，对外展示重心放在小程序端。

第二，一定要重视数据造数的合理性。成绩全是 80 分以上，图表会丧失分析感；成绩全部集中在 60-70，又显得没有区分度。造数据时先用 Excel 或脚本预览一眼统计指标，确认分布合理再写代码。

第三，Django 的 DEBUG=True 在开发阶段很好用，能看到详细异常，但联调真机时如果把服务端日志打满，就很难定位问题。我一般会在项目的日志配置里单独分文件记录 Django 请求日志，避免和浏览器控制台信息混在一起。

这个项目真正值得花心思的地方，不在“会不会 Django”或者“会不会小程序”，而是当你拿到一个真实场景时，能不能把数据链路完整跑通，并用可视化的方式把结论讲清楚。只要统计口径定义到位、数据结构设计合理，后面的展示层工作都是在做填空题。答辩那天，把班级对比、分数段分布、个人趋势这几张图放出来，说清楚每个指标怎么算的、为什么这样算，就已经赢过大多数做成“学生信息管理”的同类项目了。