评论功能看起来简单：一个输入框、一条列表、一个删除按钮。但真把它放到社交网络场景里，问题立刻变得具体——一条推文下面几万条评论怎么分页？楼中楼怎么存？删了父评论，子评论怎么办？搜索"某人上周说过的某句话"靠 SQL 的 like 能不能扛住？这些都不是背八股能糊过去的，得亲手写一遍才知道坑在哪。

这门课围绕一个评论系统展开，技术栈落在 Django 一侧：Web 框架本身、MySQL 与 ORM 的接入、Django Rest Framework 提供接口、单元测试兜底，另外涉及虚拟开发环境和 Git 的基本操作。如果你正卡在"会写 CRUD 但没做过后端服务设计"这个阶段，它的定位比较对得上。

先确认自己缺的是哪一块

这门课不是零基础入门。它更适合以下状态的人：

写过 Python，但没认真用过 Django，分不清 Model、View、Serializer 各自的职责边界；
做过后端接口，但代码是"能跑就行"，没写过单元测试，也没考虑过异步任务和缓存该放在哪一层；
面试被问到"评论系统怎么设计"时，只能答出建一张 comment 表和 parent_id 字段，再往下就说不清；
简历上项目栏空着，需要一个能讲清楚技术决策、而不是只能描述界面的项目。

如果以上都不沾，你可能更需要的是数据库原理或分布式系统的专项内容，而不是这个项目。

评论模块真正难的地方

把它拆开看，会碰到几个绕不过去的点。一是层级结构：用 parent_id 做邻接表最简单，但查询多层回复时要递归，改成路径枚举或闭包表又是另一套取舍。二是接口设计：列表接口要不要返回嵌套结构？分页用 offset 还是游标？返回字段要不要按场景裁剪？这些决定会直接写进 DRF 的 Serializer 和 ViewSet 里。三是搜索：评论全文检索如果只靠数据库模糊查询，数据量一上来就崩，需要引入专门的检索方案。四是异步与缓存：点赞计数、通知下发这类操作不该卡住主请求，缓存又要处理失效和一致性。课程把这些作为进阶特性列出，说明它不满足于做一个能提交评论的玩具。

配套练习怎么用才不白学

这类项目课的常见问题是"看懂了但写不出"。建议按这个节奏走：

先不看参考实现，自己把数据模型和接口列表写出来，写完再对照，差异点就是你的知识缺口；
每加一个功能，同步补一个单元测试。测试不是为了覆盖率数字，而是逼你想清楚边界——空评论、超长评论、重复提交、权限校验；
异步任务和缓存部分，重点搞清楚"什么该异步、什么该缓存、失效策略怎么定"，而不是记住某个 API 的调用方式；
最后把整个项目在本地环境跑通一遍提交记录，Git 的提交粒度本身就是代码组织能力的体现。

学完之后应该能回答的问题

拿这几个问题自测，能顺畅说清楚，说明这门课没白上：评论表为什么这样设计，多级回复的查询代价是什么；DRF 里序列化嵌套数据和扁平数据的取舍依据；全文搜索方案为什么不能直接复用普通查询；异步任务失败后如何重试和补偿；缓存命中率低时你从哪里入手排查。如果答不上来，回去补对应章节，比继续往下推进度更有用。

缺什么补什么。这个项目适合当作一次完整的后端服务演练，把它做完、讲清楚，比简历上多一行"熟悉 Django"实在得多。