恶意代码检测：同一用户多次咨询时怎样区分人数与次数
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /c9305454f3d9.html
📄
恶意代码检测：同一用户多次咨询时怎样区分人数与次数
先给结论：在恶意代码检测的咨询记录里，“次数”是会话或提交条数，“人数”是能归并到同一自然人或同一受检主体的独立个体数。要区分两者，不能只看总数，而要先确认记录里有没有稳定的归并键，再决定是直接按会话计数，还是先归并再计数。若没有可核对的归并键，任何“人数”都只是估算，不能当作事实使用。
先判断有没有可用的归并键
归并键是能把两条记录连到同一个人的字段，例如同一登录账号、同一提交邮箱、同一受检文件哈希加同一联系人。恶意代码检测场景下，文件哈希只能说明“同一个样本被重复提交”，不能直接说明“同一个人”。如果两次提交来自不同账号但哈希相同，可能是同一样本在多个团队间流转，人数应算两人。
判断标准可以落到一个动作上：抽取最近若干条记录，只保留带有账号或邮箱的条目，看同一归并键下是否出现多条不同时间的咨询。若出现，说明这批数据支持“先归并再计人数”；若归并键缺失或大量为空，则只能报告次数，并在结论里注明人数不可核。
两种条件下的不同选择
条件一：归并键完整且稳定
此时应先把记录按归并键分组，再在组内取首次咨询时间作为该人的进入时间，取最后一次作为活跃时间。动作结果是：同一人多次咨询只计一次人数，但次数仍保留，用于观察重复咨询的强度。下一步可以据此判断，某类恶意代码检测问题是被反复追问，还是被不同人各问一次。
条件二：归并键缺失或不可靠
此时不要强行归并。更稳妥的做法是同时给出两个口径：原始次数，以及按“同一受检样本加同一咨询主题”粗略去重后的次数。后者只能称为“去重后的咨询条数”，不能称为人数。动作结果是，读者能看清总量里有多少来自重复提交，但不会把样本重复误当成人员重复。
用可核对的证据排除其他解释
次数高不必然等于人数多。常见替代解释包括：同一人换了设备或账号、同一团队多人共用邮箱、自动化脚本重复提交、以及同一受检文件被不同环节反复上传。要排除这些解释，可以核对提交时间间隔、来源账号、样本哈希和咨询正文是否高度相似。
如果同一哈希在短时间内反复出现，且正文措辞接近，更合理的解释是重复提交或流程回环，而不是新增人数。如果哈希不同但账号相同，说明同一人在持续提交不同样本，人数仍是一，次数增加。这个区分会直接影响下一步：前者应检查提交流程，后者应关注该人的持续检测需求。
一个注明假设的短例子
假设某恶意代码检测入口一周内收到 40 条咨询，其中 25 条带同一邮箱，10 条带另一邮箱，5 条无邮箱。按归并键计算，可确认人数为 2，次数为 40，其中 35 条可归并，5 条只能计为未知来源次数。这里的数字仅用于说明比较方法，不代表任何真实项目结果。
下一步动作是：先检查那 5 条无邮箱记录是否来自同一提交入口或同一时间段；若是，则把它们标为“待确认批次”，而不是直接加进人数。这样处理的结果是，人数不会被高估，次数也不会被丢弃。
例外与适用条件
当咨询涉及实际受检样本时，人数与样本数必须分开报告。一个人可以提交多个恶意代码样本，一个样本也可以被多个人提交。若业务只关心“有多少个独立受检对象”，就应以样本哈希或文件标识为主键；若关心“有多少个独立咨询者”，就应以账号或联系方式为主键。两者不能互相替代。
最后要说明：请求量、抓取量或提交量归零，不能单独证明归并逻辑正确。它也可能是入口变更、采集中断或统计口径调整造成的。只有在归并键、时间线和样本标识能相互印证时，人数与次数的区分才站得住脚。
