信息收集的本质是缩小假设空间

扫描器跑完，一屏结果，然后呢？

信息收集最容易做成「收集」——把能跑的工具跑一遍，能爬的链接爬一遍，导出一张表。表很完整，但拿起来不知道从哪看。

收集的目的不是收集

它的目的是把「这个站可能有什么问题」这个几乎无限大的可能性，收窄到几条可以验证的假设。

一个具体的差别：看到首页是 Vue 单页应用，接口全在打包后的 JS 里。这时候不该去跑目录扫描——SPA 根本没有目录，扫出来的全是 200 的空壳。该做的是翻 JS 里的接口清单。

同样是「收集」，一个是按工具列表执行，一个是按目标形态决定。

假设比字典值钱

知道对方是 Spring Boot，就去试 /actuator/env，三个请求，命中率不低。

不知道是什么，拿十万条字典轰，跑一晚上，命中率还更低。

这不是说字典没用，是说字典该在「假设验证失败之后」用，而不是当作起点。顺序反了，时间就花在了不该花的地方。

什么时候算够了

一个可用的标准：你能画出「用户请求从外网进来，经过什么，到达什么」这条链路，并且能标出每一跳归谁管。

画不出来，说明还缺东西。画出来了，就可以停下来，开始验证。

收集阶段省下的判断，会在后面以反复试错的形式还回来，还带利息。

完整的方法在信息收集那一章，这里只留这一条。