使用concurrent.futures.threadpoolexecutor配合requests和模块化结构可高效实现中小规模爬虫，避免单线程阻塞；需设timeout=(3,7)、用set去重、伪造user-agent，并针对xss/sqli采用轻量隐蔽探测策略。
直接用 requests + 多线程 + 模块化结构就能跑起来，不需要 Django、Scrapy 或数据库——毕设或内测场景下，重框架反而拖慢验证节奏，80% 的误报和卡死都源于过度设计。
怎么避免单线程扫一个网站等两小时？
别用 for 循环串行发请求。Python 原生的 concurrent.futures.ThreadPoolExecutor 足够应付中小规模站点（50–200 个 URL）：
- 线程数控制在
min(32, os.cpu_count() * 4)，太多反而触发目标限流或本地端口耗尽 - 每个请求必须设
timeout=(3, 7)：3 秒连不上就放弃，7 秒收不到响应也中断 - 加一层简单队列去重：用
set()存已处理的urlparse.urljoin(base, path)归一化结果，避免/admin?sid=123和/admin?sid=456被当两个漏洞点扫两次
SQL 注入检测为什么总报错或漏报？
不是正则写得不够多，而是没绕过基础 WAF 和响应干扰。真实内测中，AND 1=1 这类 Payload 几乎必被拦截，得换更轻量、更隐蔽的探测方式：
- 优先用布尔盲注思路：对同一 URL 发两个请求，分别加
?id=1 AND 1=1和?id=1 AND 1=2，比对响应长度差是否 >150 字节（排除 HTML 注释/时间戳抖动） - 数据库报错关键词要带
re.IGNORECASE和边界符，比如匹配r'(?i)\bORA-\d{5}\b'，而不是模糊搜"oracle error" - 遇到返回
403或响应里含"blocked"/"waf"的站点，立刻跳过后续所有 Payload，别硬刚
为什么爬出来的链接扫不出 XSS？
因为只爬 <a href></a> 不够——XSS 真正高发点在表单参数、JSON 接口回显、URL Fragment 里。你得主动提取输入面：
- 用
BeautifulSoup解析页面时，同时抓input[name]、form[action]、script标签里的src和内联 JS 中的window.location.*拼接逻辑 - 对每个参数名（如
q、search、callback）单独构造?q=<img src="1" onerror="alert(1)">类 Payload，而不是只往 URL path 后硬塞 - 别依赖
alert(1)回显：有些站点会过滤括号或 script 关键字，改用<svg></svg>或 base64 编码绕过
最常被忽略的一点：所有 HTTP 请求头必须伪造 User-Agent，否则很多站直接返回 403；但别用太怪的 UA（比如 sqlmap），内测环境里一个常见浏览器 UA 就够用。工具跑起来后，先拿自己搭的 DVWA 或 WebGoat 验证三遍——不是看“有没有报漏洞”，而是看“报的漏洞能不能手动复现”。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
