毕业设计实战：构建高可用分布式漏洞扫描系统

1. 项目概述与核心价值

做毕业设计，选“漏洞扫描工具”这个方向的同学，眼光是相当不错的。这不仅仅是一个能让你顺利通过答辩的课题，更是一个能让你在简历上留下扎实一笔的实战项目。为什么这么说？因为“漏洞扫描”是网络安全领域的刚需，从企业安全运维到渗透测试，再到安全开发流程（DevSecOps），它都是基础且核心的环节。一个完整的、从需求分析到高可用部署的扫描工具项目，能让你系统地走完一个产品从0到1的完整生命周期，这其中的经验，远比单纯实现一个算法或者一个单机版的小工具要宝贵得多。

这个项目标题拆解开来，包含了几个关键阶段：需求分析、工具设计与实现、高可用部署。它要求你不仅仅是一个会写代码的程序员，更要具备产品思维、架构思维和运维思维。你需要思考：扫描工具给谁用？在什么场景下用？要扫什么？怎么扫得又快又准又不把目标扫崩？最后，如何让它7x24小时稳定可靠地运行？这些问题，正是企业里实际在做的事情。通过这个毕设，你能摸到安全研发、SRE（站点可靠性工程）甚至部分安全运营的门道，对于想进入安全行业或者提升工程能力的同学来说，价值拉满。

接下来，我将以一个“过来人”和项目实践者的角度，带你完整走一遍这条路径。我会重点分享那些在教科书和官方文档里不会写的“坑”和“技巧”，让你不仅能做出项目，更能理解每一步背后的“为什么”。

2. 需求分析：定义你的扫描器灵魂

需求分析是项目的基石，这一步没想清楚，后面代码写得再漂亮也是空中楼阁。很多同学一上来就想着用哪个开源框架、实现什么炫酷的算法，这是本末倒置。我们先要把“做什么”和“为谁做”搞明白。

2.1 明确用户与核心场景

你的扫描器不是给自己玩的玩具，它必须有明确的用户画像和使用场景。通常，一个漏洞扫描工具可能面向以下几类用户：

1. 安全工程师/渗透测试人员：他们需要深度、灵活的扫描，支持自定义POC（漏洞概念验证）、复杂的认证绕过、以及详细的漏洞利用证明。他们对误报率容忍度低，但对漏报率极其敏感。
2. 研发团队/DevOps工程师：他们需要将扫描集成到CI/CD流水线中，在代码构建和部署阶段快速发现安全漏洞。他们需要的是速度快、反馈及时、能自动阻断不安全构建的能力。对漏洞的深度要求可能不如安全工程师，但必须稳定、自动化。
3. 系统运维/网络管理员：他们更关注资产发现、端口服务识别、以及公开的高危漏洞（如永恒之蓝）。他们需要定期对全网资产进行普查，操作简单，报告清晰，能快速定位风险点。

对于毕设项目，我建议你聚焦于一个核心场景。贪多嚼不烂。例如，你可以定位为“一个面向Web应用的、可用于CI/CD集成的轻量级漏洞扫描工具”。这样，你的需求边界就清晰了：主要扫描HTTP/HTTPS服务，重点检测OWASP Top 10漏洞（如SQL注入、XSS），并提供API供Jenkins或GitLab CI调用。

2.2 功能性需求拆解

基于核心场景，我们可以拆解出必须实现的功能模块：

• 资产发现与识别：输入一个域名或IP段，工具能自动发现存活主机、开放的端口及端口上运行的服务（如Nginx 1.18, Tomcat 9.0）。这里可以用masscan进行快速端口扫描，用nmap进行服务识别，或者用更轻量的socket编程结合banner抓取。
• 漏洞检测引擎：这是核心。你需要决定检测方式：
  • 基于特征（签名）的检测：维护一个漏洞特征库（如特定响应头、错误信息、参数模式）。优点是速度快，实现简单；缺点是对于逻辑漏洞、新型漏洞无能为力，误报和漏报都可能较高。
  • 基于爬虫的动态分析：内置一个爬虫（如定制化的Crawley或selenium）遍历网站所有链接和表单，然后对每个输入点（参数）插入测试载荷。这种方式能发现更复杂的交互漏洞，但速度慢，且对JavaScript渲染的页面处理困难。
  • 混合模式：毕设项目中比较务实的选择。对已知的、特征明显的漏洞（如目录遍历、敏感文件泄露）用特征检测；对SQL注入、XSS等需要交互验证的，用简单的动态测试（如发送'和<script>alert(1)</script>看响应差异）。
• 调度与并发控制：如何高效地扫描多个目标或一个目标的大量URL？你需要一个任务队列（如Redis+Celery）和线程池/进程池。这里有个关键点：并发控制。无脑开100个线程去扫一个网站，很可能直接把对方扫挂，或者触发对方的WAF封禁。必须实现速率限制（如每秒最多N个请求）、间隔延迟、以及错误重试机制。
• 报告生成：扫描结果不能只是一堆日志。需要生成结构化的报告，如JSON、HTML或PDF。报告里至少应包括：目标信息、漏洞列表（每个漏洞要有名称、风险等级、发现位置、请求/响应详情、修复建议）、扫描统计信息。

2.3 非功能性需求考量

这部分决定了你的工具是否“好用”和“耐用”，是体现工程能力的关键。

• 性能：扫描速度要多快？这取决于你的场景。CI/CD场景要求分钟级反馈；全量扫描可以接受小时级。你需要对关键路径（如网络请求、规则匹配）进行性能分析和优化。
• 准确性：如何降低误报和漏报？这是漏洞扫描器的世界性难题。对于毕设，你可以通过“二次验证”来降低误报。例如，特征匹配到一个疑似SQL注入点后，再发送一个精心构造的、能触发时间延迟或差异响应的Payload进行确认。
• 可扩展性：如何方便地添加新的漏洞检测插件（POC）？设计一个良好的插件架构，比如每个POC是一个独立的Python类或脚本，通过配置文件或自动发现机制加载。这样你的工具才能跟上漏洞更新的速度。
• 安全性：扫描器本身不能成为攻击者的跳板或泄露敏感信息。要确保：
  • 不存储敏感的扫描数据（如管理密码）。
  • 对用户输入（目标地址、配置参数）进行严格的校验和过滤，防止命令注入。
  • 扫描行为本身要可控，避免触发目标系统的防御机制导致法律风险（务必在授权范围内测试！）。

实操心得：需求分析文档不用写得像商业软件说明书那样复杂，但一定要有。用一个Markdown文件，清晰地列出上述要点，特别是“不做哪些”的范围界定。这能帮助你在开发过程中保持专注，防止功能蔓延。我曾见过一个同学的毕设，一开始只想做Web扫描，中途觉得端口扫描很酷加进去，后来又加了弱口令爆破，最后每个模块都没做深，答辩时被问得哑口无言。

3. 技术选型与核心模块设计

需求明确了，接下来就是选择合适的技术栈来落地。选型的原则是：成熟、高效、社区活跃、学习成本可控。不要为了炫技而选择过于冷门或复杂的技术。

3.1 整体架构设计

一个典型的、可扩展的漏洞扫描器可以采用“调度中心+引擎插件”的微内核架构。这非常适合毕设项目，结构清晰，模块解耦。

[用户界面/API] -> [任务调度中心] -> [消息队列] -> [扫描引擎集群] -> [结果存储] ^ | | v [报告生成] <----------------------------[数据聚合与分析]

• 用户界面/API层：提供Web界面或RESTful API来提交扫描任务、查看进度和结果。对于毕设，实现一个简单的Flask或FastAPI的API服务就足够了，前端可以用Vue/React写个管理页面，或者直接用curl和Postman测试。
• 任务调度中心：接收扫描请求，解析参数（目标、扫描类型、深度等），创建扫描任务，并将其放入消息队列。同时，它还负责监控任务状态、管理扫描引擎节点。
• 消息队列：解耦调度器和扫描引擎。使用Redis的List或Pub/Sub可以快速实现一个轻量级队列。如果需要更复杂的特性（如优先级、延迟任务），可以用RabbitMQ或Kafka，但对于毕设，Redis绰绰有余。
• 扫描引擎集群：一个或多个扫描引擎Worker，从消息队列中消费任务，执行具体的扫描逻辑。每个引擎可以加载不同的漏洞检测插件。集群化是实现高可用和横向扩展的基础。
• 数据存储：存储扫描任务元数据、原始结果、资产信息等。可以用MySQL或PostgreSQL存储关系型数据，用Elasticsearch存储日志和扫描详情以便检索。毕设项目用SQLite+JSON文件起步也未尝不可，但要说明这是为了简化，生产环境需升级。

3.2 核心模块技术选型

• 编程语言：Python是绝对的首选。它在网络安全领域有极其丰富的库支持（requests,scapy,beautifulsoup4,sqlmap的部分代码可参考思路），开发效率高，易于实现原型。Go语言在并发和性能上更有优势，但生态和开发速度可能对毕设时间不友好。
• 网络请求与爬虫：
  • requests+urllib3：处理HTTP请求的基础，务必配置连接池、超时、重试和代理。
  • aiohttp/httpx：如果你要实现高性能的异步扫描，这两个库是必选。它们能让你用少量的线程并发处理成千上万个HTTP请求，极大提升扫描速度。
  • selenium/playwright：用于处理需要JavaScript渲染的复杂单页应用（SPA）。但它们是重量级的，会启动浏览器实例，速度慢、资源消耗大。慎用，除非你的核心需求就是处理这类应用。
• 漏洞检测规则：可以自己写YAML或JSON格式的规则文件。参考nuclei模板的格式是不错的选择，它结构清晰，包含了请求、匹配条件、提取信息等部分。例如，一个检测phpinfo文件泄露的规则可以很简单：

  id: phpinfo-exposure info: name: PHPInfo Exposure severity: medium requests: - method: GET path: - "{{BaseURL}}/phpinfo.php" matchers: - type: word words: - "PHP Version" - "Configuration" condition: and

• 任务队列与并发：
  • Celery+Redis：Python生态下最经典的任务队列方案，功能强大，支持定时任务、重试、结果回溯。但配置稍复杂。
  • RQ(Redis Queue)：比Celery更轻量，API更简单，对于毕设项目可能更合适。
  • 原生concurrent.futures模块：如果你的扫描器是单机版，不需要分布式，直接用Python标准库里的ThreadPoolExecutor或ProcessPoolExecutor实现并发控制是最快的方式。

避坑指南：在技术选型时，最容易犯的错误是“过度设计”。不要一上来就想着搞微服务、搞K8s。从一个单机版、多线程的扫描器开始，把核心的扫描逻辑和规则引擎跑通。然后再考虑如何把它拆分成调度器、引擎Worker，如何引入消息队列。循序渐进，每一步都有可运行的成果，你的信心和项目的可控性会强很多。

4. 核心扫描引擎的实现细节

引擎是扫描器的心脏，我们重点讲几个关键部分的实现思路和代码层面的技巧。

4.1 智能爬虫：不只是抓链接

一个只会抓取<a href>的爬虫对于现代Web应用是远远不够的。

1. 表单自动填写与提交：你需要解析<form>标签，识别input,select,textarea，并尝试填充测试数据。对于隐藏字段（type="hidden"）要保留其原始值。
2. JavaScript链接提取：简单的正则表达式匹配window.location或<a onclick>里的链接是低效且不可靠的。更高级的做法是使用无头浏览器（playwright），但重量级。折中方案是使用jsbeautifier之类的库简单解析JS文件，提取可能的URL字符串，但这仍有局限。对于毕设，可以明确声明对JS生成链接的支持有限，这是一个已知的改进点。
3. 避免爬虫陷阱：要检测并避免无限循环，例如通过查询参数?page=1&page=2...生成的日历链接。可以设置最大深度、最大页面数限制，并对URL进行规范化（去除无关参数、排序参数）后再进行去重判断。
4. 会话与状态管理：很多漏洞（如越权访问）需要在登录态下才能检测。你的爬虫需要支持维护Cookie会话，并能模拟登录流程。可以设计一个“登录插件”，让用户预先配置登录的API和凭证，爬虫先执行登录，获取并保存会话。

# 一个简化的爬虫核心循环示例 import asyncio import aiohttp from urllib.parse import urljoin, urlparse from bs4 import BeautifulSoup class SimpleCrawler: def __init__(self, start_url, max_depth=3): self.start_url = start_url self.max_depth = max_depth self.visited = set() self.session = None self.base_domain = urlparse(start_url).netloc async def crawl(self): async with aiohttp.ClientSession() as self.session: await self._crawl_page(self.start_url, depth=0) async def _crawl_page(self, url, depth): if depth > self.max_depth or url in self.visited: return self.visited.add(url) try: async with self.session.get(url, timeout=10) as response: html = await response.text() # 1. 将当前URL和响应交给漏洞检测模块 await self.scan_for_vulns(url, response, html) # 2. 解析HTML，发现新的链接 if depth < self.max_depth: soup = BeautifulSoup(html, 'html.parser') new_urls = self._extract_links(soup, url) tasks = [self._crawl_page(new_url, depth+1) for new_url in new_urls] await asyncio.gather(*tasks) except Exception as e: print(f"Error crawling {url}: {e}") def _extract_links(self, soup, base_url): urls = set() for tag in soup.find_all(['a', 'link'], href=True): href = tag['href'] full_url = urljoin(base_url, href) if urlparse(full_url).netloc == self.base_domain: # 限制同域名 urls.add(full_url) # 同样需要处理 <form action>, <script> 等 return urls async def scan_for_vulns(self, url, response, html): # 这里是调用漏洞检测插件的地方 # 例如：检测响应头中是否包含敏感信息 if 'X-Powered-By' in response.headers: self.report_finding(url, "信息泄露", f"服务器信息: {response.headers['X-Powered-By']}") # 检测HTML中是否包含常见备份文件关键词 if '.bak' in html or '.sql' in html: self.report_finding(url, "敏感文件泄露", "页面内容中包含疑似备份文件关键词")

4.2 漏洞检测插件化设计

插件化是保证扫描器生命力的关键。设计一个简单的插件接口：

# vuln_plugins/base.py class VulnPluginBase: """漏洞插件基类""" plugin_name = "base_plugin" severity = "info" # low, medium, high, critical def __init__(self, target_url, session): self.target_url = target_url self.session = session # 共享的aiohttp session async def check(self): """执行检测，返回布尔值表示是否发现漏洞，以及详细信息""" raise NotImplementedError def generate_report(self): """生成漏洞报告片段""" return { "plugin": self.plugin_name, "severity": self.severity, "url": self.target_url, "detail": "" } # vuln_plugins/sql_error_based.py class SqlErrorPlugin(VulnPluginBase): plugin_name = "sql_error_detection" severity = "high" async def check(self): test_payloads = ["'", "\"", "' OR '1'='1"] for payload in test_payloads: test_url = f"{self.target_url}?id={payload}" try: async with self.session.get(test_url) as resp: text = await resp.text() # 简单的错误信息匹配，实际中需要更精细的规则 error_keywords = ["SQL syntax", "MySQL", "ORA-", "Unclosed quotation mark"] if any(keyword in text for keyword in error_keywords): self.found_payload = payload self.error_snippet = text[:200] # 截取部分错误信息 return True except Exception: continue return False def generate_report(self): report = super().generate_report() report["detail"] = f"疑似SQL注入点（基于错误回显）。测试载荷：{self.found_payload}。错误信息片段：{self.error_snippet}" return report

然后，在扫描引擎中动态加载所有插件：

# engine/scanner.py import importlib import pkgutil import vuln_plugins class ScannerEngine: def __init__(self): self.plugins = [] self._load_plugins() def _load_plugins(self): package = vuln_plugins for _, module_name, _ in pkgutil.iter_modules(package.__path__): module = importlib.import_module(f"{package.__name__}.{module_name}") for attr_name in dir(module): attr = getattr(module, attr_name) if isinstance(attr, type) and issubclass(attr, VulnPluginBase) and attr != VulnPluginBase: self.plugins.append(attr) async def scan_url(self, url, session): findings = [] for PluginClass in self.plugins: plugin = PluginClass(url, session) if await plugin.check(): findings.append(plugin.generate_report()) return findings

4.3 精准的漏洞验证与误报控制

误报是扫描器的“毒瘤”。一个整天“狼来了”的工具很快会被弃用。除了前面提到的二次验证，还有一些技巧：

• 差异对比（Diff）：对于盲注或条件响应的检测，不能只看返回了错误信息。应该发送一个正常请求和一个带Payload的请求，对比两者的响应状态码、长度、内容（可以计算哈希）。只有存在统计学上的显著差异时，才认为是潜在漏洞。
• 时间延迟检测：对于时间盲注，发送sleep(5)这样的Payload，然后精确测量响应时间。要注意网络抖动，需要设置一个合理的阈值（如比基准响应时间多3秒以上）。
• 上下文感知：检测XSS时，Payload"><script>alert(1)</script>被插入到HTML标签内和插入到JavaScript代码块中，利用方式完全不同。简单的关键词匹配会漏报或误报。需要分析Payload插入点的上下文（是HTML属性、文本节点还是<script>标签内），并生成对应的测试Payload。
• 指纹识别前置：在扫描一个目标前，先识别其使用的技术栈（如WordPress, ThinkPHP, Spring Boot）。然后只加载针对该技术栈的漏洞插件，可以大幅提高效率和准确性。可以用Wappalyzer这样的开源库或简单的正则规则来实现指纹识别。

实操心得：实现漏洞检测逻辑时，永远不要在生产环境或未授权的目标上测试你的扫描器。搭建一个自己的“靶场”至关重要。推荐使用DVWA、WebGoat、vulhub或自己用存在漏洞的旧版本CMS搭建测试环境。这样你可以安全地验证你的检测逻辑是否有效，同时也能积累大量的测试用例。

5. 高可用与可扩展部署方案

一个只能跑在自己笔记本上的扫描器是没有实用价值的。高可用部署确保你的服务稳定、可靠、能够处理大规模扫描任务。

5.1 从单机到分布式

我们之前设计的“调度中心+引擎Worker”架构天然支持分布式。部署的核心是让多个引擎Worker可以并行工作。

1. 容器化：使用Docker将你的调度器、引擎Worker分别打包成镜像。这保证了环境一致性，也简化了部署。Dockerfile里要写好Python环境依赖、项目代码的拷贝。

   # 引擎Worker的Dockerfile示例 FROM python:3.9-slim WORKDIR /app COPY requirements.txt . RUN pip install --no-cache-dir -r requirements.txt COPY . . CMD ["python", "worker.py"]

2. 使用Docker Compose编排：在开发或小规模部署时，docker-compose.yml可以一键启动所有服务。

   version: '3' services: redis: image: redis:alpine ports: - "6379:6379" scheduler: build: ./scheduler depends_on: - redis environment: - REDIS_HOST=redis ports: - "5000:5000" # API端口 worker: build: ./engine depends_on: - redis environment: - REDIS_HOST=redis - WORKER_QUEUE=scan_tasks deploy: replicas: 3 # 启动3个Worker实例

3. 任务队列与结果回传：Worker从Redis队列中获取任务，执行完毕后，将结果写回Redis的另一个结果队列，或者直接写入数据库。调度器监听结果队列，更新任务状态。

5.2 实现负载均衡与故障转移

• Worker水平扩展：当任务积压时，你只需要增加worker服务的副本数（docker-compose up --scale worker=5）。任务队列会自动将任务分发给空闲的Worker。
• 调度器高可用：调度器（API服务）可以部署多个实例，前面用Nginx做负载均衡。但要注意，如果调度器有状态（比如在内存中维护任务映射），就需要将会话或状态存储到外部（如Redis），实现无状态化。
• 健康检查与自愈：在Docker Compose或K8s中，可以配置容器的健康检查（healthcheck）。如果Worker进程卡死或崩溃，编排工具会自动重启容器。你还需要在Worker代码中加入心跳机制，定期向调度器报告“存活”，调度器可以将长时间无心跳的Worker标记为失效，并将其任务重新放入队列。

5.3 监控、日志与告警

一个看不见的服务是危险的。你需要知道它是否在运行、跑得怎么样、有没有出错。

• 日志聚合：将调度器、各个Worker的日志统一收集起来，方便排查问题。可以用ELK栈（Elasticsearch, Logstash, Kibana）或更轻量的Loki+Grafana。最起码，要把日志输出到标准输出（stdout），然后由Docker收集。
• 指标监控：监控关键指标，如：任务队列长度（堆积情况）、Worker活跃数、平均任务处理时间、API请求成功率、系统资源（CPU、内存）使用率。可以使用Prometheus来收集指标，用Grafana制作仪表盘。Python应用可以通过prometheus_client库暴露指标。
• 告警：当关键指标异常时（如队列堆积超过100、Worker全部失活、API错误率飙升），需要及时告警。可以将告警发送到钉钉、企业微信或邮件。Prometheus的Alertmanager可以很好地完成这个工作。

部署避坑指南：

1. 配置文件管理：不要将数据库密码、API密钥等敏感信息硬编码在代码或镜像里。使用环境变量或外部的配置文件（如通过Docker的secrets或K8s的ConfigMap/Secret）来管理。
2. 数据库连接池：如果你的Worker直接写数据库，一定要使用连接池，并妥善处理连接断开和重连。否则在高并发下，数据库连接数会被打满。
3. 扫描速率限制全局化：在分布式环境下，多个Worker同时扫描同一个目标，即使每个Worker自身做了限速，合起来也可能超过目标承受范围。需要在调度器层面实现全局的、针对每个目标的速率限制令牌桶。
4. 结果去重：多个Worker可能扫描到同一个URL的同一个漏洞。在结果入库前，需要根据“目标+漏洞类型+位置”做一个去重判断。

6. 项目展示、优化与答辩要点

把代码跑起来只是成功了一半，如何展示和讲述你的项目，决定了答辩的成败。

6.1 构建完整的演示闭环

准备一个清晰的演示脚本：

1. 环境启动：一键启动所有服务（docker-compose up），展示服务健康状态（可以做个简单的状态监控页面）。
2. 提交扫描任务：通过你开发的Web界面或API（用curl或Postman演示），提交一个对自建靶场（如DVWA）的扫描任务。
3. 实时展示进度：演示任务队列的消费情况、Worker的工作日志（可以tail -f日志文件，或者展示一个动态更新的任务进度条）。
4. 查看扫描报告：任务完成后，展示生成的HTML或JSON报告。重点指出发现的几个典型漏洞（如SQL注入、XSS），并点击报告中的链接，可以跳转到靶场对应的漏洞页面进行验证（手动触发一个alert弹窗），这是非常有力的证明。
5. 高可用演示（可选但加分）：模拟一个Worker故障（docker stop一个worker容器），展示调度器如何将未完成的任务重新分配给其他Worker，服务不中断。

6.2 性能优化与深度扩展方向

在答辩时，老师可能会问“你的工具和Nessus/OpenVAS比有什么优势？”或者“哪里可以改进？”。你不能说“我做的简单”，而要展示你的思考。

• 性能优化：
  • 异步I/O：你已经用了aiohttp，可以强调这相比多线程模型，在I/O密集型（网络请求）的扫描任务中，能极大提升并发能力和资源利用率。
  • 连接复用：保持HTTP长连接，避免每次请求都进行TCP三次握手。
  • 智能调度：将针对同一域名的多个URL任务分配给同一个Worker，可以复用DNS解析结果和TCP连接。
  • 规则优化：对漏洞规则进行优先级排序，先运行速度快、命中率高的规则。对目标进行指纹识别后，只运行相关的规则集。
• 深度扩展方向：
  • 分布式爬虫：将爬虫任务也分布式化，一个主节点负责URL去重和调度，多个爬虫节点并行抓取。
  • 漏洞情报集成：接入CVE、CNVD等漏洞库，当识别出目标组件版本时，自动关联已知的公开漏洞。
  • 交互式漏洞验证：对于某些漏洞，提供“一键验证”功能，在用户授权下，安全地执行更深入的探测以确认漏洞是否存在及可利用性。
  • 与DevOps平台深度集成：开发GitLab CI/CD插件、Jenkins插件，让研发人员在代码合并请求时就能看到安全扫描结果。

6.3 答辩核心要点与常见问题

• 讲清楚架构图：准备一张清晰的架构图（可以用draw.io画），展示调度器、消息队列、Worker、数据库之间的关系和数据流。这是你系统设计能力的直观体现。
• 突出你的工作量与创新点：
  • 工作量：实现了多少个漏洞检测插件？支持哪些类型的漏洞？爬虫有哪些特性？设计了怎样的插件系统？
  • 创新/亮点：也许你的扫描算法不是最新的，但你的插件化设计、基于异步IO的高性能引擎、考虑周全的速率限制和错误处理机制、完整的高可用部署方案，这些都是扎实的工程实践亮点。
• 准备好回答以下问题：
  • 你是如何降低误报率的？（结合二次验证、差异对比、上下文感知来回答）
  • 你的扫描器会不会把目标网站扫挂？（回答你实现的速率限制、并发控制、友好爬虫策略）
  • 如果扫描过程中某个Worker崩溃了怎么办？（回答任务队列的机制：任务会重新入队，由其他Worker处理）
  • 如何添加一个新的漏洞检测规则？（演示你的插件编写模板和加载机制）
  • 你的工具和开源项目（如sqlmap, nuclei）有什么区别？（强调你的项目是一个完整的、工程化的、可部署的扫描系统，而它们更多是单点工具或引擎；你的重点在于整合、调度、部署和易用性）

最后，记住毕业设计的核心是展示你分析问题、设计系统、实现方案、解决难点的完整能力。“漏洞扫描工具”这个项目为你提供了一个绝佳的舞台。从需求到部署，这条完整路径走下来，你已经不是一个简单的脚本小子了，而是一个有产品思维和工程能力的准工程师。把每一步的思考和实践都清晰地呈现出来，你的答辩一定会非常出彩。