1. 为什么我最终把 ZAP 留在了工具箱里
第一次接触漏洞扫描这个方向的时候，我手里其实有好几款工具，商业的、开源的都试过一轮。折腾了大半年之后，OWASP ZAP 成了我每台工作机上必装的常驻软件。原因说出来很朴素：它免费、开源、跨平台，而且从纯手工的代理抓包到全自动的主动扫描，都能在一个界面里完成，不需要在五六个工具之间来回倒腾数据。对于刚入门 Web 安全测试的人，或者团队里需要一个能快速对自家系统做一轮体检的开发者来说，这个特性其实比很多花哨的功能更值钱。
这篇文章我打算把 OWASP ZAP 从下载、安装到真正能用起来打一轮扫描的完整路径讲清楚。我会按我自己的实际操作顺序来写，包括各个系统的安装方式、代理和证书怎么配、被动扫描和主动扫描分别怎么开、认证站点和带文件上传接口的站点怎么处理、报告怎么出、以及我在实际使用中踩过的那些坑。不管你之前有没有用过类似工具，跟着走一遍，基本能独立跑通一套完整的扫描流程。
需要先把一件事说在前面：这类工具只能用于你自己拥有产权、或者已经拿到明确书面授权的目标。未经授权对第三方系统发起扫描，性质上和入侵没区别，这一点没有任何模糊空间。我们做的所有测试，都建立在授权范围内。
1.1 从手工点测到自动化扫描的转折
早些年我做测试基本靠手工，浏览器开个代理，一个个接口点过去，看返回、看参数、看错误信息。这种方式对业务逻辑的把握最准，但覆盖面受限于人的精力，一天能认真过完的接口数量有限。真正让我改变工作方式的，是一次给内部系统做安全评估，几百个接口靠手工根本跑不完，我才认真去研究自动化扫描工具的用法。
自动化扫描的价值不在于替代人工，而在于把那些重复度高、规则明确的检查项批量跑掉。比如响应头里缺失的安全策略、Cookie 没打 HttpOnly、反射型输入未过滤、目录列表暴露这类问题，工具几秒钟就能扫完一个站点，人去做这些纯属浪费。而 ZAP 的被动扫描机制有个我很喜欢的设计：它在代理流量经过的时候顺带做检查，不对目标发起额外的攻击性请求，所以哪怕在相对敏感的环境里做初步摸底，风险也可控。等摸底有结果了，再针对性地开主动扫描。
1.2 ZAP 和同类工具的定位差异
市面上做 Web 漏洞扫描的工具不少，各有各的脾气。有些工具偏向于大规模资产测绘，一次性喂几千个域名做批量探测；有些偏向于深度利用，能直接打出利用链。ZAP 的定位更偏向"交互式测试助手"，它既能当一个抓包代理用，也能在你在浏览器里正常操作业务的同时，后台持续分析流量并给出告警。
这个差异带来的实际影响是：ZAP 更适合在测试某个具体业务系统的过程中使用，边测边看告警，而不是丢一个域名列表进去等结果。它提供的四种模式——安全模式、保护模式、标准模式、攻击模式——也体现了这种思路。安全模式完全不发任何可能造成影响的请求，攻击模式则放开所有主动扫描能力。你可以根据测试阶段的推进，逐步把权限放开。这种渐进式的工作方式，我认为比"一键扫描"更符合真实项目的节奏。
1.3 谁适合从这篇内容入手
如果你是开发人员，想在上线前给自己的接口做一轮基础体检，这篇内容能帮你把环境搭起来并跑通第一轮扫描。如果你是刚转做安全测试的新人，ZAP 是理解"漏洞扫描到底在扫什么"的绝佳入口，因为它的告警里会附带请求、响应、参考链接，你能顺着看到问题到底出在哪一行流量上。如果你已经在用 Burp 之类的工具，ZAP 的自动化能力和命令行接口可以作为补充，特别是在需要把扫描塞进流水线的场景里。基础不同，重点不一样，但路径是同一套。
2. 下载与安装：各系统的落地方案
安装这一步看着简单，实际上不同系统、不同方式装出来的 ZAP，功能可用性和后续维护成本差别不小。我按平台分开讲，你对照自己的环境挑一种走就行。
2.1 先确定版本和运行环境
ZAP 是 Java 写的，所以运行依赖 JDK。官方提供的安装包里，Windows 版本一般自带了运行时，macOS 和 Linux 的安装包也大多内置了 JRE，正常安装不需要你单独配 Java 环境。但如果你是下载的纯压缩包版本，或者想用命令行无界面模式，那就得确保系统里有可用的 Java 运行时。我的习惯是统一装一个较新版本的 JDK，然后在启动脚本里显式指定，避免系统里多个 Java 版本互相干扰导致启动失败。
版本选择上，官方发布分为稳定版和每日构建版。日常使用闭眼选稳定版，功能经过一轮轮验证，出问题的概率低。每日构建版主要是给需要尝鲜新检测规则的人用的，稳定性不敢保证。下载的时候留意页面上的版本号和发布日期，别拿到一个放了两年的旧包。
提示：无论哪个平台，下载完成后建议核对一下官方给出的校验值，确认文件在传输过程中没被篡改。这一步很多人会跳过，但作为安全从业者，自己用的工具来源是否可信，恰恰是最该较真的地方。
2.2 Windows 下的安装步骤
Windows 是我周边同事用得最多的环境，安装流程也最省心。从官方页面拿到.exe安装包后，双击运行，安装向导会依次问安装路径、是否创建桌面快捷方式、是否关联相关文件类型。路径里我建议不要带中文和空格，虽然现在的版本对中文路径容忍度提高了，但早些年出现过插件加载路径含中文时解析异常的情况，避开了省心。
安装完成后第一次启动，会弹出一个窗口问你以哪种模式运行，以及是否要持久化会话。持久化会话的意思是，本次抓到的所有流量和扫描结果会被保存成一个 session 文件，下次打开还能接着看。如果你在做持续几天的项目，建议开启；如果只是临时试一下，不持久化更清爽，退出就不留痕。这里的选择后面可以在界面里改，不用太纠结。
安装过程中如果遇到防火墙弹窗询问是否允许程序通信，记得放行，否则 ZAP 的本地代理端口可能被拦住，浏览器连不上来。另外，Windows Defender 有时会对安装包里的某些组件报可疑，这是安全软件对抓包类工具的常见误报，确认来源可信后按提示处理即可。
2.3 Linux 与 macOS 的安装方式
Linux 下最常见的是两种路子。一种是下载官方提供的.tar.gz包，解压后直接运行目录里的启动脚本，好处是不污染系统包管理，卸载就是删目录，干净利落。另一种是通过发行版仓库或者第三方仓库安装，好处是能跟着系统更新，坏处是版本往往落后官方好几个小版本，有些新检测规则用不上。我一般用解压包的方式，在/opt下放一个目录，然后建一个软链接指向可执行脚本，这样版本升级时只需要换链接。
macOS 用户比较省事，官方提供.dmg镜像，挂载后把应用拖进应用程序目录就行。需要注意的是，如果系统提示"无法验证开发者"，需要在安全性与隐私设置里手动允许一次。另外 macOS 上通过 Homebrew 也能装，命令一行搞定，适合习惯用包管理器的用户。命令行版本在这两个系统上都很常用，尤其是要集成到自动化任务里的时候，后面讲命令行的时候会细说。
2.4 用容器跑一套临时环境
如果你的机器上不想长期装这个软件，或者需要在一台服务器上临时起一套扫描环境，容器是个很省事的方案。拉取官方镜像后，把界面端口和代理端口映射到宿主机，就能通过浏览器访问 Web 界面来操作，也能直接连容器暴露出来的代理端口。
# 拉取官方镜像 docker pull zaproxy/zap-stable # 以交互方式启动，映射界面和代理端口 docker run -u zap -p 8080:8080 -p 8090:8090 -i zaproxy/zap-stable zap-webswing.sh这里 8080 通常对应界面访问端口，8090 对应代理端口，具体以镜像文档为准。容器方式的好处是环境隔离彻底，扫描完把容器删掉，宿主机上不留任何东西。坏处是网络配置稍微绕一点，尤其是你想让它扫描宿主机上跑的本地服务时，需要处理容器网络地址的问题。我一般会把待测服务也放进同一个自定义网络里，通过服务名互访，能避开不少地址困惑。
3. 第一次打开界面的正确姿势
装好之后别急着点扫描按钮，先把界面和几个核心概念理一遍，能省掉后面大量返工。ZAP 的界面元素不算少，但真正天天打交道的就是那几块。
3.1 四种模式的区别与切换时机
前面提到过模式的概念，这里展开说。安全模式下，ZAP 不会发起任何可能对目标造成影响的请求，连主动扫描都会被禁用，适合在生产环境或者不允许有任何扰动的情况下做纯被动观察。保护模式类似，但它会允许你手动发起一些请求，只是自动化的攻击行为被限制。标准模式是默认档，被动扫描全开，主动扫描需要你手动触发。攻击模式则把限制全放开，包括那些可能触发告警、写入数据、造成服务压力的检测项。
我自己的用法是：前期摸底用标准模式，确认目标环境是测试环境、且授权范围明确之后，再切到攻击模式做深度扫描。切换的位置在工具栏上，点一下就能改，但改之前一定要想清楚当前目标是不是能承受攻击性请求。很多线上系统对异常请求很敏感，一个不小心的主动扫描就可能把服务打挂，这个责任得自己扛。
3.2 核心面板的功能拆解
界面左侧是站点树，随着你浏览目标，所有被访问过的目录和接口会以树状结构列出来，这是你后面选择扫描范围的主要依据。中间上方一般是请求和响应面板，选中某个节点就能看到具体的流量内容。中间下方是历史记录，记录了所有经过代理的请求，支持按方法、状态码、URL 关键词过滤，找特定接口的时候非常方便。
右侧那块是告警面板，被动扫描发现的问题会实时往这里堆。每条告警点开，能看到风险等级、置信度、涉及的参数、请求响应证据，以及一段说明和参考链接。我强烈建议新手把每条告警的说明都读一遍，这是理解漏洞成因的最快途径。底部是各种输出窗口，扫描进度、脚本日志、报错信息都在这儿。
注意：历史记录里的信息量会随着浏览迅速膨胀，项目做久了 session 文件可能几个 G。定期清理或者分段保存，别让一个文件拖垮整个工具的响应速度。
4. 被动扫描：不动目标的第一层网
被动扫描是我最推荐新手先玩明白的功能。它不向目标发额外请求，只是分析流经代理的流量，所以几乎没有副作用。
4.1 代理配置与流量接管
要让 ZAP 看到流量，得让浏览器把请求发给它。ZAP 启动后会默认监听一个本地端口，标准模式下通常是 8080，具体以界面显示为准。然后在浏览器的代理设置里，把 HTTP 和 HTTPS 代理都指向127.0.0.1加这个端口。
更省事的做法是用浏览器插件来切换代理，比如给 Chrome 装一个代理管理插件，配置一个指向 ZAP 的代理配置，需要抓包时一键开启，平时关掉，互不影响。我习惯专门开一个干净的浏览器配置文件来做测试，不装日常插件、不登录个人账号，避免测试流量和私人流量混在一起，也避免会话信息互相污染。
配置好之后，在浏览器里访问目标站点，回到 ZAP 看历史记录，应该能看到请求一条条冒出来。如果一条都没有，先检查代理端口对不对、浏览器插件有没有生效、以及 ZAP 那边有没有弹出证书相关的拦截提示。
4.2 证书导入：绕不过去的一步
HTTPS 流量要被抓到，必须让浏览器信任 ZAP 生成的根证书。这一步不做，访问 HTTPS 网站时浏览器会直接报证书错误，流量也就抓不全。ZAP 提供了证书导出功能，在选项里找到证书相关设置，把根证书导出来保存成文件。
导入的方式各浏览器不同。以 Chrome 为例，可以在设置里找到证书管理，把导出的证书导入到"受信任的根证书颁发机构"下面。Firefox 有自己的证书库，需要在隐私与安全设置里单独导入。导入完成后重启浏览器，再访问 HTTPS 站点，看看 ZAP 的历史记录里能不能看到明文内容。能看到，说明证书链打通了。
这套证书是本地生成的，只在你自己的机器上有效，用完记得在不需要抓包的时候把代理关掉、把证书清理掉。有些同事图省事一直挂着代理，结果日常上网全部经过本地工具，体验和安全性都不好。
4.3 看懂被动扫描的告警
被动扫描的规则覆盖了很多常见的低风险问题，比如响应头缺少某些安全策略、Cookie 属性设置不当、页面里泄露了敏感的注释信息、错误页面暴露了技术栈版本等。这些单项看着不起眼，组合起来往往是攻击者做信息收集的起点。
告警面板里每条记录都有风险等级，从信息、低、中到高。我的建议是不要只盯着高危看，那些"信息"级别的告警经常能帮你发现一些意料之外的东西，比如某个接口返回了调试信息、某个路径下可以直接列出文件。这些内容在后续的主动扫描里可以作为重点输入。
提示：被动扫描的规则可以在选项里逐条开关，也能调整阈值。如果你的目标系统有大量误报，比如某类响应头是框架自动加的、实际不影响安全，可以针对性关掉对应规则，让告警列表更干净。但关之前一定要搞清楚那条规则到底在检查什么，别为了眼不见为净把真问题也关了。
5. 主动扫描：从爬虫到攻击面遍历
被动扫描看完流量就结束了，它的覆盖面取决于你手动点了多少页面。要系统性地遍历一个站点，就得用主动扫描，它包含两个关键环节：爬虫和攻击规则检测。
5.1 自动化扫描的完整流程
ZAP 提供了一个自动化扫描的入口，输入目标地址，它会自动完成爬虫、被动扫描、主动扫描的串联。对于结构简单、不需要登录的站点，这是最快的上手方式。流程大致是：先启动爬虫把站点内的链接、表单、参数都摸一遍，形成一张站点地图；然后对地图里发现的每个可测点，逐条跑主动扫描规则。
这里有个细节需要注意：自动化扫描默认不带认证信息，如果目标系统需要登录才能访问核心功能，那爬出来的地图基本是残缺的，扫出来的结果自然也没意义。带认证的站点怎么处理，下一节专门说。
主动扫描对目标是有压力的，它会尝试各种畸形输入、边界值、特殊字符组合。在共享环境或者资源紧张的服务上跑，可能造成响应变慢甚至短时不可用。所以跑之前跟相关方打个招呼，选低峰时段，是很基本的职业素养。
5.2 传统爬虫和 Ajax 爬虫怎么选
现代前端大量使用异步加载，页面点开时 HTML 里只有骨架，真正的内容靠接口异步拉取。传统爬虫只解析 HTML，遇到这种站点基本爬不出东西，站点地图会非常单薄。这时候就要用支持 Ajax 的爬虫，它会驱动一个真实的浏览器内核去执行页面脚本，等内容渲染出来再解析链接。
代价是速度慢很多，资源占用也高。我的策略是先用传统爬虫快速跑一遍，看看能覆盖多少；如果覆盖明显不足，再切到 Ajax 爬虫补齐。有些团队的做法是两者都跑一轮，结果取并集，覆盖率会更好，代价是时间翻倍。
# 命令行方式启动传统爬虫 zap-cli -p 8090 spider http://target.example.com # 启用 Ajax 爬虫需要先在界面里开启对应插件，命令行参数以实际版本为准5.3 扫描策略与阈值调优
主动扫描能测的规则非常多，全开跑一个大站点可能要几个小时甚至更久。实际项目里我会根据目标特点做取舍。比如目标是个纯静态展示站，那些针对数据库注入、命令执行的规则基本没发挥空间，可以适当精简；目标是个交互复杂的业务系统，表单和参数特别多，那就得留足时间让它跑完。
扫描策略可以在选项里新建或修改，针对不同强度的检查项设置启用与否。还有个容易被忽略的点是并发线程数，默认值在小型目标上够用，但目标服务性能强、你又有时间压力时，适当调高能明显缩短总时长。调高之前要确认目标扛得住并发，否则容易把服务压垮。
6. 认证扫描与文件上传接口的处理
这两块是实际项目里绕不开、又特别容易卡住新人的地方，我单独拎出来讲。
6.1 让扫描器带上登录状态
需要登录才能访问的功能，扫描器必须先拿到有效的会话。ZAP 提供的表单认证配置就是干这个的。你需要指定登录页面的地址、用户名和密码字段的名称、以及一个用来判断"登录是否成功"的标识。这个标识可以是一个只有登录后才出现的字符串，比如某个用户昵称，或者登录成功后跳转到的 URL 特征。
配置好之后，ZAP 会先发一次登录请求，拿到会话 Cookie 或 Token，后续所有扫描请求都带着这套凭据。判断标识设得准不准，直接决定扫描能不能正常进行。如果标识太宽松，登录失败时它也可能误判为成功，导致后续扫描全是在未登录状态下跑的。配置完记得用界面上的验证按钮测一下，确认能正确识别登录成功和失败两种状态。
注意：用来扫描的账号最好单独开一个，权限和普通用户一致，不要用管理员账号。扫描过程中可能触发密码修改、数据写入之类的操作，用专用账号能把影响圈在最小范围。
6.2 文件上传接口的检测思路
文件上传是 Web 系统里问题高发的功能点，也是很多实际案例的入口。OWASP ZAP 对这类接口的检查，主要围绕上传的类型限制、内容校验、存储路径和回显方式展开。要扫到这些，前提是爬虫得先发现上传表单，并且知道各个字段的含义。
实际操作里，上传接口往往需要先登录、先拿到某些动态令牌，甚至要经过多步操作才能到达。纯靠自动爬虫经常摸不到。我的做法是，先用代理把整个上传流程手工走一遍，让 ZAP 在历史记录里完整记录下这些请求，然后在历史记录里右键那个上传请求，选择针对性的扫描选项，把上传相关字段交给扫描器去测。
ZAP 有几个针对上传的检查插件，可以测试上传特殊构造的文件名、测试服务端是否依赖前端校验、检查返回内容里是否直接暴露了上传文件的访问路径。这些检查触发时，你会在告警里看到对应条目。需要提醒的是，上传测试有一定的副作用，可能真的往目标服务器上写文件，所以务必在测试环境进行，并且提前准备好清理方案。
6.3 上下文和用户会话的管理
当你要扫描的站点不止一个登录身份，或者有多个功能模块需要不同权限时，用"上下文"来组织会更清晰。一个上下文可以绑定一组 URL 范围、一套认证配置、一组会话管理规则。这样你在扫描 A 模块时不会误扫到 B 模块，不同身份的扫描结果也不会混在一起。
会话管理这块，有些系统用的不是简单的 Cookie，而是每次请求都要带一个动态计算的令牌，或者用 OAuth 之类的机制。遇到这种，ZAP 支持通过脚本来自定义会话处理逻辑。写脚本有一定门槛，但一旦搞定，后续所有扫描都能自动带上正确的凭据，省去大量手工维护的麻烦。
7. 报告输出与自动化集成
扫描跑完了，结果得能拿得出手、用得上，不然白跑。
7.1 报告类型和内容取舍
ZAP 支持导出多种格式的报告，常见的有 HTML、PDF、Markdown、XML、JSON。给人看的用 HTML 或 PDF，排版友好，能直接作为交付物；给机器处理的用 JSON 或 XML，方便接入其他平台做二次分析。
报告里通常会把告警按风险等级分组，每条包含描述、证据、请求响应、修复建议和参考链接。我的习惯是导出一份完整报告存档，再手工整理一份精简版给开发团队。精简版只保留确认存在的问题，去掉那些扫描器误报或者实际不可利用的条目，并附上复现步骤和修复优先级。开发同学看完整报告容易被几百条告警淹没，精简版更能推动问题落地。
7.2 命令行与流水线集成
命令行模式是 ZAP 真正体现工程价值的地方。它支持无界面运行，可以在服务器上定时执行扫描任务，把结果输出成文件，再通过脚本判断是否存在高危问题，决定是否阻断发布流程。
# 无界面模式下对指定目标做一次快速扫描，输出报告 zap.sh -cmd -quickurl http://target.example.com -quickout /tmp/zap-report.html # 需要更细粒度控制时，用配置文件方式加载一套预设的扫描策略 zap.sh -cmd -autorun /path/to/plan.yaml把扫描塞进持续集成流程，我踩过的一个坑是：一开始把扫描放在每次代码提交后触发，结果流水线时间被拉得很长，而且大量提交根本没触及被测接口，纯粹浪费资源。后来改成按天定时跑全量扫描，再加上针对改动模块的增量扫描，效率高了很多。另外一个经验是，首次接入时先只把高危问题设为阻断条件，等误报打磨干净了再收紧标准，否则开发团队会被误报折腾到对这套机制失去信任。
8. 常见问题与排查实录
这部分是我这些年攒下来的实际问题，按发生频率排序，配上我的处理思路。
8.1 扫不到内容、站点地图空得可怜
这是新手反馈最多的问题。排查顺序我一般是这样：第一，确认代理有没有生效，在 ZAP 历史记录里能不能看到流量，看不到就是代理配置或证书问题；第二，确认目标是不是需要登录，未登录状态下爬虫只能爬到公开页面；第三，确认站点是不是 Ajax 渲染的，传统爬虫爬不动，该换 Ajax 爬虫；第四，检查爬虫的作用域设置，是不是把目标域名排除在外了；第五，看看有没有 robots 文件或者前端路由把路径藏起来了。
还有一种情况是目标用了比较激进的反爬机制，识别到扫描器特征后返回空内容或者直接拒绝。这种就得上认证扫描，用真实登录态去访问，同时适当降低请求频率，模仿正常用户的操作节奏。
8.2 误报太多，告警列表没法看
误报是扫描工具的通病，ZAP 也不例外。处理思路分两层：一是确认哪些规则在你的技术栈下天然会误报，比如某些框架默认行为触发的、或者某些安全检查在前端做了但服务端不需要做的，这些可以在规则层面关掉；二是对每条误报做人工复核，确认它确实不可利用，然后在报告里标注说明。
我一般会建一个项目专属的规则配置，把误报规则的处理固化下来，下次对同类系统扫描直接复用，省去重复劳动。这个配置可以导出成文件，在团队里共享。
8.3 性能问题和资源占用
扫描大站点时 ZAP 可能吃满内存，界面卡顿甚至崩溃。处理方式有几个：调大启动脚本里的最大堆内存参数；扫描时用命令行模式而不是界面模式，省掉界面渲染的开销；把大站点拆成多个上下文分批扫描；定期清理历史记录和旧的 session 文件。
还有个隐蔽的坑是，如果代理同时被多个浏览器或爬虫共用，历史记录会迅速膨胀，表单和响应的缓存也会拖慢响应。给扫描任务单独开一个 ZAP 实例，别和日常抓包混用，能避免很多莫名其妙的问题。
8.4 常见问题速查表
| 现象 | 可能原因 | 处理方向 |
|---|---|---|
| 历史记录没有流量 | 代理未生效、端口不对、防火墙拦截 | 检查浏览器代理配置和本地端口监听 |
| HTTPS 站点报警告 | 根证书未导入或未信任 | 导出证书并导入到浏览器信任库 |
| 爬虫覆盖极少 | 目标为异步渲染、需要登录 | 启用 Ajax 爬虫、配置认证 |
| 扫描结果全是未登录状态 | 认证判断标识设置不当 | 用明确登录特征重新验证 |
| 上传接口扫不到 | 流程需多步操作、动态令牌 | 手工走一遍流程后针对请求扫描 |
| 扫描速度极慢 | 规则全开、线程数低、目标响应慢 | 精简规则、适度调高并发 |
| 内存占用过高 | 历史记录膨胀、堆内存不足 | 清理会话、调大堆参数、分批扫描 |
| 告警大量误报 | 规则与目标技术栈不匹配 | 复核后按项目关停对应规则 |
8.5 我踩过的几个具体坑
第一个坑是证书导入时只导入了顶层，没导入到受信任的根证书机构，导致浏览器一直提示不安全，流量抓不全，排查了半天才发现放错了位置。第二个坑是扫描时用了生产环境的账号，结果某些检测规则真的修改了数据，事后清理了好一阵。从那以后我坚持用专用测试账号，并且扫描前先确认目标环境。第三个坑是第一次做流水线集成时，把扫描结果直接当阻断条件，几十条误报把发布流程堵死了，后来改成先跑一段时间观察、人工梳理规则，再逐步收紧，才顺利落地。
还有一个容易被忽略的点：ZAP 的版本升级有时会改变默认规则集，升级后同样的目标扫出来的结果可能和之前不一样。升级前把当前的规则配置导出备份，升级后对比一下差异，能避免结果波动带来的困惑。
最后分享一个我常用的小技巧。对不熟悉的站点，我会先用标准模式配合被动扫描，手工把主要业务流程走一遍，让 ZAP 把流量吃全，然后停下来仔细看被动扫描的告警和站点地图。这一步基本能帮我摸清系统的大致结构、认证方式和可能的薄弱点。等心里有数了，再切攻击模式针对具体模块做主动扫描。这个"先摸后打"的节奏，比一上来就全自动扫描效率高得多，也更不容易把目标搞出问题。
