企业官网建设流程全解析

1. 从"能跑通"到"能扛住"：文章模块为什么是博客项目的第一道分水岭

很多人做Django博客，前面用户模块、登录注册都顺风顺水，一到文章模块就开始卡壳。原因不复杂——文章模块是整个项目里第一个真正把"数据关系"和"页面交互"揉在一起的地方。列表要分页、详情要关联作者和分类、评论要支持嵌套回复、回复还要防止无限层级。这几个需求单拎出来都不难，但叠在一起，新手很容易写出N+1查询、评论树渲染错乱、分页和筛选条件互相打架的问题。

我自己第一次写这个模块的时候，列表页看着正常，一上量就慢得离谱。后来用调试工具一查，发现每渲染一篇文章就要额外查一次作者信息，一页十篇就是十一次查询。这种问题在开发阶段完全看不出来，因为本地数据库里就几条数据。所以这篇文章不只是讲"怎么把功能写出来"，更想讲清楚"怎么写才不会在真实使用中翻车"。

这篇文章适合已经能跑通Django基础流程、准备动手写文章模块的人。我会按列表、详情、评论、回复这条主线，把每个环节的设计取舍、容易踩的坑、以及我实际用下来比较稳的写法都摊开讲。核心关键词就四个：文章列表、文章详情、评论、回复，但每个词背后都有一堆细节值得掰扯。

2. 文章列表：分页、筛选与查询优化三件事必须一起想

2.1 列表页的真正难点不在展示，而在查询次数

列表页看起来最简单，无非是把文章查出来循环渲染。但真正决定它好不好用的，是查询效率。假设一篇文章要显示标题、摘要、作者名、分类名、发布时间、评论数，如果你用最直觉的写法——在模板里通过外键一层层取——那每篇文章都会触发若干次额外查询。

我习惯的做法是在视图层就把需要的数据一次性取干净。用select_related处理外键（作者、分类这种一对一或一对多的关系），用annotate配合聚合函数把评论数直接算在查询里。这样一页十篇文章，查询次数能压到两三次，而不是二三十次。

from django.db.models import Count from django.core.paginator import Paginator def article_list(request): queryset = Article.objects.select_related('author', 'category') \ .annotate(comment_count=Count('comments')) \ .filter(status='published') \ .order_by('-created_at') paginator = Paginator(queryset, 10) page_obj = paginator.get_page(request.GET.get('page')) return render(request, 'article/list.html', {'page_obj': page_obj})

这里有个细节值得说：annotate和filter的顺序会影响结果。如果你先annotate再filter评论相关条件，聚合的基数会变，评论数可能算错。我一般把过滤条件放在聚合之前，确保统计的是全部评论而不是过滤后的子集。

2.2 分页参数被玩坏是列表页最常见的线上问题

分页本身用Django内置的Paginator就够了，但get_page和page这两个方法的区别很多人没搞清。page()在页码非法时直接抛异常，get_page()会优雅地回退到第一页或最后一页。列表页面向普通用户，一定要用get_page()，否则用户手改URL里的页码就能把页面搞崩。

还有一个坑是分页和筛选条件共存。比如列表页带分类筛选，用户翻到第三页，再点另一个分类，如果分页链接没带上筛选参数，就会跳回该分类的第一页甚至丢失筛选。解决办法是在模板里拼分页链接时保留当前查询字符串。我通常写一个小工具函数，把request.GET里的page参数替换掉，其余原样保留。

提示：分页每页条数不要拍脑袋定。列表页有摘要和缩略图的话，每页10条比较舒服；纯标题列表可以放到20条。条数太多会让单次查询变重，太少又增加翻页次数。

2.3 列表页要不要做缓存，取决于更新频率

文章列表是典型的"读多写少"页面。如果站点文章更新不频繁，给列表页加一层缓存收益很明显。但缓存粒度要选对：整页缓存最简单，但一旦有新文章发布就得清缓存；按查询集缓存灵活一些，但实现成本高。

我的经验是，个人博客这种量级，先别急着上缓存。等真正出现访问压力，或者列表页查询确实变慢时再考虑。过早优化只会让代码变复杂，还容易引入"发了新文章但列表不更新"这种让人抓狂的bug。真要缓存，优先缓存那些不常变的片段，比如侧边栏的热门文章、分类列表，而不是整个列表主体。

3. 文章详情：URL设计、浏览量统计与上一篇下一篇的取舍

3.1 详情页URL用ID还是用slug，这是个需要提前定的事

详情页的URL设计有两种主流做法：一种是用文章ID，比如/article/123/；另一种是用slug，比如/article/django-blog-list/。ID简单直接，永远不会冲突；slug对搜索引擎和用户都更友好，但需要处理重名和中文转拼音的问题。

我一般推荐slug方案，但要在模型里保证唯一性。生成slug时如果发现重复，就在后面追加短随机串或递增数字。中文标题转slug可以用第三方库，也可以自己写个简单的映射。关键是这个决定要在项目早期定下来，因为一旦文章多起来再改URL结构，所有外链和搜索引擎收录都会受影响。

from django.utils.text import slugify import uuid def save(self, *args, **kwargs): if not self.slug: base_slug = slugify(self.title) or uuid.uuid4().hex[:8] slug = base_slug while Article.objects.filter(slug=slug).exists(): slug = f"{base_slug}-{uuid.uuid4().hex[:4]}" self.slug = slug super().save(*args, **kwargs)

3.2 浏览量统计别直接往数据库写

浏览量是个高频写操作。如果每次访问详情页都article.views += 1; article.save()，文章一火，数据库写入压力会非常大，而且还会和文章内容的更新互相干扰。

比较稳的做法是用缓存做计数缓冲。每次访问先在缓存里给对应文章的计数加一，达到一定阈值或者定时任务再批量写回数据库。这样既保证了浏览量大致准确，又不会让每次访问都打数据库。如果对实时性要求不高，甚至可以用一个独立的计数表，异步更新。

注意：浏览量统计要防刷。同一个用户短时间内反复刷新不应该重复计数。可以用会话或缓存记录用户最近访问过的文章，设置一个合理的过期时间，比如半小时内同一用户对同一文章只计一次。

3.3 上一篇下一篇：看似简单，查询条件容易写错

详情页底部放"上一篇""下一篇"是很常见的需求。逻辑是按发布时间排序，找当前文章的前一条和后一条。但这里有个容易忽略的点：如果文章有草稿、私密等状态，上一篇下一篇必须只在已发布文章里找，否则用户会点进一个无权访问的页面。

def get_prev_next(article): published = Article.objects.filter(status='published') prev_article = published.filter(created_at__lt=article.created_at) \ .order_by('-created_at').first() next_article = published.filter(created_at__gt=article.created_at) \ .order_by('created_at').first() return prev_article, next_article

如果两篇文章发布时间完全相同，这个逻辑会漏掉其中一篇。更严谨的做法是用发布时间加ID组合排序，但大多数场景下发布时间精确到秒已经够用。我实际项目里会在发布时间上做唯一性约束，或者干脆用自增ID作为排序的兜底条件。

4. 评论系统：从平铺到嵌套，数据模型怎么设计才不后悔

4.1 评论模型的核心字段与自关联设计

评论要支持回复，最直接的做法是在评论模型里加一个指向自身的外键，表示"这条评论回复的是哪条评论"。这样一条评论既可以是顶级评论（父字段为空），也可以是某条评论的回复。

class Comment(models.Model): article = models.ForeignKey(Article, on_delete=models.CASCADE, related_name='comments') author = models.ForeignKey(User, on_delete=models.CASCADE) parent = models.ForeignKey('self', null=True, blank=True, on_delete=models.CASCADE, related_name='replies') content = models.TextField(max_length=1000) created_at = models.DateTimeField(auto_now_add=True) is_active = models.BooleanField(default=True)

这个设计的好处是灵活，理论上可以支持无限层级。但无限层级在展示上是个灾难，所以实际产品里通常只展示两层：顶级评论和它的直接回复。再深的回复会平铺到第二层，或者用"回复@某人"的方式表达。

4.2 只做两层展示，但数据层保留完整关系

我的建议是数据层保留完整的父子关系，展示层只渲染两层。这样既不会丢失"谁回复了谁"的信息，又避免了页面结构过于复杂。渲染时先取出所有顶级评论，再一次性取出这些顶级评论下的所有回复，在内存里按父ID分组。

def article_detail(request, slug): article = get_object_or_404(Article, slug=slug, status='published') top_comments = article.comments.filter(parent__isnull=True, is_active=True) \ .select_related('author').order_by('-created_at') comment_ids = [c.id for c in top_comments] replies = Comment.objects.filter(parent_id__in=comment_ids, is_active=True) \ .select_related('author', 'parent__author').order_by('created_at') reply_map = {} for reply in replies: reply_map.setdefault(reply.parent_id, []).append(reply) # 把 reply_map 传给模板

这里用select_related('parent__author')是为了在回复里显示"回复@某某"时不再额外查作者。这种细节在评论多的时候差别很明显。

4.3 评论提交的校验与防滥用

评论提交接口要做的校验比想象中多：内容不能为空、长度不能超限、文章必须存在且允许评论、父评论必须属于同一篇文章。最后这条特别容易被忽略——如果不校验父评论和文章的关系，恶意用户可以把A文章的评论挂到B文章下面，造成数据错乱。

def post_comment(request, article_id): article = get_object_or_404(Article, id=article_id, status='published') content = request.POST.get('content', '').strip() parent_id = request.POST.get('parent_id') if not content or len(content) > 1000: return JsonResponse({'ok': False, 'msg': '评论内容不合法'}) parent = None if parent_id: parent = Comment.objects.filter(id=parent_id, article=article).first() if not parent: return JsonResponse({'ok': False, 'msg': '回复目标不存在'}) Comment.objects.create(article=article, author=request.user, parent=parent, content=content) return JsonResponse({'ok': True})

防滥用方面，至少要加登录校验和频率限制。同一用户短时间内连续提交相同内容，应该被拦截。这些可以在视图层做简单判断，也可以用中间件统一处理。

5. 回复功能：嵌套渲染、@提醒与删除时的级联处理

5.1 回复的展示逻辑：平铺还是缩进

回复展示有两种常见风格。一种是缩进式，回复比被回复的评论往右缩进一层，视觉上形成对话感；另一种是平铺式，所有回复都在同一层级，通过"回复@某人"来表明关系。缩进式在移动端容易因为屏幕窄而显示不下，平铺式更省空间但对话关系不够直观。

我实际用下来，桌面端为主的站点用缩进式体验更好，移动端为主的用平铺式更稳。如果要做响应式，可以在小屏幕上把缩进层级压平。关键是缩进层级要有上限，超过两层就不再继续缩进，否则深层回复会把内容挤成一条竖线。

5.2 @提醒的实现思路与边界

回复时自动带上"回复@某人"是提升体验的小细节。实现上，在渲染回复内容前，根据父评论的作者生成一个前缀。但要注意，如果回复的是自己的评论，就不需要@自己；如果父评论已经被删除，@信息也要相应处理。

更完整的@提醒会涉及通知系统：被回复的人收到一条站内通知。这属于评论模块的延伸功能，如果要做，建议把通知逻辑独立成一个服务，评论创建后触发，而不是把通知代码塞在评论视图里。这样以后加邮件通知、推送通知都不会把评论逻辑搞乱。

5.3 删除评论时，子回复怎么办

删除评论是个需要想清楚的操作。如果直接删除父评论，子回复会因为外键级联一起消失，用户会觉得"我的回复莫名其妙没了"。更友好的做法是软删除：把评论标记为已删除，内容替换成"该评论已删除"，但保留结构，让子回复还能正常显示。

class Comment(models.Model): # ... 其他字段 is_deleted = models.BooleanField(default=False) def soft_delete(self): self.is_deleted = True self.content = '该评论已删除' self.save(update_fields=['is_deleted', 'content'])

软删除的代价是查询时要过滤掉已删除评论的内容，但保留其作为父节点的存在。这样既维护了对话的完整性，又给了用户"删除"的操作反馈。如果业务上确实需要物理删除，那至少要在删除前提示用户"该评论下的回复也会一并删除"。

6. 几个我实际踩过、文档里不会写的坑

6.1 评论数统计和实际评论列表对不上

前面列表页用annotate统计评论数，详情页又单独查评论列表，两边如果过滤条件不一致，就会出现"列表显示5条评论，点进去只有3条"的情况。根源通常是列表页统计时没排除已删除或未审核的评论。解决办法是统一一个查询集方法，比如active_comments()，列表统计和详情查询都用它，保证口径一致。

6.2 分页后评论锚点丢失

详情页评论多了要分页，用户提交评论后应该跳回评论所在的那一页并定位到自己的评论。如果提交后直接重定向到详情页第一页，用户会以为评论没发出去。做法是提交成功后计算评论所在页码，重定向时带上页码和锚点，比如/article/xxx/?comment_page=2#comment-45。

6.3 富文本内容在列表页的摘要处理

文章详情用富文本存储，列表页要显示摘要。如果直接截取HTML字符串，很容易把标签截断，导致页面结构错乱。正确做法是先用工具把HTML转成纯文本，再截取指定长度。Django生态里有现成的过滤器可以用，也可以自己写个简单的正则去标签函数。截取时还要注意中英文混排的宽度问题，按字符数截取对中文友好，按单词截取对英文友好，混合内容建议按字符数并留出余量。

6.4 并发提交评论导致重复

用户网络慢的时候可能连点提交按钮，导致同一条评论提交两次。前端可以在提交后禁用按钮，但后端也要有兜底。简单的做法是给评论内容加一个短时间内的去重判断：同一用户、同一文章、相同内容，若在若干秒内已存在，则拒绝重复创建。这个判断用缓存实现比查数据库更轻量。

7. 收尾：这个模块做完之后，我一般会回头检查这几件事

文章模块跑通不难，难的是跑稳。我每次做完这个模块，都会回头过一遍几个检查点：列表页的查询次数是否随文章数增长而暴涨；详情页的浏览量统计会不会成为写入瓶颈；评论的父子关系在删除和分页场景下是否还成立；回复的展示层级在移动端会不会溢出。这几个点只要有一个没处理好，上线后迟早会以bug的形式找上门。

另外说个个人习惯：评论和回复相关的视图，我会尽量把业务逻辑抽到独立的服务函数里，视图只负责参数校验和响应组装。这样以后要加通知、加审核、加敏感词过滤，都只需要改服务层，不会把视图改成一团乱麻。这个模块是整个博客项目里交互最密集的部分，前期多花点心思把结构理清楚，后面加功能会轻松很多。