企业官网建设流程全解析

1. 热门文章功能的设计思路与场景拆解

做过内容站的朋友应该都有体会，后台文章列表一旦超过几百篇，编辑想找“最近哪几篇最火”就变成了体力活。Django自带的admin虽然开箱即用，但它默认只给你一个按字段排序的表格，没有任何“热度”维度的聚合视图。所谓热门文章功能，本质上就是在admin后台增加一个可排序、可筛选、可快速定位高流量内容的入口，让运营同学不用写SQL、不用翻日志，点两下就能看到哪些文章值得二次推荐。

这个功能解决的核心问题有三个。第一是数据聚合问题，文章的浏览量、评论数、点赞数通常分散在不同表里，admin默认的list_display只能展示当前模型的字段，跨表统计需要额外处理。第二是排序性能问题，如果每次打开列表都实时COUNT评论表，文章量大了之后后台会卡到怀疑人生，必须考虑预计算或缓存。第三是运营视角问题，技术同学觉得“按浏览量排序”就够了，但运营真正关心的是“最近7天热度上升最快的文章”，时间窗口这个维度必须留出来。

适合谁来参考这篇内容？如果你已经能跑通Django的admin基础配置，知道list_display、list_filter怎么用，但还没做过跨表统计和自定义排序，那这篇正好补上这块。如果你是完全的新手，建议先把官方tutorial的admin部分过一遍再回来，不然有些地方会卡住。

我自己的项目里，热门文章功能上线后，编辑找爆款的时间从平均五分钟缩短到十秒以内，而且因为加了时间窗口筛选，他们能发现一些“老文章突然被翻出来”的长尾流量，这是单纯按总浏览量排序绝对看不到的。

2. 核心字段设计与数据模型改造

2.1 为什么要在文章模型上冗余计数字段

最直觉的做法是每次需要热门列表时，用annotate去关联统计评论表和浏览记录表。我一开始也是这么干的，代码写起来很优雅：

from django.db.models import Count Article.objects.annotate( comment_count=Count('comments') ).order_by('-comment_count')

但实测下来，当文章数到两千、评论数到五万的时候，这个查询在后台列表页要跑三秒以上。原因很简单，annotate生成的SQL里带GROUP BY，而且admin的get_queryset还会叠加分页、搜索、筛选条件，数据库优化器很难走索引。

所以我的方案是在Article模型上直接加冗余字段：view_count、comment_count、like_count，再加一个hot_score用来存综合热度分。每次有新的浏览、评论、点赞时，通过信号或者显式的F表达式更新这些字段。这样admin列表查询就变成了单表扫描，速度直接回到毫秒级。

注意：冗余字段最大的坑是数据不一致。比如批量删除评论时如果忘了同步减comment_count，后台显示的数字就会虚高。我的做法是写一个管理命令recalc_counts，每周跑一次全量校准，平时靠信号增量更新。

2.2 hot_score的计算公式与参数选择

热度分怎么算，这是整个功能里最需要动脑子的地方。纯按浏览量排，新文章永远打不过老文章；纯按时间排，又变成了“最新文章”而不是“热门文章”。我参考了几个内容平台的公开思路，最后定下来的公式是：

hot_score = (view_count * 1 + comment_count * 3 + like_count * 2) / (hours_since_publish + 2) ** 1.5

这个公式里有三个关键参数需要解释。权重系数（1、3、2）反映的是互动成本：浏览一次最廉价，评论要打字所以权重最高，点赞居中。时间衰减指数1.5是我试出来的，用1.0衰减太慢，老文章霸榜；用2.0衰减太快，新文章还没积累数据就沉了。分母加2是为了防止刚发布的文章除以接近零的数导致分数爆炸。

这个公式不需要实时算。我在模型里加了一个hot_score字段，配合一个定时任务每半小时重算一次最近七天的文章。为什么是半小时？因为热门榜不需要秒级更新，半小时的延迟对运营完全够用，而且能把数据库压力摊平。

2.3 时间窗口字段的预留

运营后来提了一个需求：“我想看最近24小时的热门，也想看最近7天的，还想看总榜。”如果只存一个hot_score就满足不了。我的处理方式是加三个字段：hot_score_24h、hot_score_7d、hot_score_all，分别对应不同时间窗口的计算结果。定时任务里一次算三遍，写入三个字段。

这样admin里就可以用list_filter做时间窗口切换，或者干脆做三个不同的列表页。字段多了会不会浪费空间？三个FloatField而已，相比它带来的运营效率提升，这点存储成本可以忽略。

3. admin后台的列表页定制实操

3.1 list_display与排序字段的配置

先看基础配置。在ArticleAdmin里，我把热门相关的字段全部放进list_display：

@admin.register(Article) class ArticleAdmin(admin.ModelAdmin): list_display = ( 'title', 'author', 'status', 'view_count', 'comment_count', 'like_count', 'hot_score_7d', 'published_at', ) list_filter = ('status', 'category', 'published_at') search_fields = ('title', 'content') ordering = ('-hot_score_7d',) list_per_page = 30

这里有几个细节值得说。ordering设成-hot_score_7d之后，后台默认就按七日热度排，编辑一进来看到的就是热门榜。list_per_page设30而不是默认的100，是因为热门文章列表通常只看前几页，每页少一点加载更快，编辑翻页的心理负担也小。

但这里有个坑：ordering会影响所有查询，包括搜索和筛选之后的结果。如果编辑搜“Django”然后发现结果还是按热度排，可能不是他想要的。我的折中方案是保留默认排序，但在admin里加一个自定义的get_ordering方法，当检测到搜索参数时切换成按发布时间排。

3.2 用list_editable做快速调整

有些文章是编辑手动置顶的，跟算法算出来的热度无关。我在模型里加了一个is_featured布尔字段，然后在admin里把它设成可编辑：

list_editable = ('is_featured',)

这样编辑在列表页直接勾选就能置顶，不用点进详情页。但list_editable有个限制：它要求字段必须在list_display里，而且不能是list_display_links的第一个字段。我第一次配的时候把is_featured放在title后面，结果报错说不能编辑链接字段，后来挪到view_count旁边就好了。

实操心得：list_editable保存时是逐行提交的，如果编辑一次性勾了二十行，会产生二十次UPDATE。文章量大的站点建议配合actions做批量操作，而不是依赖list_editable。

3.3 自定义admin方法展示格式化数据

hot_score是个浮点数，直接显示1234.5678很难看。我用@admin.display装饰器做了格式化：

@admin.display(description='七日热度', ordering='hot_score_7d') def hot_score_display(self, obj): return f'{obj.hot_score_7d:.1f}'

注意ordering参数，它告诉admin点击这个列的表头时按哪个字段排序。如果不写这个，Django会尝试按方法名排序然后报错。这个细节官方文档里提了一句，但很容易漏掉。

同理，view_count这种数字可以加千分位分隔：

@admin.display(description='浏览量', ordering='view_count') def view_count_display(self, obj): return f'{obj.view_count:,}'

4. 跨表统计与性能优化方案

4.1 信号机制更新计数字段

评论数、点赞数的实时更新，我用的是post_save和post_delete信号。以评论为例：

from django.db.models.signals import post_save, post_delete from django.dispatch import receiver from django.db.models import F @receiver(post_save, sender=Comment) def increment_comment_count(sender, instance, created, **kwargs): if created: Article.objects.filter(pk=instance.article_id).update( comment_count=F('comment_count') + 1 ) @receiver(post_delete, sender=Comment) def decrement_comment_count(sender, instance, **kwargs): Article.objects.filter(pk=instance.article_id).update( comment_count=F('comment_count') - 1 )

用F表达式而不是obj.comment_count += 1; obj.save()，是因为前者生成的是UPDATE ... SET comment_count = comment_count + 1，在并发场景下不会丢更新。后者是读-改-写三步，两个请求同时来就会少算一次。

注意：信号写在apps.py的ready()里导入，否则Django启动时不会注册。我踩过这个坑，信号代码写好了但死活不触发，查了半天才发现是没在ready里import。

4.2 定时任务重算hot_score

热度分的重算我用的是django-crontab或者系统的crontab，每半小时执行一次管理命令：

# management/commands/recalc_hot_score.py from django.core.management.base import BaseCommand from django.utils import timezone from datetime import timedelta from blog.models import Article class Command(BaseCommand): help = '重算文章热度分' def handle(self, *args, **options): now = timezone.now() articles = Article.objects.filter( published_at__gte=now - timedelta(days=7) ) for article in articles: hours = (now - article.published_at).total_seconds() / 3600 base = article.view_count + article.comment_count * 3 + article.like_count * 2 article.hot_score_7d = base / (hours + 2) ** 1.5 article.hot_score_24h = base / (hours + 2) ** 1.5 if hours <= 24 else 0 article.hot_score_all = base Article.objects.bulk_update( articles, ['hot_score_7d', 'hot_score_24h', 'hot_score_all'], batch_size=500 ) self.stdout.write(f'重算完成，共{len(articles)}篇')

这里用bulk_update而不是逐条save，两千篇文章从十几秒降到一秒以内。batch_size=500是试出来的，太大容易撑爆内存，太小又失去批量优势。

4.3 数据库索引的配合

ordering = ('-hot_score_7d',)这个默认排序，如果hot_score_7d上没有索引，每次打开列表都是全表扫描加排序。我在模型的Meta里加了：

class Meta: indexes = [ models.Index(fields=['-hot_score_7d']), models.Index(fields=['-hot_score_24h']), models.Index(fields=['status', '-hot_score_7d']), ]

第三个复合索引是给“已发布+按热度排”这个最常见的查询组合用的。加索引会让写入稍微变慢，但热门文章功能是读多写少的场景，这个 trade-off 完全值得。

5. 常见问题排查与避坑经验

5.1 热度分不更新或更新延迟

最常见的原因是定时任务没跑起来。排查顺序是：先手动执行python manage.py recalc_hot_score看有没有报错，再检查crontab的日志，最后确认published_at字段有没有时区问题。我遇到过一次，服务器时区是UTC而published_at存的是本地时间，导致hours算出来是负数，热度分全变成了负值。

5.2 admin列表页加载缓慢

如果加了索引还是慢，大概率是list_display里放了会触发额外查询的方法。比如你写了一个def comment_preview(self, obj): return obj.comments.first().content，每行都会查一次评论表，三十行就是三十次查询。解决办法是用list_select_related或者prefetch_related，在get_queryset里一次性把关联数据取出来。

5.3 计数字段与实际不符

前面提过，批量操作是重灾区。除了定时校准，我还在admin里加了一个action叫“重新统计选中文章”，编辑发现数字不对可以手动触发。代码逻辑就是遍历选中的文章，重新COUNT一遍评论和点赞，然后覆盖写入。

独家避坑：bulk_update不会触发post_save信号，所以如果你在信号里做了其他联动操作（比如发通知），用bulk_update重算热度时那些操作不会执行。这是特性不是bug，但不知道的话会困惑很久。

6. 功能扩展与运营侧联动

热门文章功能做完之后，我顺手加了两个扩展。一个是admin首页的仪表盘，用AdminSite.index_template覆盖默认模板，在顶部展示“今日热度Top10”的缩略列表，编辑登录就能看到。另一个是给热门文章加了一个is_featured的自动推荐逻辑：当某篇文章的hot_score_24h进入前五时，自动把is_featured置为True，运营只需要审核不需要手动挑。

这两个扩展都不复杂，但把“热门文章”从一个被动查询变成了主动推荐，运营侧的反馈明显更好。有编辑跟我说，以前是“我想找热门文章”，现在是“热门文章来找我”，这个体验差异还是挺大的。

后续如果文章量继续涨，可以考虑把热度计算从定时任务改成异步队列，用Celery做增量更新，进一步降低延迟。不过就目前的数据规模来说，半小时一次的批量重算完全够用，没必要过早优化。