简介：图像分类是计算机视觉的基础任务之一，其核心在于利用卷积神经网络自动提取图像中的空间特征，并映射到语义标签。随着深度学习技术的成熟，模型不仅要具备高精度，还需通过Web服务实现工程化落地。Django作为成熟的Python Web框架，能够将训练好的模型封装为REST API，支撑图片上传、推理调用与结果展示，形成从数据标注到业务展示的完整链路。这一技术组合在智慧校园场景中具有典型应用价值，例如课堂学生行为识别，可自动分析学生听讲、玩手机、睡觉等状态，辅助教学管理。本文围绕该场景，系统讲解了CNN模型选型、训练调优、Django服务化部署、异步任务优化及生产环境搭建等关键环节，为开发者提供一套可复用的深度学习工程实践方案。

技术栈与架构设计：这套系统到底是怎么跑起来的

拿到这个题目的时候，我第一反应是又有人要做课堂行为分析了。这个方向其实在计算机视觉领域火了好几年了，从最早的传统图像处理到现在的深度学习方案，技术迭代了好几轮，但核心思路一直没变：把摄像头采集到的课堂画面交给模型去推理，自动判断画面里的学生是在认真听课、低头玩手机、趴在桌上睡觉，还是举手发言、和同学交头接耳。

这套系统的技术选型其实很有代表性。深度学习负责视觉识别这一块，Django负责把模型能力封装成Web服务，两者加起来就是一个完整的B/S架构应用。如果单独看深度学习部分，本质就是一个图像分类任务，输入是每一帧图像里的学生区域，输出是该学生当前的行为类别；而Django部分要解决的则是怎么把模型加载到后端、怎么接收前端上传的图片或视频流、怎么把识别结果持久化到数据库，最后通过Web页面展示给老师或教务管理人员。

从项目结构上讲，这套系统大致分成了几个模块：

1. 数据层：标注好的学生行为图片数据集，包含训练集和测试集。
2. 模型层：基于CNN类的深度学习模型，负责提取图像特征并完成分类。
3. 服务层：Django编写的REST API，处理图片上传、模型调用、结果返回。
4. 展示层：管理后台和前端页面，用于查看识别记录、统计结果、可视化展示。

这个分工基本覆盖了“数据标注—模型训练—服务部署—业务展示”的完整链路，也是目前做此类课题最标准的套路。如果你是自己做毕业设计或者课程项目，直接照这个思路拆解文档，整个项目的脉络一下就清楚了。

---

深度学习模型的核心细节：CNN和注意力机制怎么选

既然系统名字叫“基于深度学习的上课学生行为识别”，那模型部分自然是绝对的重头戏。这里我先说结论： 绝大多数学生行为识别系统走的路线都是CNN来做图像分类，或者CNN+序列模型来做视频行为识别 。

如果只是识别单张静态图片，那本质上就是图像分类任务。比如判断一个学生是“认真听讲”“玩手机”“趴在桌子上”还是“举手”，每一类都对应一个标签，模型训练的过程就是让网络学会从像素到语义标签的映射。这种情况下，常用的骨干网络有ResNet、MobileNet、EfficientNet这类经典分类网络，它们的区别主要体现在精度和计算量的权衡上。

如果是做视频流实时识别，那就要用到时序信息了。因为单帧图像有时候会出歧义，比如学生低着头可能是在看书也可能是在玩手机，但如果看连续几帧的画面，大概率就能判断出来。这种场景常用的方案是使用双流网络（空间流+时间流）或使用SlowFast这类视频理解网络，再或者用CNN提取特征后用LSTM来建模时序关系。不过考虑到训练成本和推理速度，很多实际项目用的是折中方案：每隔几帧取一帧关键帧，用CNN识别帧中的学生行为，再用平滑策略把相邻帧的结果做融合，相当于用后处理逻辑模拟时序建模。

再来说说池化这件事。CNN里的池化层虽然有多个变体，核心作用就是下采样，把特征图的尺寸缩小，同时保留最重要的激活信息。最常用的是最大池化（Max Pooling）和平均池化（Average Pooling）。在行为识别任务里，我个人倾向于使用全局平均池化（Global Average Pooling）接在全连接层之前，它能直接把整个特征图压成一个特征向量，降低过拟合风险，也方便后面接分类器。 很多初学者容易忽略一个细节：池化不是越多越好，一旦下采样过猛，小目标（比如画面里远处的学生）的细节信息会直接丢失，识别准确率会断崖式下降。

我当时在做数据集测试的时候还发现一个问题：同一个学生，坐在第一排和坐在最后一排，实际框出来的像素尺寸差异非常大。如果模型只针对近距离样本训练，远距离基本全部误判。这个场景下的解决办法有两种：

• 数据增强阶段做多尺度训练（Random Resized Crop），让模型对不同尺寸的目标都具备一定的适应能力。
• 检测阶段先做人脸或人体检测，把目标区域裁剪出来，再送入分类模型。因为裁剪后的目标大小基本一致，分类器只需要关注目标区域内的特征。

实际项目里，第二种方法更稳。毕竟行为识别面向的是整个教室场景，直接端到端分类容易受背景干扰。更合理的技术路线是“目标检测 + 目标分类 + 时序平滑”三层结构。目标检测负责框出每个学生，分类网络负责判断框内行为，最后用滑窗投票的方式稳定输出。

---

环境准备：模型训练和Django服务部署要准备哪些东西

在真正动手之前，环境这块得先理顺。这个项目牵扯两套环境：一套是模型训练环境，一套是Django运行环境。这两者不一定必须在同一台机器上，但一定要提前规划好。

模型训练一般要求有GPU，因为CNN的训练若只在CPU上跑，哪怕一个小的ResNet18，跑几十个epoch也够你等到怀疑人生。我建议用一张NVIDIA显卡，至少8GB显存起步。显存大小决定了batch size的上限，batch size又直接影响收敛速度和最终精度，这个关系很多新手第一次做项目时容易忽略。

操作系统方面，Windows和Linux都行。Ubuntu装深度学习环境确实坑比较多，尤其是显卡驱动和CUDA版本匹配问题。我自己遇到最多的情况就是：系统装好NVIDIA驱动之后，执行nvidia-smi一点问题没有，但一跑PyTorch就报错说CUDA不可用。排查到最后往往是PyTorch版本、CUDA toolkit版本和驱动版本三者之间不兼容。这里给你一个比较稳的组合，如果不知道选什么版本就直接抄作业：

• Python 3.8或3.10
• CUDA 11.8
• cuDNN 8.6
• PyTorch 1.13.1或2.0.1
• torchvision 0.14.1或0.15.1

如果不想被本地环境折腾，也可以直接用Autodl这类云GPU平台。它们的好处是环境镜像已经预先装好了主流深度学习框架，租一台4090的机器，半小时之内就能开始训练，按小时计费，对项目周期短、只需要验证实验结果的场景非常划算。

Django环境就简单多了，它本身就是纯Python的Web框架，对硬件没有要求。安装方式直接pip install django就行，需要确认的两件事是Python版本和Django版本。Django 2.2以上版本目前都支持Python 3.6以上的环境，但为了省心，建议直接用Python 3.10 + Django 4.2组合，这个组合在社区里踩坑的人少，遇到的坑也大多有现成的解决方案。

对了，如果你之后要把项目部署到服务器上，最好提前用虚拟环境把依赖锁一份完整的requirements.txt。训练环境和部署环境的依赖版本不一致，非常容易导致模型推理结果和训练时的结果不一致，而且这种偏差特别难排查。

---

模型的训练流程与关键参数：怎么把准确率调到能用的水平

这套系统里，深度学习模型是最核心的，所以模型训练这部分要重点说。一张图像进入神经网络之后，卷积层提取的空间特征会经过池化、归一化、激活函数等处理，最终在全连接层被映射成每个行为类别的概率分布。损失函数最常用的是交叉熵损失（CrossEntropyLoss），优化器常用Adam或SGD带动量。Adam收敛快、对学习率不敏感，初学用它比较容易出效果；SGD训练出来的模型泛化性能通常更好，但需要手动调整学习率策略，训练周期也要更长。

我的建议是先用Adam跑通流程，确认数据没问题、loss能正常下降，再用SGD+CosineAnnealingLR做一次精细训练，这样可以兼顾开发效率和最终精度。

训练轮次（epoch）的话，50到100轮是比较常见的设置。很多同学会踩一个误区，喜欢把epoch设置到几百甚至上千轮，然后发现一个典型问题：训练集上的准确率持续上升，验证集却一直在原地踏步。这就是过拟合的信号。遇到这种情况，我的经验是优先检查数据集本身是否存在数据泄露，比如同一个学生的多张图片被同时划入了训练集和验证集，模型相当于直接记答案；然后再看模型是否太大、数据增强是否太少，最后再决定要不要加Dropout或权重衰减。

数据增强这块，我强烈建议要加到位。 上课场景下，学生的姿态变化、光线变化、遮挡情况都很复杂。像我之前做的一组实验，仅仅加了随机水平翻转和随机亮度扰动，准确率就有两三个点的提升。如果再加入RandomErasing、Cutout这类模拟遮挡的数据增强方式，对遮挡情况的鲁棒性会有明显改善。

行为类别定义也需要提前想清楚。有些项目把行为分得特别细，比如“记笔记”、“翻书”、“看黑板”都算单独一类，但这种细粒度分类对标注质量和数据量的要求极高，单类别样本不够时模型很容易互混。更合理的做法是合并成大类别，比如“认真听讲（看黑板/看书/记笔记）”“做小动作（玩手机/东张西望/交头接耳）”“睡觉（趴在桌上/闭眼）”这样组合，实际效果会好很多。

训练完成后一定要看混淆矩阵，而不要只看总体准确率。我遇到过一种情况，总体准确率到了90%以上，看似不错，打开混淆矩阵发现“玩手机”这个类别的召回率只有60%，大量样本都被误判成了“听讲”。原因是玩手机时手部区域的视觉特征变化太大，和低头看书的姿态又接近，模型学到的最优策略就是直接把这个类别忽略掉。这种坑不看混淆矩阵完全发现不了。

---

Django项目架构与核心代码实现：模型怎么被部署成Web服务

模型训练好了只是第一步，真正让这个系统能被使用，得靠Django把它封装成Web服务。Django本身是一个重量级框架，自带ORM、Admin后台、模板引擎、认证系统等一整套组件。用它做算法服务的好处就是这些基础设施都给你准备好了，你要做的只是把模型推理的逻辑融进去。

我建议的Django项目结构大概是这样的：

student_behavior_system/
├── manage.py
├── requirements.txt
├── behavior_app/
│   ├── models.py
│   ├── views.py
│   ├── urls.py
│   ├── services/
│   │   ├── recognition.py
│   │   └── model_loader.py
│   └── migrations/
├── static/
│   ├── css/
│   ├── js/
│   └── uploads/
├── media/
│   └── images/
└── templates/
    ├── index.html
    └── result.html

这里有个关键设计： 模型加载和业务逻辑分开。 在Django菜鸟教程中第一个跑的Hello World，基本都是在views.py里直接写业务逻辑，但放到机器学习项目里，如果每次请求都去加载模型，系统会直接卡死。正确做法是写一个model_loader模块，在Django启动时把模型加载进全局变量，后续请求只需要复用这个已经加载好的模型实例即可。

# behavior_app/services/model_loader.py
import torch
from torchvision import models, transforms

_model = None

def get_model():
    global _model
    if _model is None:
        _model = models.resnet18(num_classes=6)
        _model.load_state_dict(torch.load("models/resnet18_behavior.pth", map_location="cpu"))
        _model.eval()
    return _model

def preprocess(image):
    transform = transforms.Compose([
        transforms.Resize((224, 224)),
        transforms.ToTensor(),
        transforms.Normalize([0.485, 0.456, 0.406], [0.229, 0.224, 0.225])
    ])
    return transform(image).unsqueeze(0)

views.py里调用这个模型时，只需要调用get_model()拿模型实例，然后把图片预处理之后丢进去推理就行。 需要注意，模型服务化的一个核心差异是推理模式必须设置为eval() ，因为训练模式下Dropout和BatchNorm的行为和推理模式完全不同，直接用训练模式推理会导致结果随机波动，这种问题在代码里特别隐蔽。

# behavior_app/views.py
import torch
from django.shortcuts import render
from django.http import JsonResponse
from .services.model_loader import get_model, preprocess

CLASS_NAMES = ["认真听讲", "举手发言", "睡觉", "玩手机", "低头写字", "站立"]

def recognize_view(request):
    if request.method == "POST":
        image_file = request.FILES.get("image")
        if not image_file:
            return JsonResponse({"error": "未上传图片"}, status=400)
        image = Image.open(image_file).convert("RGB")
        tensor = preprocess(image)
        with torch.no_grad():
            logits = get_model()(tensor)
            probs = torch.softmax(logits, dim=1)
            conf, idx = torch.max(probs, dim=1)
            label = CLASS_NAMES[idx.item()]
            confidence = conf.item()
        return JsonResponse({"label": label, "confidence": round(confidence, 4)})
    return render(request, "index.html")

数据库模型部分，可以设计一张BehaviorRecord表，用来记录每一次识别的结果：

# behavior_app/models.py
from django.db import models

class BehaviorRecord(models.Model):
    image = models.ImageField(upload_to="uploads/")
    label = models.CharField(max_length=50)
    confidence = models.FloatField()
    created_at = models.DateTimeField(auto_now_add=True)

数据库这里我建议先用Django默认的SQLite，等系统规模上来了再切换到MySQL/PostgreSQL。SQLite对单机部署的毕设或小场景系统完全够用，开箱即用、零配置，而且Django对SQLite的支持一直很稳定。

---

前端页面与可视化：识别结果怎么展示才直观

前端这块如果只是做后台管理，Django自带的Admin就能应付。但如果你想做一个给老师直接用的界面，那还是得自己写几个页面。这里我建议用一个相对简洁的方案：原生HTML + Bootstrap + jQuery，不需要引入Vue或React这种重型前端框架。因为行为识别系统的核心交互很简单——上传图片、查看结果、浏览历史记录，用不上复杂的前端状态管理。

首页可以做成上传交互：

<form id="uploadForm" enctype="multipart/form-data">
    {% csrf_token %}
    <div class="upload-area">
        <input type="file" name="image" accept="image/*" required>
    </div>
    <button type="submit">开始识别</button>
</form>
<div id="result"></div>

<script>
$("#uploadForm").on("submit", function (e) {
    e.preventDefault();
    var formData = new FormData(this);
    $.ajax({
        url: "/recognize/",
        type: "POST",
        data: formData,
        processData: false,
        contentType: false,
        success: function (res) {
            $("#result").html(
                "<h3>识别结果: " + res.label + "</h3>" +
                "<p>置信度: " + res.confidence + "</p>"
            );
        }
    });
});
</script>

这个交互足够简单直接，老师上传一张课堂照片，系统返回识别结果和置信度。

如果你希望系统看起来更高级，可以把识别结果做成统计报表的形式。比如用ECharts画一个饼图，展示当前照片里各种行为类别的占比，或者用折线图展示一段时间内的课堂专注度变化趋势。ECharts的社区案例很多，接入也简单，引入js文件后直接按文档写配置项就行。

前端展示这块有一个小建议： 置信度要展示，但同时也要给一个可信任度分级标注。 比如置信度在90%以上显示绿色“可靠”，70%-90%显示橙色“参考”，低于70%显示红色“需人工确认”。因为自动识别系统总有误判的可能，让使用者知道哪些结果是可信的、哪些结果需要复核，比单纯给一个冷冰冰的百分比要实用得多。

还有一个点容易被忽略：上传图片后最好直接把图片显示在页面上，把检测框和标签画上去。如果你用了目标检测模型，那输出就不只是类别标签，而是一组框坐标。Django后端可以通过PIL的ImageDraw在图片上画框并把结果保存，前端展示画好框的图片。这样老师一眼就能看出每个学生被识别成了什么行为，而不是看一串文字结果。

---

性能优化与并发策略：多用户同时上传时怎么办

校园环境里最可能的并发场景是：多个老师同时登录系统上传课堂照片，或者一个老师上传了一段视频，系统需要逐帧处理。这种情况如果处理不好，Django服务会直接被阻塞，表现在用户体验上就是页面一直转圈、请求超时。

模型推理本身是CPU密集（如果GPU推理则是GPU密集）操作，处理一张图片大约需要几十到几百毫秒，处理一段视频里的几百帧图片就不是几秒能解决的了。如果这些操作全部放在同步的views里，Django的worker进程会被占满，新的请求就排不上队。

几种成熟的优化策略：

第一种是 异步任务队列 。把模型推理任务扔到Celery + Redis队列里，views里只负责接收任务、返回任务ID，前端再通过轮询或WebSocket查询任务状态。这样用户上传视频后可以关闭页面，等处理完成后再查看结果。这个方案功能最完整，但增加了系统复杂度，部署环境里要多维护Redis和Celery worker。

第二种是 进程内队列 。用Python标准库的queue模块，配合后台线程处理任务，再搭配一个简单的任务状态表。实现起来比Celery简单很多，适合中小型系统的并发需求。

第三种是 多进程部署 。用Gunicorn或uWSGI启动多个Django worker，每个worker内部加载一份模型副本。这样同一时刻可以并行处理多个推理请求，但缺点是内存占用会随着worker数线性增长。一个ResNet18模型在内存中大约占几十MB，启动4个worker就是几百MB，一般服务器都能承受。

我在实际项目中比较推荐第二种方案。简单，稳定，维护成本低。核心逻辑是：把推理任务放入队列，后台线程消费队列并更新任务状态。

import queue
import threading
from .services.model_loader import model_inference

task_queue = queue.Queue()
task_results = {}

def worker():
    while True:
        task_id, image_path = task_queue.get()
        try:
            result = model_inference(image_path)
            task_results[task_id] = {"status": "done", "result": result}
        except Exception as e:
            task_results[task_id] = {"status": "error", "error": str(e)}
        finally:
            task_queue.task_done()

threading.Thread(target=worker, daemon=True).start()

views里提交任务时直接把task_id返回给前端：

def async_recognize(request):
    task_id = str(uuid.uuid4())
    task_queue.put((task_id, image_path))
    return JsonResponse({"task_id": task_id})

def task_status(request, task_id):
    result = task_results.get(task_id)
    if result:
        return JsonResponse(result)
    return JsonResponse({"status": "processing"})

前端只需要每两三秒轮询一次任务状态，拿到结果后就展示。这个方案实现简单，对Django的侵入性也小，是整个项目里性价比最高的一块优化。

---

模型训练与系统集成时的坑：这些错误我当年都踩过

做这个项目时，我印象最深的一个问题是： 模型单独测试时准确率很高，但集成到Django里之后，识别结果出现了大量错误。 当时我排查了半天，最后发现原因让人哭笑不得——数据预处理对不上。训练时用的是PyTorch的transforms，包含Resize到(224,224)、ToTensor、Normalize三步。但Django项目里为了图省事，我直接用OpenCV读图，然后调用训练好的模型，完全跳过了Normalize这一步，而且OpenCV读出来的是BGR通道顺序，和PyTorch的RGB通道顺序不一致。两张图的输入分布完全不对，模型预测出来的结果自然是一团糟。

这个问题在各大数据科学社区里被讨论过很多次，属于比较典型的封装阶段失误。解决方式很简单： 训练和推理过程必须共享同一套预处理流程。 我的做法是把数据预处理逻辑整合成独立模块，训练时和部署时都调用这一个模块，不搞两套逻辑。

另一个我踩过的坑是 路径硬编码 。训练脚本里写死了本地路径，比如 /home/ubuntu/data/classroom_images/train ，结果代码拿到新环境后直接报FileNotFoundError。后来我强制要求自己在项目里统一使用 pathlib.Path 来构建路径，并且把数据目录、模型目录、日志目录等全部提取到配置文件里，不做硬编码。

还有一类问题跟模型文件大小有关。训练好的PyTorch模型权重文件，如果是ResNet50这种中等规模的网络，通常有100MB左右。Django部署时如果把这些权重文件直接塞进Git仓库，文件会变得非常臃肿，clone和部署都慢。更好的做法是权重文件单独存放，或者用Git LFS管理大文件，代码仓库里只保留下载脚本。

模型量化这块也值得考虑一下。训练时用的是FP32精度，但推理阶段可以转成int8量化，模型体积能缩小到原来的四分之一左右，推理速度也有显著提升。如果你的部署环境CPU性能一般，量化是一个性价比很高的优化方向。不过量化后精度可能会有轻微损失，建议量化前后都跑一遍同一批测试集，对比一下准确率变化，如果掉点超过1个百分点，就建议保留FP32模型。

---

数据库设计与查询技巧：识别记录怎么管理才高效

Django的ORM做得相当成熟，这个项目的数据库设计也不需要太复杂，核心就是一张行为记录表。但为了后续扩展方便，我会在表结构设计上多做一点考虑。

比如，如果系统支撑的是一次性识别一张照片，那行为记录表可以设计成上面提到的那样，一条记录对应一次识别结果。但如果要做课堂整体统计分析，就需要把“识别批次”这个概念加进来。可以设计两张表：一张Session表，保存一次识别会话的信息（比如上传时间、图片数量、教师ID）；一张BehaviorRecord表，每条记录关联一个Session。这样就能很方便地统计“某一次课堂里各类行为的占比”或者“某个班级连续几周的行为趋势”。

class Session(models.Model):
    description = models.CharField(max_length=200, blank=True)
    created_at = models.DateTimeField(auto_now_add=True)

class BehaviorRecord(models.Model):
    session = models.ForeignKey(Session, on_delete=models.CASCADE, related_name="records")
    image = models.ImageField(upload_to="uploads/")
    label = models.CharField(max_length=50)
    confidence = models.FloatField()
    created_at = models.DateTimeField(auto_now_add=True)

查询方面，Django ORM提供了很多实用的方法。比如要统计某一次Session里每个行为类别的数量，只需一行：

from django.db.models import Count

record_counts = BehaviorRecord.objects.filter(session_id=1).values("label").annotate(count=Count("id"))

如果要删除某个Session下的所有历史记录，注意Django的CASCADE外键级联删除机制会自动把这个Session关联的所有BehaviorRecord一并清空，不会留下孤儿数据。 执行删除的时候有一个容易出错的地方：如果记录条数很大，直接调用delete()方法虽然简单，但如果你希望保留操作日志，或者需要先把数据备份到文件再删，那就要在删除前先做好数据导出，否则删错了数据是找不回来的。

除了基础的增删改查，Django还提供了一些更高级的查询功能，比如按时间范围筛选，或者按置信度阈值筛选。这些操作在后台管理里使用频率很高，熟练运用Django的ORM真的能大幅提升开发效率。

---

系统部署与上线：从开发环境到生产环境的几道坎

Django项目从开发环境跑到生产环境，要做的迁移工作比很多人想象的多。开发时用的runserver服务器自带自动重载功能，方便调试，但它是一个单进程开发服务器，性能和稳定性都无法支撑生产环境的并发要求。生产环境部署一般用Gunicorn或者uWSGI作为Django的WSGI服务器，Nginx负责反向代理和静态文件服务。

部署架构大致是这样：

浏览器 → Nginx → Gunicorn (Django) → MySQL/PostgreSQL

Nginx直接面对用户请求，把动态请求转发给Gunicorn，把静态文件直接返回，这样能减轻Django应用服务器的压力。静态文件包括CSS、JS、图片等，Django开发模式下能自动处理，但生产环境必须用collectstatic命令收集到指定目录，再由Nginx配置alias指向这个目录。

我在Ubuntu上部署的时候，整体流程大概是这样的：

1. 安装Python虚拟环境和依赖：python3 -m venv venv，然后source venv/bin/activate，再pip install -r requirements.txt
2. 安装Nginx和Gunicorn
3. 修改Django配置文件，把DEBUG设为False，配置ALLOWED_HOSTS为服务器IP或域名，配置STATIC_ROOT和MEDIA_ROOT
4. 执行python manage.py collectstatic收集静态文件
5. 执行python manage.py migrate初始化数据库（如果用的是SQLite，这一步会创建数据库文件）
6. 用Gunicorn启动Django服务：gunicorn student_behavior_system.wsgi:application -b 127.0.0.1:8000
7. 配置Nginx，把80端口请求转发给127.0.0.1:8000，并配置静态文件的映射
8. 设置systemd服务，让Gunicorn在系统重启后自动拉起

还有一个很容易被忽略的配置是 CSRF_TRUSTED_ORIGINS 。如果Django部署在HTTPS域名下，不配置这个参数，所有POST请求都会因为CSRF校验失败而无法提交。这个报错在本地开发时不会出现，只有部署到线上之后才会遇到，而且报错信息比较隐蔽，第一次遇到可能根本不会往这个方向排查。

我的建议是， 部署前先在本地把SECRET_KEY改成环境变量读取，把数据库连接、模型路径等全部通过环境变量或配置文件管理。 这样在服务器上部署时，只需要修改环境变量，不需要改动任何代码。这个习惯看起来微不足道，但在你真正需要把项目从一台机器迁移到另一台机器的时候，能省下大量踩坑的时间。

---

常见问题排查与调试技巧：十个最典型的报错场景

开发过程中会遇到很多让人头疼的报错，我整理了一份排查清单，这些都是在实际处理类似项目时反复出现的典型问题：

问题场景	可能原因	排查思路
Django启动时报ModuleNotFoundError	缺少依赖包	检查requirements.txt是否完整，用pip list核对
执行迁移时报No migrations to apply	迁移文件与数据库状态不一致	删掉数据库和migrations记录重新执行migrate
上传图片时提示文件过大	请求体超过Django默认限制	Django的DATA_UPLOAD_MAX_MEMORY_SIZE参数调大
模型推理时报shape mismatch	输入尺寸或通道数和模型预期不一致	打印模型输入输出的shape，检查预处理参数
识别结果一直是一个类别	模型训练过拟合或类别分布不均	查看混淆矩阵，检查测试集是否包含各类别的样本
前端页面加载很慢	静态文件没有被Nginx代理	检查Nginx静态文件配置，确认collectstatic执行过
同步请求导致页面卡顿	模型推理占满了worker	改用异步队列方案，限制推理并发数
远程服务器访问不了网站	安全组或防火墙没放行端口	检查云控制台安全组规则，确认端口已开放
数据库迁移报字段冲突	模型改动后未更新迁移文件	执行makemigrations重新生成迁移文件
视频上传后一直显示处理中	后台任务线程被kill或崩溃	查看Django日志，确认异常信息

这里我想特别提一下 模型类别映射错乱 这个坑。如果训练时类别的索引顺序是 {"听讲": 0, "玩手机": 1, "睡觉": 2} ，但Django代码里用的是 ["听讲", "睡觉", "玩手机"] ，那么模型预测出索引1时，系统会把它显示成“睡觉”，但模型真正识别的是“玩手机”。这种问题在项目调试阶段尤其容易发生，因为模型文件、代码、文档在多人协作或版本迭代过程中很容易出现不一致。

我的解决方法是：把类别映射表单独放在配置文件里，模型训练时和Django加载时都读取同一份配置，不复制两份映射表。同时，在启动Django时打印一遍类别映射，方便在日志里确认。

---

效果评估与优化空间：准确率还能不能往上提

最后一个话题聊聊效果评估。行为识别系统的评估不能只靠准确率一个指标，更合理的评估维度包括：

• 准确率 ：所有预测中预测正确的比例。
• 召回率 ：某一类别的样本中，被正确识别出来的比例。比如“睡觉”行为，如果模型经常把睡觉误判成“低头”，那“睡觉”这个类别的召回率就低。
• F1-Score ：准确率和召回率的调和平均，类别不均衡时比准确率更可靠。
• 单帧推理延迟 ：模型对单张图片的处理时间。这个指标直接关系到系统能否支撑实时识别场景。

如果发现模型在某个类别上表现特别差，可以考虑从这几个方向去优化：

1. 增加该类别的训练样本数量。现实中“睡觉”样本可能远远少于“听讲”样本，需要在数据采集阶段做平衡。
2. 针对困难样本做数据增强，特别是模拟教室环境下的光照变化、遮挡情况。
3. 尝试更强的骨干网络。ResNet18换成ResNet50或者EfficientNet-B3，准确率通常会有提升，但推理速度会下降，需要结合部署环境做取舍。
4. 使用Focal Loss替代交叉熵损失。Focal Loss可以降低易分类样本的权重，让模型更关注难分类的样本，对类别不均衡问题有一定缓解效果。

如果项目时间充裕，还可以尝试引入时空注意力机制。之前有一段时间我在调研课堂行为识别方向时，留意到几篇CVPR上关于视频动作识别的论文里提出了一个很有意思的方向：检测学生的人体关键点来辅助行为判断。比如“举手”这个行为，从姿态特征上识别比从图像特征上识别要容易得多，因为它的姿态模式非常明确——手臂抬起超过肩膀。如果把姿态估计网络和分类网络的特征融合起来，对一些姿态特征明显的行为，准确率能有明显提升。

不过引入姿态估计会增加系统的复杂度和推理时间，是否值得去做，取决于你的应用场景。如果识别目标只有听讲、玩手机、睡觉这三类，用传统的CNN分类模型就能解决，不需要太多的额外模块；但如果你希望对“举手”“起立”这类动作类行为做细粒度识别，姿态信息就很有价值了。

我觉得从毕设或者课程设计的角度来说，当前这套“目标检测+CNN分类+Django服务”的组合方案已经足够完整，既能体现深度学习的技术深度，又能借助Django展现实战项目的工程能力。整套系统从数据到训练到部署的链路全部打通，是一个标准且实用的学习项目模板。如果你后续想在这个项目基础上继续迭代，我建议把精力优先投向数据质量的提升和模型的轻量化部署这两个方向，这两个方向带来的收益最直接。

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