文章阅读量按访客去重的一种实现
- 后端架构
- 时间:2026-06-03 17:30:00
- 161 人已阅读
简介阅读量不适合每次刷新都加一,按 IP 与 User-Agent 哈希做短周期去重会更接近真实访问。 本文会结合项目实践,重点记录保存访问记录时写入 article_views、同一访客短时间重复刷新不增加阅读数等处理思路,方便后续开发和排错时复用。
文章阅读量按访客去重的一种实现
阅读量不适合每次刷新都加一,按 IP 与 User-Agent 哈希做短周期去重会更接近真实访问。 本文会结合项目实践,重点记录保存访问记录时写入 article_views、同一访客短时间重复刷新不增加阅读数等处理思路,方便后续开发和排错时复用。

背景
这篇笔记来自个人博客项目里一次比较完整的实践。最初看起来只是一个小功能,但真正落到页面、后台、数据库和移动端之后,就会发现它牵涉到数据结构、交互反馈、权限边界和后续维护。
我的处理原则是:先让功能能被稳定使用,再把容易出错的地方收拢成约束。这样做不会让第一版变得很重,但能避免后面每加一个页面都重新踩一遍同样的问题。
实践要点
- 保存访问记录时写入 article_views。
- 同一访客短时间重复刷新不增加阅读数。
- 真实统计系统可以再引入更细的访客标识。
落地步骤
- 先确认页面真实使用场景,区分前台访客操作和后台管理员操作。
- 再整理数据来源,明确哪些字段来自数据库,哪些只是展示层计算结果。
- 然后补齐表单校验、空数据状态、错误提示和移动端样式。
- 最后用几条真实数据走一遍流程,检查列表、详情、分页和保存后的跳转。
在这个过程中,最容易被忽略的是“看起来能用”和“长期好用”之间的差距。比如提示信息是否统一、按钮是否会重复提交、列表是否分页、上传文件是否能被安全删除,这些细节都会影响后续维护体验。
示例代码
$hash = hash('sha256', $request->server('HTTP_USER_AGENT', ''));
$exists = Db::name('article_views')
->where('article_id', $articleId)
->where('ip_address', $request->ip())
->where('user_agent_hash', $hash)
->whereTime('viewed_at', 'today')
->find();
排查清单
- 如果页面显示异常,先看浏览器控制台和服务端日志,不要只盯着模板。
- 如果数据没有生效,确认查询条件、发布状态、软删除字段和缓存。
- 如果前台和预览不一致,优先检查 Markdown 渲染规则和公共 CSS。
- 如果手机端布局溢出,先判断是表格需要横向滚动,还是表单本身应该自适应。
个人记录
这类功能真正有价值的地方,不只是把按钮做出来,而是把规则说清楚。比如“保存访问记录时写入 article_views。”这类经验,如果不写下来,下一次遇到相似问题还是会凭感觉处理。
另一个收获是:同一访客短时间重复刷新不增加阅读数。 这会让项目越做越稳。早期多花一点时间整理边界,后面扩展分类、标签、留言、媒体库或者轮播配置时,心里会踏实很多。
真实统计系统可以再引入更细的访客标识。
小结
这篇笔记更像一次项目复盘:把问题拆清楚,把约束写明确,再把可以复用的处理方式沉淀下来。个人博客虽然规模不大,但它包含内容管理系统里常见的很多环节,认真做一遍,会比只看文档记得更牢。
上一篇:点赞功能如何更贴近真实用户行为
文章评论
暂无评论,来写第一条吧。