📍 WDQWDWQD987AAAAA:216.73.216.71
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /8ba7f20dc8bd.html
📄

网站性能分析怎样判断采集是否遗漏：先别把日志条数当覆盖量

判断采集是否遗漏，不能只看采集日志的总条数或“抓取成功”的数量，而要把同一时间窗口内的三类记录对齐：站内访问日志、采集任务自身的请求记录、以及页面内容实际入库记录。若三者对同一批 URL 的计数和状态不一致，才说明存在遗漏；单看某一项偏高或偏低，可能只是口径不同。

常见误解：日志里请求很多，就等于没有遗漏

采集日志通常记录的是“发起了多少次请求”，而不是“有多少个不同 URL 被完整取回”。同一页面可能因重试、跳转、分页或参数变化被请求多次，日志条数会明显高于实际应采集的 URL 数量。反过来，如果采集器对失败请求不写日志，日志条数又可能低于真实抓取次数。因此，日志条数只能说明请求活动量，不能直接证明覆盖完整。

另一个误解是把搜索引擎抓取报告当作站内采集结果。第三方估算流量、搜索引擎自己的抓取统计和站内采集系统的口径并不相同：前者通常经过抽样或估算，后者记录的是实际请求。判断采集遗漏应以可核对的请求与入库记录为主，而不是用估算数据反推。

用三层记录对齐，定位遗漏发生在哪一步

可以按下面的顺序做一次可执行的核对。假设某次采集任务计划覆盖 1000 个详情页，可以这样检查：

1. 生成待采集清单：从栏目页、站点地图或数据库导出应采集的 URL，去重后得到基准数量。这是分母。
2. 核对请求记录：在采集日志中按 URL 去重，统计真正发出请求的 URL 数量，并区分成功、超时、被拒绝、跳转等状态。
3. 核对入库记录：在存储端按同一 URL 去重，统计实际写入且字段完整的记录数量。
4. 做差集：基准清单减去请求记录，得到“从未请求”的 URL；请求记录减去入库记录，得到“请求了但没入库”的 URL。

如果差集集中在某一类页面，例如带分页参数的列表页，问题更可能在链接发现或 URL 规范化；如果差集分散且状态多为超时，问题更可能在网络或目标站限流；如果请求成功但入库为空，则要检查解析规则和字段映射。这里要区分“可能原因”和“已经定位的原因”：差集只说明遗漏范围，具体原因仍需结合状态码和解析日志确认。

检查项：哪些信号说明采集确实漏了

• 基准清单中的 URL 在请求记录里完全找不到，且不是被规则主动排除。
• 同一 URL 多次请求均返回相同错误，但任务被标记为完成。
• 入库记录数明显少于请求成功数，且缺失集中在某些模板或字段。
• 分页、筛选参数或动态加载内容未被纳入待采集清单。
• 采集时间窗口与站内访问日志窗口不一致，导致对比失真。

这些检查项要结合具体条件判断：如果目标站本身有访问频率限制，少量超时属于正常波动；如果连续多个批次都缺失同一批 URL，才更可能是采集配置问题。

一个可复用的短例子

假设某站点地图列出 500 个商品页，采集日志去重后有 480 个 URL 被请求，其中 20 个返回超时；入库记录为 470 条。此时可以判断：有 20 个 URL 从未被请求，10 个请求成功但未入库。前者需要检查链接发现逻辑，后者需要检查解析和存储。这个例子只用于说明对比方法，不代表任何真实项目结果。

实际操作时，可以用 sort 和 comm 对两份 URL 列表做差集，也可以把请求记录和入库记录导入表格后按 URL 做匹配。关键是保留原始记录，不要只保留汇总数字。

下一步怎么做

先固定一个时间窗口和一份基准 URL 清单，再分别导出请求记录与入库记录，按 URL 去重后做两次差集。得到差集后，优先查看这些 URL 的请求状态和解析日志，确认是未请求、请求失败还是解析失败，再决定调整发现规则、重试策略还是解析配置。