Django影评社区开发实战：从数据建模到生产部署全记录

算起来，我做了不少Python Web项目，但真正让我觉得“入门到进阶”分水岭明显的，还是这个电影深度解读与影评社区网站。前后大概花了三周业余时间，从需求梳理到数据库设计，再到功能实现和最后部署上线，整个流程走完，对Django的理解完全不一样了。这套东西我一直在本地保留着，最近整理代码时觉得值得拿出来聊聊。

这个项目表面上看是一个带评分、评论、排行功能的电影信息站，但骨子里它是一个标准的社区型Web应用。用户注册登录、内容发布、互动评论、内容分类筛选、后台管理、搜索排序，这些互联网产品的基础能力全都有。用它来练手或者作为作品集项目，覆盖面非常广。尤其是如果你正处在“学完Python语法但不知道能做什么”的阶段，或者准备找Python后端相关岗位，这类项目是性价比极高的实践样本。

这篇文章我打算从架构设计、数据建模、核心功能实现到部署上线，把整个项目的关键决策和踩坑过程都过一遍。会贴一些关键代码，也会讲清楚每个设计背后的理由——当初我自己看教程时最烦的就是只给代码不讲为什么，这里咱们说得透一点。

1. 项目整体设计与思路拆解

1.1 为什么选Django而不是Flask或FastAPI

先回答很多人会问的第一个问题：做一个影评社区，用Flask不是更轻量吗？

从个人经验讲，Flask确实适合微服务和接口服务，但做内容型社区网站，Django的“全家桶”优势太明显了。你需要用户认证，Django自带auth模块；你需要后台管理，Django自带admin；你需要ORM操作数据库，Django的models层足够成熟。这些功能如果用Flask，你得自己集成Flask-Login、Flask-Admin、SQLAlchemy，选型成本和学习成本都上去了。

更关键的一点是Django自带的Admin后台对这个项目太友好。影评社区必然需要管理员审核内容、管理用户、维护电影信息，Django Admin几乎是零成本就能给你一个能用的运营后台。对个人开发者或者小团队来说，这就省掉了一大块后台开发时间。

1.2 核心功能模块划分

我按照社区网站的通用结构，把整个站点拆成了四个大块：

第一块是内容展示。包含电影列表页、电影详情页、影评详情页、深度解读专题页。这块是门面，用户进来先看内容，所以展示层的体验必须做好。

第二块是用户系统。注册、登录、个人主页、用户发布的影评列表。这里直接用Django自带的User模型扩展出一个Profile模型，存头像和个性签名。

第三块是互动系统。影评的点赞、收藏、评论，以及电影的评分。这些是社区氛围的保障，也是数据库设计里外键关系最密集的部分。

第四块是后台管理。用Django Admin定制出来的运营后台，管理电影信息、审核影评、管理用户、查看举报。

这四个模块互相独立又相互关联，正好把Django的MTV架构发挥到极致。

1.3 技术方案选型的几个关键考虑

数据库选了MySQL而不是SQLite。很多人开发时图省事用SQLite，但影评社区的数据模型里关系查询特别多，SQLite在高并发下的表现和并发控制能力都不行。MySQL配合Django的ORM，性能和数据一致性都更可靠。

前端没有上前后端分离框架，用的是Django模板加少量JavaScript。原因很直接：这个项目核心是服务端渲染，要兼顾SEO，影评和电影详情页如果全靠前端渲染，搜索引擎根本抓不到内容。Django模板配合Bootstrap做样式，再用jQuery发几个AJAX请求处理点赞和评论，完全够用，还省去了跨域和接口鉴权的麻烦。

还有一个容易忽略的点就是Python版本。项目用的是Python 3.10 + Django 4.2 LTS。Django 4.2是长期支持版本，安全更新周期长，功能也稳定。生产环境最怕就是用了非LTS版本，半年一升级，烦死。

2. 核心功能模块设计与数据建模

2.1 数据模型设计

影评社区的核心是内容，内容的核心是电影和评论。我设计了六个相互关联的数据模型，下面是关键代码：

from django.db import models from django.contrib.auth.models import User from django.urls import reverse from django.utils import timezone class Genre(models.Model): """电影分类""" name = models.CharField(max_length=50, unique=True, verbose_name="分类名") slug = models.SlugField(max_length=100, unique=True, verbose_name="URL标识") class Meta: verbose_name = "电影分类" verbose_name_plural = verbose_name def __str__(self): return self.name class Film(models.Model): """电影基本信息""" title = models.CharField(max_length=200, verbose_name="电影名称") original_title = models.CharField(max_length=200, blank=True, verbose_name="原名") cover = models.ImageField(upload_to="films/covers/", blank=True, null=True, verbose_name="封面图") genres = models.ManyToManyField(Genre, related_name="films", verbose_name="分类") director = models.CharField(max_length=100, verbose_name="导演") cast = models.TextField(blank=True, verbose_name="主演阵容") release_date = models.DateField(null=True, blank=True, verbose_name="上映日期") region = models.CharField(max_length=50, blank=True, verbose_name="制片地区") language = models.CharField(max_length=50, blank=True, verbose_name="语言") duration = models.PositiveIntegerField(default=0, verbose_name="片长(分钟)") summary = models.TextField(verbose_name="剧情简介") trailer_url = models.URLField(blank=True, verbose_name="预告片链接") average_rating = models.DecimalField(max_digits=3, decimal_places=1, default=0.0, verbose_name="平均评分") rating_count = models.PositiveIntegerField(default=0, verbose_name="评分人数") is_published = models.BooleanField(default=False, verbose_name="是否发布") created_at = models.DateTimeField(auto_now_add=True, verbose_name="创建时间") updated_at = models.DateTimeField(auto_now=True, verbose_name="更新时间") class Meta: verbose_name = "电影" verbose_name_plural = verbose_name ordering = ["-created_at"] indexes = [ models.Index(fields=["-average_rating"]), models.Index(fields=["title"]), ] def __str__(self): return self.title def get_absolute_url(self): return reverse("films:film_detail", args=[self.pk])

这里有两个设计值得单独讲。第一个是average_rating字段直接冗余存储在Film表中。为什么不通过评分表聚合查询实时算？因为列表页要按评分排序，如果每条电影都实时聚合几百条评分记录，数据库压力非常大。用冗余字段，每次用户评分时更新一次即可，读性能好得多。

第二个是slug字段。分类和电影详情页的URL为了SEO友好，都应该用语义化标识而不是纯数字主键。分类用slug没问题，但电影详情我最终还是用了主键——因为电影名同名情况太多，直接用title做slug会撞车。折中方案是URL里带主键：/films/123/，清晰且没有冲突问题。

2.2 影评与深度解读模型

影评社区和普通电影网站的区别就在影评这块。我设计了Review模型，同时承担“短评”和“深度解读”两种内容形态：

class Review(models.Model): """影评/深度解读""" REVIEW_TYPE_CHOICES = ( ("review", "短评"), ("deep", "深度解读"), ) film = models.ForeignKey(Film, on_delete=models.CASCADE, related_name="reviews", verbose_name="电影") author = models.ForeignKey(User, on_delete=models.CASCADE, related_name="reviews", verbose_name="作者") title = models.CharField(max_length=200, verbose_name="标题") content = models.TextField(verbose_name="正文") content_type = models.CharField(max_length=10, choices=REVIEW_TYPE_CHOICES, default="review", verbose_name="内容类型") rating = models.PositiveSmallIntegerField(default=0, verbose_name="评分(0-10)") is_featured = models.BooleanField(default=False, verbose_name="首页推荐") is_approved = models.BooleanField(default=False, verbose_name="审核通过") view_count = models.PositiveIntegerField(default=0, verbose_name="浏览量") created_at = models.DateTimeField(auto_now_add=True, verbose_name="创建时间") updated_at = models.DateTimeField(auto_now=True, verbose_name="更新时间") class Meta: verbose_name = "影评" verbose_name_plural = verbose_name ordering = ["-created_at"] indexes = [ models.Index(fields=["-created_at"]), models.Index(fields=["film", "-created_at"]), ] def __str__(self): return self.title

content_type这个字段就是“深度解读”功能的实现核心。review类型是短评，三五百字，用户看完电影随手写；deep类型是长文解读，可以从导演风格、镜头语言、主题隐喻多个维度展开。列表页会区分两种类型展示，深度解读还支持专题聚合。

is_featured字段用来做首页推荐位，管理员在后台勾选后，文章会出现在首页焦点图区域。is_approved是内容审核开关，新发布的影评默认不展示，管理员审核通过后才会在前台显示——这个机制防止了垃圾内容直接对外暴露，对内容型社区非常必要。

2.3 用户评分与评论互动

电影评分和评论是社区的灵魂。评分模型做了一层约束：

class Rating(models.Model): user = models.ForeignKey(User, on_delete=models.CASCADE, related_name="ratings", verbose_name="用户") film = models.ForeignKey(Film, on_delete=models.CASCADE, related_name="ratings", verbose_name="电影") score = models.PositiveSmallIntegerField(verbose_name="评分(1-10)") created_at = models.DateTimeField(auto_now_add=True) class Meta: unique_together = ("user", "film") verbose_name = "用户评分" verbose_name_plural = verbose_name def __str__(self): return f"{self.user.username}-{self.film.title}: {self.score}"

unique_together保证一个用户对一部电影只能评一次分。用户在提交评分时，视图函数要做两件事：写入Rating表，同时更新Film表的average_rating和rating_count。更新平均分时要注意并发问题，Django的F()表达式就派上用场了：

from django.db.models import F def submit_rating(request, film_id): film = get_object_or_404(Film, pk=film_id) score = request.POST.get("score") rating, created = Rating.objects.get_or_create( user=request.user, film=film, defaults={"score": score} ) if not created: # 更新已有评分，需要先减去旧值 film.rating_count = F("rating_count") film.average_rating = ( (F("average_rating") * F("rating_count") - rating.score + int(score)) / F("rating_count") ) rating.score = score rating.save() else: film.rating_count = F("rating_count") + 1 film.average_rating = ( (F("average_rating") * (F("rating_count") - 1) + int(score)) / F("rating_count") ) film.save(update_fields=["rating_count", "average_rating"])

这里用F()表达式是为了避免竞态条件。如果先查出来再算平均值再写回，两个用户同时评分时可能丢更新。F()表达式把计算下推到数据库层面执行，在高并发场景下这个细节能救命。

3. 功能实现与页面渲染

3.1 电影列表页与筛选排序

电影列表页的筛选条件有分类、地区、年份，排序方式有评分、热度、最新上映。我直接用Django的ORM链式查询实现，没有引入额外插件：

def film_list(request): films = Film.objects.filter(is_published=True) genre_slug = request.GET.get("genre") region = request.GET.get("region") year = request.GET.get("year") sort = request.GET.get("sort", "-average_rating") if genre_slug: films = films.filter(genres__slug=genre_slug) if region: films = films.filter(region=region) if year: films = films.filter(release_date__year=year) valid_sort_fields = { "rating": "-average_rating", "hot": "-rating_count", "latest": "-release_date", } films = films.order_by(valid_sort_fields.get(sort, "-average_rating")) paginator = Paginator(films, 12) page_number = request.GET.get("page") page_obj = paginator.get_page(page_number) return render(request, "films/film_list.html", { "page_obj": page_obj, "genres": Genre.objects.all(), "current_sort": sort, "current_genre": genre_slug, "current_region": region, "current_year": year, })

筛选逻辑里有个小细节：我用了valid_sort_fields字典来做排序白名单。千万不要直接把request.GET.get("sort")拼进order_by()里，那样用户传一个sort=password就能把数据库字段暴露出来，直接order_by("password")虽然不致命，但传sort=title__password之类的组合就可能探测出表结构。白名单过滤是最稳妥的做法。

页面上我放了GET表单来传递筛选参数，保持URL可分享。分页用Django内置的Paginator，默认每页12部电影，正好适配三列四行的网格布局。

3.2 影评发布与富文本处理

影评发布这块，短评用普通文本域就够了，深度解读我上了富文本编辑器。这里没有用复杂的富文本库，而是用django-summernote插件。原因很简单：深度解读文章需要插入图片、加粗、引用格式，这些需要成熟的编辑器支持。Summernote轻量、集成方便、中文支持好。

表单处理的核心逻辑：

class ReviewForm(forms.ModelForm): class Meta: model = Review fields = ["title", "content", "rating", "content_type"] widgets = { "content": SummernoteWidget(), "rating": forms.NumberInput(attrs={"min": 0, "max": 10, "step": 1}), } def clean_rating(self): rating = self.cleaned_data.get("rating") if rating is not None and (rating < 0 or rating > 10): raise forms.ValidationError("评分必须在0到10之间") return rating

提交影评的视图里要注意commit=False的用法。用户提交的表单数据不含film和author，这两个字段需要手动从URL参数和登录会话里带上：

def create_review(request, film_id): film = get_object_or_404(Film, pk=film_id) if request.method == "POST": form = ReviewForm(request.POST) if form.is_valid(): review = form.save(commit=False) review.film = film review.author = request.user review.is_approved = True # 可以直接简化，或者根据需求改 review.save() messages.success(request, "影评发布成功！") return redirect("films:film_detail", pk=film.id) else: form = ReviewForm() return render(request, "films/review_form.html", {"form": form, "film": film})

这里的is_approved我直接写死为True，是因为个人项目里不需要复杂的审核流。如果未来要做多用户运营，再改回False然后由管理员在后台审核即可。项目初期少做点功能，等有真实需求再迭代，这是我一贯的做法。

3.3 深度解读页面与文章详情

深度解读的详情页和短评展示有区别。短评展示重点是“评分+简短感受”，深度解读需要完整的文章排版。我给两种内容类型配置了不同的详情模板：

def review_detail(request, pk): review = get_object_or_404( Review.objects.select_related("author", "film"), pk=pk, is_approved=True, ) # 浏览量统计，用F表达式防止并发重复计数 Review.objects.filter(pk=review.pk).update(view_count=F("view_count") + 1) review.view_count += 1 comments = review.comments.filter(is_approved=True).select_related("user") return render(request, "films/review_detail.html", { "review": review, "comments": comments, })

select_related是Django ORM性能优化最重要的手段之一。影评查询时需要关联author和film，如果不用select_related，每渲染一条影评就要多查两次数据库——这就是经典的N+1查询问题。列表页展示20条影评就是61次查询，加了select_related一次就搞定。

浏览量统计用update而不是saving再save()，同样是为了避免并发重复计数——两个用户同时打开页面，用对象save()会丢一次计数，update()是原子操作。

3.4 交互功能：点赞、收藏与评论

点赞和收藏是社区产品的标配。我用了一个很通用的Like模型来记录：

class Like(models.Model): user = models.ForeignKey(User, on_delete=models.CASCADE) content_type = models.ForeignKey(ContentType, on_delete=models.CASCADE) object_id = models.PositiveIntegerField() content_object = GenericForeignKey("content_type", "object_id") created_at = models.DateTimeField(auto_now_add=True) class Meta: unique_together = ("user", "content_type", "object_id")

这里用了Django的ContentType框架实现通用点赞，这样影评、评论、甚至电影本身都能共用一张点赞表，不需要每种内容单独建一张ReviewLike、CommentLike表。这是Django进阶的重要知识点，通用外键解决的就是这类多模型关联场景。

前端我用fetch发AJAX请求，视图层根据请求类型返回JSON：

from django.http import JsonResponse from django.views.decorators.http import require_POST @require_POST def toggle_like(request): if not request.user.is_authenticated: return JsonResponse({"error": "请先登录"}, status=401) content_type_id = request.POST.get("content_type_id") object_id = request.POST.get("object_id") ct = ContentType.objects.get_for_id(content_type_id) like, created = Like.objects.get_or_create( user=request.user, content_type=ct, object_id=object_id, ) if not created: like.delete() liked = False else: liked = True like_count = Like.objects.filter(content_type=ct, object_id=object_id).count() return JsonResponse({"liked": liked, "like_count": like_count})

这里要注意@require_POST装饰器。点赞是修改操作，必须用POST请求，不能用GET。如果用GET实现点赞操作，搜索引擎爬虫和浏览器预加载可能会误触发，导致数据错乱。

评论功能相对简单，一个Comment模型加表单提交就搞定了。但评论列表的分页要做好，数据量大时不能一次全部加载。我默认每页20条评论，用Paginator处理。

4. 常见问题与排查技巧实录

4.1 数据库迁移报错和时区问题

开发过程中最常遇到的坑就是迁移报错。尤其是ImageField字段，Pillow库没装就容易在makemigrations时挂掉。解决办法是提前安装：

pip install pillow

还有一个印象深刻的坑是时区设置。Django默认USE_TZ = True，数据库存的是UTC时间，模板渲染时会转成本地时间。如果设置不对，会出现发布的影评显示的时间比实际早了8小时的情况。项目里settings.py的配置要确认下面几项：

TIME_ZONE = "Asia/Shanghai" USE_TZ = True

比较微妙的是，auto_now_add字段在USE_TZ=True时存的是UTC，模板渲染时Django会做转换，所以页面显示没问题。但如果你在代码里直接用timezone.now()和datetime.now()混用，坑就来了——datetime.now()返回的是不带时区的本地时间，和带时区的timezone.now()比较时会直接报错。这类问题也是多次踩坑后才总结出的经验。

4.2 静态文件404和Admin后台样式丢失

部署到Linux服务器上之后，经常遇到的第一个问题就是后台CSS全都丢了。原因就是Django默认不提供静态文件服务，DEBUG=False时runserver也不管静态文件了。

解决方法是项目根目录建一个staticfiles目录，然后修改配置：

STATIC_URL = "/static/" STATIC_ROOT = os.path.join(BASE_DIR, "staticfiles") STATICFILES_DIRS = [ os.path.join(BASE_DIR, "static"), ]

先执行python manage.py collectstatic收集所有静态文件，再用nginx配置别名指向staticfiles目录。这样后台样式就正常了。如果你用的是宝塔面板部署，其实还有更省事的方式，下一节详细说。

4.3 Django Admin后台界面美化与运营效率

Django Admin默认界面比较简陋，但通过配置可以让后台更好用。我做了三件事：

第一件事，在ModelAdmin里配置list_display、list_filter和search_fields，让列表页能直接看到关键信息：

@admin.register(Review) class ReviewAdmin(admin.ModelAdmin): list_display = ["title", "author", "film", "content_type", "is_approved", "is_featured", "view_count", "created_at"] list_filter = ["is_approved", "is_featured", "content_type", "created_at"] search_fields = ["title", "author__username", "film__title"] list_editable = ["is_approved", "is_featured"] date_hierarchy = "created_at" actions = ["approve_reviews", "feature_reviews"] @admin.action(description="审核通过所选影评") def approve_reviews(self, request, queryset): queryset.update(is_approved=True)

list_editable是最实用的配置之一，列表页直接勾选“审核通过”和“首页推荐”两个开关，不用点进详情页，运营效率至少提升一倍。

第二件事是定制Admin的站点信息：

admin.site.site_header = "电影影评社区管理后台" admin.site.site_title = "影评管理" admin.site.index_title = "内容运营控制台"

第三件事是引入django-import-export插件，让电影数据支持Excel批量导入。初期整理影片数据时，一部部手输很痛苦，支持批量导入后，从Excel里几百部电影一次就能进库。

4.4 常见问题速查表

4.5 Django ORM查询优化经验

在做热门影评排行榜时，我遇到了性能瓶颈。一开始直接：

hot_reviews = Review.objects.filter(is_approved=True).order_by("-view_count")[:10]

这条查询本身没问题，但渲染时每一条影评都要查询关联的film和author。后来改成：

hot_reviews = Review.objects.filter(is_approved=True).select_related("film", "author").order_by("-view_count")[:10]

查询次数直接从1+10次降到1次。类似这样的优化在整个项目里反复出现，多一次select_related，数据库压力就小一截。还有一次查“某影评的评论数量”，原来是在循环里一次次count()，后来改成annotate配合Prefetch一次性查出来。Django ORM用得好不好，很多时候就体现在这些细节上。

5. 生产环境部署与上线体验

5.1 服务器配置与域名解析

我用了一台2核4G的Linux服务器来部署这个项目。这里有个小心得是，部署前先确认好域名解析和备案状态，不然容易卡在最后的访问环节浪费一天。域名解析到服务器IP后，装好Nginx、MySQL和Python环境。

操作系统选的是CentOS 7系的Linux发行版，在线安装依赖的时候要注意版本兼容性。Django 4.2对Python版本有要求，服务器上自带的Python可能只是3.6，需要自己再装一个Python 3.10。Linux系统安装Python的常规路径是下载源码编译，编译前记得装好zlib-devel、openssl-devel这些依赖，否则后面用pip装mysqlclient时容易翻车。

mysqlclient是连接MySQL的关键依赖，Linux上装这个库有坑点：mysql_config指令不在PATH里会导致安装失败。解决办法是先装上mysql-devel再执行：

sudo yum install mysql-devel gcc gcc-c++ python3-devel pip install mysqlclient

如果你不想折腾原生依赖，还有一个替代方案是装pymysql，然后在项目的__init__.py里加上：

import pymysql pymysql.install_as_MySQLdb()

但说实话，个人经验是优先用mysqlclient，它底层走MySQL的C客户端，性能和稳定性都好很多。

5.2 用宝塔面板快速部署Django项目

如果你不想纯命令行部署，宝塔面板是我实测比较省心的方案。宝塔可以直接管理Nginx、MySQL、Python环境，还内置了Python项目管理器，可以一键创建Django项目站点。

部署流程大致是：

1. 在本地把项目打包上传到服务器，或者用git clone拉取。
2. 在宝塔中创建Python项目，选择Python 3.10版本和应用启动方式。
3. 配置项目的settings.py：把ALLOWED_HOSTS改成域名或"*"本地测试，但生产环境最好精确配置。
4. 配置Nginx反向代理，把80端口转发到Django的监听端口。
5. 配置静态文件和媒体文件路径。
6. 安装依赖、迁移数据库、收集静态文件、重启服务。

这里我强烈建议上线前做一次完整的新环境测试。很多人开发环境用的Windows加上SQLite，上线后切到Linux加MySQL就各种报错。我都是先把项目拉到服务器上跑一遍开发模式确认没问题，再切生产模式。

5.3 Gunicorn与Nginx的配合

生产环境不能用runserver，这是入门者最常踩的坑。runserver是Django开发用的轻量服务器，性能差且不安全。我用Gunicorn作为WSGI服务器：

gunicorn config.wsgi:application -w 3 -b 0.0.0.0:8000

-w 3是启动3个worker进程。对于2核4G的机器，通常2到4个worker是合理区间。-b指定监听地址。更稳健的方式是用supervisor管理Gunicorn进程，让它自动守护，崩了自动重启。

Nginx负责静态文件服务、SSL终止和反向代理。反向代理配置：

server { listen 80; server_name yourdomain.com; location /static/ { alias /path/to/staticfiles/; } location /media/ { alias /path/to/media/; } 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_set_header X-Forwarded-Proto $scheme; } }

加了HTTPS后，这段配置要配合SSL证书调整。使用Let's Encrypt的话可以直接一键申请免费证书，Nginx配置里再加两行证书路径就行。

设置X-Forwarded-Proto这个头很重要。如果少了它，Django里用request.is_secure()判断是不是HTTPS请求时会一直返回False，可能导致redirect到HTTPS的逻辑失效。

5.4 上线后的一些运营小技巧

部署完成之后，有几个细节值得处理一下。

第一，定期备份数据库。最简单的办法是写个cron任务定时执行mysqldump：

0 3 * * * mysqldump -u username -p password dbname > /backup/db_$(date +\%Y\%m\%d).sql

备份文件最好再同步到另一台机器，防止服务器磁盘故障导致数据全丢。

第二，开启Admin后台的操作日志。Django自带的django.contrib.admin里的LogEntry会记录后台管理操作，如果多人协作运营，查看日志能追溯谁把哪篇影评下架了。

第三，用django-compressor压缩CSS和JS文件。不压缩时一个页面可能加载二十多个静态文件，压缩合并后只有一两个请求，页面加载速度提升非常明显。

第四，接入sitemap。Django有sitemap框架，配合搜索引擎的搜索资源平台提交，能让电影详情页和影评页更快被收录。对内容型网站来说，这个功能性价比极高。

6. 项目复盘与个人收获

我把这个项目代码整理上传到自己的代码仓库时，翻了一遍各处注释和踩坑记录，最大的感受是：做一个完整的Web应用，真正难的从来不是某一个单独的技术点，而是把这些技术点串联成一条线的过程。

就拿“影评详情页”这一个页面来说，它涉及URL路由设计、视图函数、ORM查询优化、模板继承、评论表单、点赞AJAX、浏览量统计、SEO标签、分页处理、静态文件加载，十来个环节环环相扣。任何一个环节出现问题，页面就起不来。这就是全栈项目练习的价值——它能逼你把每个技术点都理解透，而不是像刷教程那样“看着会了”。

如果让我给正在学Django的朋友一个建议，那就是不要停留在跟着教程敲一遍代码，一定要自己动手从头搭一个完整项目。跟着教程敲，敲完是一堆别人的代码；自己从需求出发设计数据模型、写路由、写视图、调模板、踩坑解决，这一轮下来才是真正长在自己身上的能力。

这个项目后续我还计划扩展一些功能，比如基于用户评分做推荐算法，或者用Redis做缓存层来提升热点页面的响应速度。都是老玩法了，但对一个社区网站来说，每多一个实用功能，整个项目的完整度就上了一个台阶。