企业官网建设流程全解析

这个项目并不是什么宏大工程，它源于一个特别具体的问题：县里每年都要组织农业技术培训，但靠电话通知、线下集中授课的模式，越来越跑不动了。

乡镇学员分布散、农忙时间不固定、讲师来回跑成本高，一场培训经常到场人数不到通知的一半。于是就有了这个基于Python和Django搭建的“某县农业技术在线培训平台”——本质是一个面向乡村场景的轻量在线教学系统。它能承载视频课程、文档资料、在线考核、学习进度追踪，也兼容手机浏览器访问，让学员在地里干活休息的空档，也能掏出手机把一节课程看完。

这套系统的技术栈不复杂：Python 3.10 + Django 4.2 + MySQL + Nginx + Gunicorn，前端用服务端渲染加少量JavaScript。但真正把一个“看起来不难”的Django项目做到能在基层环境稳定跑起来，里面还是有不少值得记录的门道。下面我把整个项目从需求拆解到部署上线的过程完整写出来，给要做类似在线教育、培训类系统的朋友一个参考。

1. 需求倒推技术选型：为什么这种系统选Django最省心

1.1 先想清楚谁会打开这个系统

做任何系统之前，先把用户画像摸清楚。这个培训平台的使用者分为三类，需求差异非常明显：

这里面最要紧的是“学员用手机访问”。乡下的网络状况参差不齐，手机型号跨度很大，不能默认每个学员都有最新款智能手机和稳定宽带。所以前端页面必须轻，避免引入重型框架，保持服务端渲染的兼容性。

1.2 为什么不是前后端分离，也不上微服务

技术选型那阵子，我身边有朋友推荐用Vue + Django REST Framework做前后端分离，理由是“以后扩展方便”。但对于这个项目来说，前后端分离是个伪需求。

前后端分离的好处是交互体验好、前后端并行开发，代价是至少多一层Node构建流程、多一套接口联调工作，部署时还得处理跨域和静态资源托管。对于一个只有几千名学员、业务逻辑以“课程—学习—考核—统计”为主线的平台，Django自带的模板引擎完全够用。而且模板渲染天然对SEO友好，页面首屏快，开发效率也高。

微服务就更不必要了。业务规模没到那个量级，强行拆分只会增加运维复杂度。一个Django项目加一个MySQL实例，部署在一台4核8G的云服务器上，初期完全够用，单机架构排查问题还方便。

1.3 框架选型上的几个现实考量

选Django而不是Flask或FastAPI，主要是这几点：

• 自带Admin后台：Django内置的admin管理界面能极大降低讲师录入课程的负担，稍微配置一下list_display、search_fields就能直接交付，不用从零写管理端。
• 用户认证体系完整：Django自带的User模型和auth模块覆盖了登录、登出、权限分组、密码重置等常规需求，不需要自己实现用户系统。
• ORM成熟稳定：农业培训系统涉及大量数据筛选，比如按村、按乡镇查学习记录，用Django ORM写起来很直观，生成的SQL性能也能接受。
• 迁移机制方便迭代：后续每次加字段、改表结构，跑一遍makemigrations和migrate就能同步到生产库，对单人开发来说省了太多事。

提示：版本建议直接用Django 4.2 LTS，长期支持版本，安全更新能持续到2026年左右。Python用3.10或3.11，别用最新的Python 3.12或3.13，部分第三方库的二进制包可能还没跟上。

2. 数据模型设计：核心就是“人—课—进度”三件套

2.1 用户模型怎么扩：别直接改Profile字段

Django自带的User模型有username、password、email这些基础字段，但培训系统需要记录学员的所属乡镇、村组、身份角色，还有讲师和管理员的区分。常见的做法有两种：一是继承AbstractUser重写User模型，二是用OneToOneField扩展用户档案。

我这次选择了第一种方式，因为项目一开始就确定不要换用户模型，扩展字段和业务绑定紧密，直接在项目初始化阶段就用自定义User模型，后续迁移更省心。

# users/models.py from django.contrib.auth.models import AbstractUser from django.db import models class User(AbstractUser): ROLE_CHOICES = ( ('student', '学员'), ('teacher', '讲师'), ('admin', '管理员'), ) role = models.CharField(max_length=16, choices=ROLE_CHOICES, default='student', verbose_name='角色') region = models.CharField(max_length=64, blank=True, verbose_name='所属乡镇/村') phone = models.CharField(max_length=20, blank=True, verbose_name='手机号') id_card = models.CharField(max_length=18, blank=True, verbose_name='身份证号') created_at = models.DateTimeField(auto_now_add=True, verbose_name='注册时间') class Meta: verbose_name = '用户' verbose_name_plural = '用户'

这里有个很实用的细节：为每个角色建一个分组，但不强制用Django的Group表，而是直接靠role字段区分。因为业务逻辑里判断角色只需要一个if user.role == 'teacher'，比查权限表轻量得多。Django的Group和Permission机制留给后期需要细粒度权限时再用。

2.2 课程、章节、资料：逻辑分层要清晰

课程结构我从一开始就定成“培训计划—课程—章节”三层，而不是扁平的一堆课程列表。原因是乡村培训系统天然有批次概念：比如“2025年春季果树修剪培训班”，下面有若干门课程，每门课程里又有几个视频章节。

# courses/models.py class TrainingPlan(models.Model): name = models.CharField(max_length=128, verbose_name='培训计划名称') start_date = models.DateField(verbose_name='开始日期') end_date = models.DateField(verbose_name='结束日期') description = models.TextField(blank=True, verbose_name='计划说明') is_active = models.BooleanField(default=True, verbose_name='是否启用') class Course(models.Model): plan = models.ForeignKey(TrainingPlan, on_delete=models.CASCADE, related_name='courses', verbose_name='所属培训计划') title = models.CharField(max_length=128, verbose_name='课程名称') teacher = models.ForeignKey(settings.AUTH_USER_MODEL, on_delete=models.SET_NULL, null=True, related_name='courses', verbose_name='授课讲师') cover = models.ImageField(upload_to='covers/', blank=True, verbose_name='封面图') created_at = models.DateTimeField(auto_now_add=True, verbose_name='创建时间') class Lesson(models.Model): course = models.ForeignKey(Course, on_delete=models.CASCADE, related_name='lessons', verbose_name='所属课程') title = models.CharField(max_length=128, verbose_name='章节标题') video_url = models.URLField(blank=True, verbose_name='视频地址') attachment = models.FileField(upload_to='attachments/', blank=True, verbose_name='附件资料') order = models.PositiveIntegerField(default=0, verbose_name='排序') duration = models.PositiveIntegerField(default=0, verbose_name='视频时长/秒')

很多初学者容易忽略order字段。没有它，删除一个章节后再添加章节，顺序就会乱套。加上order字段，查询时用order_by('order')就能稳定排序。

注意：视频文件先不要自己存本地。早期我们试过把视频直接传到Django的MEDIA_ROOT，后来发现服务器带宽和存储都是大麻烦。一个1080P的课程视频随便就是几百MB，一台8G内存的服务器兼做文件服务器，很快就吃不消。后面改成传对象存储或者直接把视频托管到第三方视频平台，Django只存一个video_url字段，省了太多事。

2.3 学习进度和考核：用一张记录表解决所有统计问题

学习记录是整个系统的数据核心。每次学员打开一个章节，前端就向后端发一条上报请求，后端记录“学到了哪里、看了多久、是否完成”。这样管理员随时能查出“某某乡镇有多少人完成了春季培训”。

# records/models.py class LearningRecord(models.Model): user = models.ForeignKey(settings.AUTH_USER_MODEL, on_delete=models.CASCADE, related_name='learning_records', verbose_name='学员') lesson = models.ForeignKey(Lesson, on_delete=models.CASCADE, related_name='learning_records', verbose_name='章节') watch_seconds = models.PositiveIntegerField(default=0, verbose_name='已观看时长/秒') is_completed = models.BooleanField(default=False, verbose_name='是否完成') last_position = models.PositiveIntegerField(default=0, verbose_name='最后播放位置/秒') updated_at = models.DateTimeField(auto_now=True, verbose_name='更新时间') class Meta: unique_together = ('user', 'lesson') class ExamResult(models.Model): user = models.ForeignKey(settings.AUTH_USER_MODEL, on_delete=models.CASCADE, verbose_name='学员') course = models.ForeignKey(Course, on_delete=models.CASCADE, verbose_name='课程') score = models.FloatField(verbose_name='考试得分') passed = models.BooleanField(default=False, verbose_name='是否合格') submitted_at = models.DateTimeField(auto_now_add=True, verbose_name='提交时间')

LearningRecord表加了unique_together('user', 'lesson')，保证同一个学员对同一章节只会有一条进度记录。更新进度时直接update_or_create，既避免重复数据，代码也简洁。

一张记录表，再配合Django的聚合查询，就能满足绝大多数统计需求：完成人数、平均学时、各村完成率，一条ORM语句的事。

3. 核心功能模块实现：模板渲染为主，接口为辅

3.1 用户注册登录：Django自带认证的“半定制”改造

登录功能直接用Django的LoginView，省掉手写表单校验和session管理的麻烦。但培训平台的学员注册有个特殊需求——需要管理员预绑定，比如导入某乡镇学员名单后，学员凭身份证号和初始密码登录。这就不能做成完全开放注册。

# users/views.py from django.contrib.auth.views import LoginView, LogoutView class CustomLoginView(LoginView): template_name = 'users/login.html' redirect_authenticated_user = True def get_success_url(self): user = self.request.user if user.role == 'student': return reverse('courses:student_home') elif user.role == 'teacher': return reverse('courses:teacher_dashboard') return reverse('admin:index')

这里有个坑：redirect_authenticated_user = True虽然在用户已登录时会直接跳过登录页，但如果你没有定义get_success_url，它会默认跳到Django的LOGIN_REDIRECT_URL。不同角色的跳转目标不同，必须自己重写这个方法。

注册方面，我们用的是“名单导入+首登改密”模式：管理员在后台按模板Excel导入学员名单（姓名、身份证号、手机号、所属村组），系统自动生成用户名和初始密码，学员首次登录后强制修改密码。这就绕开了手机验证码这类在乡村场景下经常收不到短信的麻烦。

3.2 课程列表和学习页：ListAPI + 详情页的组合

课程首页要让学员一眼看到当前正在进行的培训计划和每门课的完成状态。Django的ListView配合annotate就能把“每门课总章节数、已完成章节数”一并算出来。

# courses/views.py from django.views.generic import ListView from django.db.models import Count, Q class CourseListView(ListView): template_name = 'courses/course_list.html' context_object_name = 'courses' paginate_by = 12 def get_queryset(self): plan = TrainingPlan.objects.filter(is_active=True).first() courses = Course.objects.filter(plan=plan) user = self.request.user for course in courses: total_lessons = course.lessons.count() completed_lessons = LearningRecord.objects.filter( user=user, lesson__course=course, is_completed=True ).count() course.progress = int(completed_lessons / total_lessons * 100) if total_lessons else 0 return courses

直接在get_queryset里循环查数据库，数据量小的时候没问题。如果课程数量涨上来，建议改成annotate + Count加条件聚合，一条SQL搞定，但初期这样写最简单直接，业务跑起来以后再做性能优化也不迟。

3.3 学习进度上报：一个轻量POST接口

前端播放页嵌入了一个简易的HTML5视频播放器，每隔15秒向后端上报当前播放位置。之所以用接口而不是表单提交，是为了让上报动作变成异步的，不影响视频播放。

# records/views.py import json from django.http import JsonResponse from django.views.decorators.http import require_POST from django.contrib.auth.decorators import login_required @require_POST @login_required def report_progress(request): data = json.loads(request.body) lesson_id = data.get('lesson_id') position = int(data.get('position', 0)) watch_seconds = int(data.get('watch_seconds', 0)) duration = int(data.get('duration', 0)) try: lesson = Lesson.objects.get(id=lesson_id) except Lesson.DoesNotExist: return JsonResponse({'code': 1, 'msg': '章节不存在'}) record, created = LearningRecord.objects.update_or_create( user=request.user, lesson=lesson, defaults={ 'last_position': position, 'watch_seconds': watch_seconds, } ) # 如果观看时长超过视频时长的85%，判定为完成 if duration > 0 and watch_seconds >= duration * 0.85: record.is_completed = True record.save() return JsonResponse({'code': 0, 'msg': 'ok'})

判断完成的标准是“观看时长超过视频时长的85%”，这是故意的。不让学员拖动进度条到底就算完成，也不要求100%看完——85%既保证有效学习，又容忍了网络卡顿导致的最后几秒没播完的情况。

前端用一个简单的setInterval每15秒调用一次这个接口，同时把参数localStorage存一份，避免切换页面导致进度丢失：

// schoolrecord.js let lastReported = 0; video.addEventListener('timeupdate', function () { const pos = Math.floor(video.currentTime); const dur = Math.floor(video.duration); if (pos - lastReported >= 15) { lastReported = pos; fetch('/records/report/', { method: 'POST', headers: { 'Content-Type': 'application/json', 'X-CSRFToken': getCookie('csrftoken') }, body: JSON.stringify({ lesson_id: LESSON_ID, position: pos, watch_seconds: pos, duration: dur }) }).catch(e => { // 上报失败先存本地，下次打开再补报 localStorage.setItem('pending_report_' + LESSON_ID, JSON.stringify({ position: pos, watch_seconds: pos })); }); } });

提示：fetch请求里的X-CSRFToken一定要加上，否则Django的CSRF中间件会直接返回403。getCookie函数可以放在全局公共JS里，网上有很多现成写法，这里不再贴完整代码。

3.4 权限控制：装饰器和Mixin的混合使用

Django的权限体系很好用，但默认的login_required只解决了“登录了没有”，解决不了“登录了但角色不对”。我给不同角色写了独立的入口判断：

# common/decorators.py from functools import wraps from django.core.exceptions import PermissionDenied def role_required(roles): def decorator(view_func): @wraps(view_func) def _wrapped(request, *args, **kwargs): if not request.user.is_authenticated: return redirect('users:login') if request.user.role not in roles: raise PermissionDenied return view_func(request, *args, **kwargs) return _wrapped return decorator @role_required(['teacher', 'admin']) def course_create(request): ...

视图函数用装饰器，类视图用UserPassesTestMixin或自定义LoginRequiredMixin，两种风格统一起来用即可。注意一点：PermissionDenied异常要在settings里配一个403的模板，否则默认页面太难看，也不友好。

4. 踩坑实录：从SQLite换到MySQL，从页面白屏到强制刷新

4.1 第一个坑：SQLite不背锅，但乡村场景并发真的会写锁

Django项目默认数据库是SQLite，开发时跑起来特别爽，零配置、免维护。前期学员量小，也没人刻意做压力测试，直到有一次集中培训报名，某村网格员在同一时间帮二十多个学员批量注册，SQLite直接报database is locked。

SQLite对“单写入者”的支持是有保障的，但它不支持并发写。多个请求同时写入时，后面的请求会等待，等待超时就直接报错。培训系统里相关写入场景其实挺多：上报进度、提交考核、批量导入用户，任何一个请求密集的节点都可能把SQLite点爆。

解决方案不复杂——换MySQL。在项目初期就换，代价极低；等项目跑起来数据多了再换，光迁移数据就够折腾的。

# settings.py 数据库配置片段 DATABASES = { 'default': { 'ENGINE': 'django.db.backends.mysql', 'NAME': 'training_db', 'USER': 'training_user', 'PASSWORD': 'your_password_here', 'HOST': '127.0.0.1', 'PORT': '3306', 'OPTIONS': { 'charset': 'utf8mb4', }, 'CONN_MAX_AGE': 60, } }

CONN_MAX_AGE = 60意思是数据库连接在60秒内复用，避免每个请求都重新建连接。这个参数在高并发时能显著减少握手开销，但要注意MySQL的wait_timeout默认是8小时，如果连接空闲超过MySQL的超时阈值，Django会复用失效连接报错。Django 4.1+已经内置了连接健康检查，配合CONN_MAX_AGE就基本不需要额外处理。

4.2 第二个坑：数据库字符集没配好，用户名直接变问号

学员姓名里带生僻字的，导入进去之后页面上显示一串问号。这问题几乎每个做中文应用的人都会遇到，根源是库、表、连接三个层面的字符集不一致。

MySQL安装时默认编码可能是latin1，也可能是utf8mb3（就是utf8），但utf8mb3存不下emoji和部分生僻字。正确做法是建库时指定utf8mb4：

CREATE DATABASE training_db DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;

Django连接时再指定charset='utf8mb4'，双保险。库建好之后再改编码很麻烦，建议项目初始化时就确认。

除了数据库层面的编码问题，Django的settings里也要设置FILE_CHARSET和DEFAULT_CHARSET（默认就是utf-8，一般不用动）。比较隐蔽的是Excel导入用户名单时，如果Excel文件本身是GBK编码，用pandas读取时没指定encoding='gbk'，中文全部变成乱码入库。这个坑我踩了两次才记住：pandas读取Excel默认会把字符串列按单元格类型推断，字符串里若有中文，编码在原文件里就可能已经乱了，最稳妥的流程是先转到CSV再逐行清洗。

4.3 第三个坑：admin站点里ImageField和FileField的MEDIA路径

Django的admin虽然强大，但文件上传的路径配置很容易被新手忽略。settings.py里如果没有配置MEDIA_URL和MEDIA_ROOT，上传的文件会跑到项目根目录，而且在admin列表里点击链接无法查看图片。

MEDIA_URL = '/media/' MEDIA_ROOT = BASE_DIR / 'media'

主urls.py里还要加一句：

from django.conf import settings from django.conf.urls.static import static urlpatterns = [ ... ] + static(settings.MEDIA_URL, document_root=settings.MEDIA_ROOT)

这句只会在DEBUG=True时生效，生产环境下Nginx会直接托管/media/路径。如果在生产环境忘记配置Nginx的location，上传的文件能存但访问不了，页面就是一片空。当时排查这个问题花了一下午。

4.4 第四个坑：前端页面缓存导致更新后学员仍看到旧课程

Django模板渲染默认不会做浏览器缓存控制，但如果你用Nginx做反向代理，没配置add_header Cache-Control的话，Nginx的默认行为会让浏览器对静态资源做很激进的缓存。结果就是讲师在后台更新了课程封面，学员刷新页面还是旧图。

Nginx配置加一行即可：

location /static/ { alias /path/to/static/; expires 7d; add_header Cache-Control "public, max-age=604800, immutable"; } location /media/ { alias /path/to/media/; expires 1h; add_header Cache-Control "public, max-age=3600"; }

静态文件可以缓存7天，media文件（课程图片、附件）缓存1小时。这样既保证性能，又不会让学员长期看不到更新内容。

4.5 第五个坑：手机端页面宽度没处理，布局直接乱

很多讲师喜欢在后台把课程简介写一大段文字，学员在手机上打开，如果没有viewport meta标签，页面会以PC宽度渲染，字小得看不清，布局全乱，需要手动缩放才能阅读。

解决方式很简单，base.html里加一行：

<meta name="viewport" content="width=device-width, initial-scale=1.0">

同时所有CSS建议直接用rem而不是px做字体单位。用rem的一个好处是，老款手机或者视力不好的学员可以自己在系统设置里调大字体，页面布局不会被撑破。这个细节对乡村用户特别重要，他们有相当比例是老年人，默认字体偏小的话根本没法看。

5. 部署和优化：一台4G服务器也能跑得稳

5.1 部署方案：Gunicorn + Nginx 就够了

我用的是腾讯云轻量服务器，4核4G，CentOS系统。部署方式选的是Gunicorn + Nginx的组合。没选uWSGI因为它配置复杂、踩坑成本高；没选Daphne因为它面向ASGI，我们的项目是纯WSGI。

Gunicorn的配置要点是worker数。4核服务器，建议worker数 = 2 * CPU核心数 + 1，也就是9个。但考虑到项目内存占用和MySQL也要内存，我实际配了5个worker，每个worker处理一个请求。内存有限时，宁可减少worker数也要保证每个worker稳定，worker太多反而会因为内存交换把系统拖垮。

# gunicorn启动脚本示例 gunicorn config.wsgi:application \ --workers 5 \ --threads 2 \ --bind 127.0.0.1:8000 \ --timeout 60 \ --max-requests 1000 \ --access-logfile /var/log/training/gunicorn_access.log \ --error-logfile /var/log/training/gunicorn_error.log

--max-requests 1000的作用是每个worker处理1000个请求后自动重启，这样即使有内存泄漏，也会周期性释放，不至于跑几天就OOM。这是实际运维中一个很有用的“防呆”参数。

Nginx这边主要做静态文件托管和反向代理，配置不复杂，但有几个细节别忘了：client_max_body_size要调大，否则学员提交考核时如果带了图片附件会直接413；proxy_read_timeout也要适当加大，防止视频进度上报这类接口偶尔处理慢时被Nginx提前掐断。

server { listen 80; server_name your_domain; client_max_body_size 20m; location /static/ { alias /var/www/training/static/; expires 7d; } location /media/ { alias /var/www/training/media/; expires 1h; } location / { proxy_pass http://127.0.0.1:8000; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_read_timeout 60s; } }

5.2 安全加固：DDos防御做不了，但基础安全必须有

基层项目不太会招来专业黑客，但不设防等于裸奔。以下几个环节是必须做的：

• settings.py里DEBUG设为False，并在ALLOWED_HOSTS里把自己域名加上，否则会有Host头攻击风险。
• 给admin路径改成一个不规则的URL，比如/admin/改成/manage-panel/，能挡掉绝大多数扫描器的自动探测。
• 数据库密码不要用弱密码，至少16位混合字符。
• 定期执行collectstatic，并且把静态文件目录放在与项目代码分离的路径下，避免源码泄露。
• Django版本保持更新，订阅GitHub的Release通知，安全修复第一时间跟进。

注意：HTTPS是必要的，但现在申请SSL证书很便宜甚至免费，直接通过云厂商的免费证书功能搞定即可。部署HTTP/2能明显改善移动端加载速度。

5.3 性能优化：从“够用”到“好用”

系统跑通后，下一步要考虑体验。这个项目做过的几项优化值得记录：

数据库索引。学习进度上报接口频繁按user和lesson查询，这两个字段的联合索引建好之后，查询耗时从平均80ms降到5ms以内，效果立竿见影。

class LearningRecord(models.Model): ... class Meta: indexes = [ models.Index(fields=['user', 'lesson']), ]

静态文件压缩。项目里的CSS和JS文件加起来有好几百KB，Nginx开启gzip后能压到原来的四分之一，移动端加载速度提升非常明显。

gzip on; gzip_types text/css application/javascript application/json image/svg+xml; gzip_min_length 1k;

慢请求日志。给Django加上django-axes（防暴力破解）和简易的慢查询日志，定期看Nginx的access.log里哪些接口响应时间超过500ms，有针对性地优化。有一次就发现Excel导入接口因为同步处理耗时太长，改成异步任务后体验才顺畅起来。

5.4 数据备份：这是很多人会忽视的致命环节

用Django的dumpdata命令做逻辑备份很容易，但对这种有大量学习记录数据的系统，推荐用物理备份：

mysqldump -u training_user -p training_db > /backup/training_db_$(date +%F).sql

每天凌晨3点执行一次，保留最近30天的备份文件，再用rsync同步到另一台存储服务器。我吃了没备份的亏，有一次服务器磁盘故障，数据库直接跑不起来了，靠备份才救了回来。那之后我再也没有心存侥幸过。

另外记得定期清理media目录里失效的附件和视频，不然存储空间会被无用文件慢慢占满。写一个定时任务，扫描attachment字段对应的文件，超过一定时间的过期培训资料自动归档到冷存储。

6. 项目复盘：这套系统的扩展空间比你想的大

乡村在线培训平台上线后，实际使用效果超出了预期。第一批试点有12个乡镇，约4000名学员注册，每周活跃率保持在60%左右。但更重要的是，这个项目验证了一件事：技术选型不追求时髦，贴合实际场景和团队能力才是关键。

系统后续的扩展方向，我从项目规划的角度简单分享几个：

• 考核证书打印：培训合格后自动生成电子证书，后台支持批量导出PDF，方便乡镇统计学时。
• 数据大屏：接入一个大屏展示页面，实时显示各乡镇的参训人数、完成率、热门课程排行，对汇报工作有实际价值。
• 微信小程序端：H5在微信里打开已经能实现大部分功能，但小程序的消息订阅提醒、订阅号模板消息推送，对提升学员粘性帮助很大。
• AI问答助手：在课程详情页挂一个基于课程资料的智能问答，学员看完视频后可以直接问问题，比翻讲稿高效得多。

从我个人的实际感受来说，这类项目最需要注意的不是技术本身，而是对“用户到底怎么用”的预判。做乡村场景的项目，永远不要假设用户有流畅的4G网络、有最新款手机、有足够耐心去研究复杂的交互。简洁、稳定、低门槛，比炫技重要一百倍。

如果你现在正打算做类似培训系统，我的建议是：先用Django的admin把课程管理跑起来，再花一周时间把学员端的学习页面打磨到好用的程度，最后再考虑报表、证书这些锦上添花的功能。不要贪多，先跑通核心闭环，再慢慢加料。