zhenxun_bot 插件调用统计：装插件前，先看这组数据

【免费下载链接】zhenxun_bot基于 Nonebot2 开发，实现多平台适配和多Bot管理的，非常可爱的绪山真寻Bot项目地址: https://gitcode.com/GitHub_Trending/zh/zhenxun_bot

在 zhenxun_bot 的插件商店里翻插件，经常会撞上同一功能两个候选：简介都写着"签到"，作者栏一长串，版本号还都是 v0.1。靠描述文字根本分不出哪个更值得装。好在项目自带一套插件调用统计，把你机器人真实发生过的每一次调用都记成了数——花两分钟读懂这条从采集到排行榜的数据链路，以后挑插件就有据可依，不用再拿群做试验田。

场景：商店里的两款签到插件

先在群里跑插件商店，命令会一次性渲染两张表：原生插件和第三方插件，每行带 ID、名称、作者、版本，装过的行首还会亮起绿色"已安装"。

问题来了：

• 简介是作者自己写的，"轻量""好用"这类词两边都能用；
• 作者栏没有信誉分，新面孔和老面孔长得一模一样；
• 版本停在 v0.1 的插件，可能是刚写完，也可能是写了没人管。

判断"哪个还在维护、还有人用"，唯一的硬证据是调用数据——这正是插件调用统计要补上的缺口。

机制拆解：一次调用如何变成排行榜上的数字

整条链路分三段：每次调用先被钩子记成一笔账，攒够一批再落库，查询时直接按插件名分组计数，最后画成条形图。下面按顺序拆。

数据采集：每次调用，钩子自动记账

机器人每执行完一次插件命令，统计钩子就会悄悄记一笔，用户和群都不用做任何事。钩子挂在 NoneBot 的 postprocessor 上，每次消息处理结束自动触发；一条记录包含 5 个字段：谁调用的（user_id）、在哪个群（group_id）、调了哪个插件（plugin_name）、什么时候（create_time）、哪个 bot 处理的（bot_id），字段定义见 统计模型。

同时有三道滤网，保证账本不掺水：

1. notice 类事件一律跳过（戳一戳除外）；
2. 插件声明了ignore_statistics的，直接不记；
3. 插件信息缓存未命中时也直接放弃——宁可漏一条，不查一次库。

写入不是实时逐条进行的：记录先进内存缓冲，攒到 5000 条或 30 分钟才批量写库，机器人生机终止前还会强制刷一次盘。活跃大群一天几千次调用，数据库压力也有限。

聚合查询：按插件名分组，一次数完

看统计时系统不会去扫原始明细，而是在数据库层按plugin_name分组计数，再叠加用户、群、插件名、时间窗这些过滤条件：

query.annotate(count=Count("id")) .group_by("plugin_name") .values_list("plugin_name", "count")

这段逻辑藏在 缓存聚合层 里，查询结果还会复用缓存，同条件连问几次不会反复打数据库。

结果呈现：横向条形图加后台面板

数完之后，统计插件把"插件名 → 次数"交给图表引擎，画成横向条形图：装了几个插件，图上就有几根条，数字直接来自库里的明细，没有任何人工修饰。统计维度可以切到日、周、月，也可以切到个人视角——我的功能调用统计看自己在当前群的调用，加-g看全局。Web 管理端的仪表盘上也有现成入口：中间区域的"调用总数/今日调用"，右侧"热门插件"面板同样按全/日/周/月/年切换（见文末实操部分）。

实操：三步验证一个插件值不值得装

装任何新插件之前，按这个顺序过一遍命令，基本能过滤掉一半的"僵尸插件"：

1. 看排行：发功能调用统计（超级用户加-g看跨群总量），确认目标插件有没有出现在条形图里；
2. 看近期：发周功能调用统计，确认它这 7 天还活着，而不是只在年初被调过几次；
3. 再决定装不装：打开插件商店拿 ID，添加插件 插件ID即可安装，装错就用移除插件 插件ID清掉，全程重启一次生效。

常用命令对照：

边界与演进：现在有什么，还缺什么

这套体系目前是"只读"的：调用量是自动采集的，插件信息表里另有version、author字段供商店做版本对比，impression则是好感度门槛，跟质量打分无关。换句话说，它回答得了"谁用得最多"，还回答不了"谁写得好"。

把社区评价和错误日志接进来，是这条链路最自然的下一步；在那之前，调用量就是最接近真实口碑的一把尺子。

先看统计，再装插件。让调用量替你做决定，比看十句"亲测好用"都踏实。

【免费下载链接】zhenxun_bot基于 Nonebot2 开发，实现多平台适配和多Bot管理的，非常可爱的绪山真寻Bot项目地址: https://gitcode.com/GitHub_Trending/zh/zhenxun_bot