Acunetix 装好后的渗透使用第一件事，是测试新建 Target。点左侧栏的工具 Targets，再点 Add Target，渗透使用把要测的测试 URL 填进去。这里有个坑：如果你填的工具是 https://example.com，它默认只扫这个域名下的渗透使用路径，子域名不会自动纳入。测试想覆盖全站，工具得在 Target 设置里手动把子域名加进去，渗透使用或者干脆用它的测试子域名扫描功能先跑一遍。

我一般会先跑一次 Crawl，工具不挂任何扫描策略。渗透使用Acunetix 的测试爬虫对 JavaScript 渲染的支持还行，但遇到 SPA 站点还是工具容易漏。有个小技巧：在 Scan 设置里把 Deep Scan 打开，它会多花点时间模拟点击，能多抓出一些动态生成的链接。上次测一个 Vue 写的后台，不开这个选项只爬到 12 个页面，开了之后翻到 47 个。

扫描策略的选择直接决定结果噪音量。默认的 Full Scan 会同时跑 SQL 注入、XSS、文件包含这些，对测试环境无所谓，但要是扫生产环境，建议先选 High Risk Vulnerabilities。我吃过亏——有回拿 Full Scan 扫客户线上系统，触发了 WAF 的速率限制，IP 被封了半小时，还得打电话让运维解封。后来学乖了，生产环境一律用 XSS 或 SQL Injection 单独跑，每次只开一种。

扫描过程中可以看实时日志。Acunetix 的日志分两块：一块是爬虫的 URL 队列，一块是攻击 payload 的发送记录。如果你发现某个参数一直在被反复测试，大概率是它认为那里有注入点但还没确认。这时候可以手动点开那个请求，看看响应里有没有数据库报错回显。有次扫一个 PHP 站点，日志里 id=1' 这个请求返回了 You have an error in your SQL syntax，Acunetix 却没标红——原因是它用的布尔盲注判断逻辑没触发。这种情况就得手动验证，别全信工具。

扫完之后看结果，别被 High 数量吓到。Acunetix 的误报率在商业扫描器里算中等偏上，尤其是 Blind SQL Injection 这类，经常把响应时间波动当成注入证据。我习惯先按 Confidence 排序，只盯着 Certain 级别的看。Tentative 的那些，点进去看请求和响应，如果 payload 里带了 sleep(5) 但响应时间只多了 0.3 秒，直接忽略。

导出报告时注意格式。Acunetix 默认的 PDF 报告会把所有漏洞混在一起，给开发看很不友好。我一般导 XML 或 CSV，然后用脚本按 URL 分组，同一个接口的漏洞归到一起。这样开发修起来不用来回翻页。有个客户的安全负责人特别喜欢这种分组方式，后来他们内部定了个规矩：Acunetix 的原始报告只存档，发给研发的必须是按接口聚合后的版本。

最后说个实操细节：Acunetix 的扫描速度跟目标响应时间强相关。如果目标服务器本身就很慢，比如一个请求要 2 秒才返回，那扫描时间会成倍增加。这时候可以在 Scan Speed 里把并发线程数调低，不然容易把目标打挂。我见过最极端的情况是一个老旧的 Tomcat 应用，默认并发下扫了 10 分钟就 502 了，降到 3 个线程才稳住。工具是死的，怎么用还是得看人。