直接用threading启动多个爬虫会失控，因缺乏统一调度、异常捕获和状态管理；应改用ThreadPoolExecutor，配合理论最大worker数、结构化错误处理、线程安全状态队列与心跳检测机制。
为什么直接用 threading 启动多个爬虫会失控？
多任务并行不等于“开一堆线程就完事”。常见错误是为每个 URL 新建一个 threading.Thread，结果很快遇到连接超时堆积、DNS 阻塞、异常未捕获导致线程静默死亡，监控端根本收不到状态。真正可控的并行，得靠统一调度 + 可中断生命周期 + 状态透出。
建议用 concurrent.futures.ThreadPoolExecutor 替代裸线程：它内置任务队列、异常传播、shutdown(wait=True) 可控退出，且能通过 future.result(timeout=...) 实现单任务超时熔断。
- 设置
max_workers别超过 10（HTTP 爬取受系统文件描述符和远端限流制约，不是越多越快） - 每个任务必须包裹
try/except，把原始异常转成结构化错误信息（比如{"url": "...", "error": "TimeoutError", "status": "failed"}） - 避免在任务函数里直接 print —— 日志要走统一 handler，否则并发输出错乱
怎么让爬虫状态实时可查，又不拖慢主流程？
别用全局 dict 加锁轮询，更别用文件轮询。轻量级方案是起一个独立的 HTTP 接口（例如用 http.server 或 flask），把运行时状态存在线程安全的 queue.Queue 或 threading.local 绑定的字典里。
关键点在于“状态写入”和“状态读取”解耦：爬虫任务只往 queue.Queue 里 put 状态更新（如 {"url": "https://a.com", "status": "success", "elapsed": 1.23}），HTTP 接口从队列 dump 出最近 N 条并返回 JSON。这样即使接口被频繁请求，也不影响爬取主流程。
立即学习“Python免费学习笔记（深入）”；
- 队列 size 设为 100–500，避免内存无限增长
- HTTP 接口响应头加
Cache-Control: no-cache，防止浏览器缓存旧状态 - 如果用
flask，务必关闭调试模式（debug=False），否则多进程下状态不一致
requests 并发时 SSL 验证失败或连接复用失效怎么办？
默认 requests.Session() 在多线程下不是完全线程安全的 —— 尤其是连接池和 cookie 处理。常见现象是某几个请求突然报 SSLError: [SSL: DECRYPTION_FAILED_OR_BAD_RECORD_MAC]，或者复用的连接被其他线程意外 close。
解决方案是每个线程独享一个 Session 实例，并显式配置连接池参数：
session = requests.Session()
adapter = requests.adapters.HTTPAdapter(
pool_connections=10,
pool_maxsize=10,
max_retries=2
)
session.mount('http://', adapter)
session.mount('https://', adapter)
- 禁用 SSL 验证（
verify=False）仅用于测试，生产环境必须保留，否则中间人攻击风险真实存在 - 不要在 Session 上设全局
timeout，而是在每个session.get(..., timeout=(3, 7))中单独设（连接超时 + 读取超时分离） - 若目标站有反爬，User-Agent 必须每请求随机，且不能复用 Session 的 headers 字段（会跨请求污染）
监控系统如何判断某个爬虫“卡死”而非单纯慢？
单纯看响应时间不可靠 —— 有些页面就是渲染慢。真卡死的特征是：任务已提交但 future.done() 长期为 False，且无任何日志输出。需要额外加一层“心跳检测”。
做法是在每个爬取任务内启动一个子线程，每隔 5 秒向共享的 dict 写入当前时间戳（key 为任务 ID）；主监控线程定时扫描这个 dict，若某 key 对应的时间戳距今 > 30 秒，就标记为 “stuck”，并调用 future.cancel() 强制终止。
- 共享 dict 必须用
threading.RLock保护，否则并发写入会丢数据 - 取消后记得清理对应 Session 和连接，否则可能泄漏 socket
- “卡死”判定阈值要结合业务：API 类接口设 15 秒，前端渲染页可放宽到 60 秒
真正的难点不在并发模型本身，而在如何让每个任务既独立又可追溯、既快速又不崩远端、既上报状态又不拖垮自己 —— 这些边界条件，往往比写第一行 import requests 花的时间还多。
