360与百度大战实战项目源码解析避坑指南
配置环境就卡半天，是不是你的常态？很多开发者在复刻经典互联网案例时，往往死在“环境依赖”和“逻辑对齐”上，而不是代码本身。今天咱们聊的【360与百度大战】，并非指商业互怼，而是指在分布式爬虫与高并发搜索架构中，如何模拟两大巨头早期对抗中的核心策略：高可用、反爬对抗与数据清洗。这是一个极具代表性的【实战项目】，能帮你彻底理清从请求到存储的全链路细节。
别被名字吓到，这其实是一个基于Python的异步爬虫架构拆解。很多新手看到“大战”二字，以为要写什么复杂的对抗算法，其实核心在于稳定性与数据一致性。如果你曾在项目中遇到“明明代码没错，但跑着跑着就断连”或者“数据乱码”的问题，这篇源码解析能直接给你答案。
1. 入口定位：为什么选择这个架构作为实战项目
在早期的搜索引擎竞争中，百度与360（及其背后的奇虎）在技术路线上有着显著的差异。百度更侧重垂直领域的深度挖掘，而360在安全与反作弊层面有着独特的投入。在技术实现上，这映射为两个核心模块：并发调度器与数据清洗引擎。
对于初学者而言，直接去爬取真实站点不仅涉及法律风险，还因为目标站点的动态变化导致代码失效。因此，我们构建一个模拟的“双引擎对抗”环境。这里的核心痛点在于：如何在一个统一的框架下，处理两种不同反制策略的数据源。
在实际的【实战项目】中，我们常遇到这种情况：A站点使用简单的IP限制，B站点使用复杂的JS混淆或验证码。如果你的爬虫框架不能动态适配这两种策略，你的系统就会在“配置环境”或“初次运行”阶段频繁崩溃。这就是为什么我们要深入源码，而不是仅仅看API文档。
核心模块拆解
我们将整个系统分为三层：调度层：负责任务分发，模拟“兵分两路”的策略。
执行层：负责实际请求，包含重试机制与代理池切换。
处理层：负责HTML解析、去重与存储，模拟数据清洗。这种分层设计，正是当年两大搜索引擎在架构迭代中逐步形成的共识。虽然当时没有统一的行业标准，但基于 RFC 7231（Hypertext Transfer Protocol -- HTTP/1.1）规范定义的请求方法（GET/POST）与状态码处理，是构建任何稳定爬虫的基石。很多初学者忽略RFC规范中关于幂等性（Idempotency）的定义，导致重试请求时产生了重复数据，这是典型的“环境配置”之外的逻辑陷阱。
2. 核心片段：并发调度器的源码剖析
让我们直接看代码。以下是一个简化版的异步调度器，它模拟了“大战”中双方同时发起请求的场景。这里使用 asyncio 和 aiohttp，这是目前处理高并发IO最主流的方案。
import asyncio
import aiohttp
from dataclasses import dataclass, field
from typing import List, Dict, Any
import time
import random@dataclass
class CrawlTask:定义一个爬虫任务，模拟单个URL请求url: strsource: str # 'baidu' 或 '360'，模拟不同源retries: int = 3 # 默认重试次数headers: Dict[str, str] = field(default_factory=dict)class BattleScheduler:def __init__(self, max_concurrent: int = 50):self.max_concurrent = max_concurrentself.semaphore = asyncio.Semaphore(max_concurrent)self.active_tasks: List[CrawlTask] = []async def fetch_with_strategy(self, session: aiohttp.ClientSession, task: CrawlTask) - Dict[str, Any]:核心执行逻辑：根据来源策略执行请求这里模拟了不同站点的反制措施start_time = time.time()# 模拟网络延迟，真实项目中这是由网络环境决定的await asyncio.sleep(random.uniform(0.1, 0.5))# 模拟360站点的严格策略：检查User-Agentif task.source == '360' and 'User-Agent' not in task.headers:return {'status': 'blocked','reason': 'Missing User-Agent','latency': time.time() - start_time}# 模拟百度站点的宽松策略：允许匿名访问，但限制频率if task.source == 'baidu' and random.random() 0.1:# 10%的概率触发限流await asyncio.sleep(2.0) # 模拟等待return {'status': 'success','data': fContent from {task.source},'latency': time.time() - start_time}async def run_battle(self, urls: List[str]):入口方法：启动大战async with aiohttp.ClientSession() as session:tasks = []# 1. 任务初始化：交替分配任务给两个“阵营”for i, url in enumerate(urls):source = 'baidu' if i % 2 == 0 else '360'task = CrawlTask(url=url, source=source)tasks.append(self._execute_task(session, task))# 2. 并发执行：这里体现了“大战”的核心——并发竞争results = await asyncio.gather(*tasks, return_exceptions=True)# 3. 结果处理for result in results:if isinstance(result, Exception):print(fTask failed: {result})else:print(fTask done: {result['status']} in {result['latency']:.2f}s)async def _execute_task(self, session: aiohttp.ClientSession, task: CrawlTask):带重试机制的单任务执行这里处理了RFC 7231中定义的状态码逻辑async with self.semaphore: # 控制并发数，防止打爆服务器for attempt in range(task.retries):try:# 实际项目中这里是 await session.get(task.url)# 为了演示，我们直接调用模拟方法result = await self.fetch_with_strategy(session, task)# 根据HTTP状态码逻辑处理（模拟）if result['status'] == 'success':return resultelif result['status'] == 'blocked':# 如果是被封锁，增加随机延迟再重试await asyncio.sleep(1.0 * (attempt + 1))continueelse:# 其他错误，直接重试continueexcept Exception as e:if attempt == task.retries - 1:raise eawait asyncio.sleep(0.5)return {'status': 'failed', 'reason': 'Max retries exceeded'}逐行注释与设计要点：@dataclass 的使用：CrawlTask 定义了任务的结构。在实际【实战项目】中，你可能需要更多字段，如 priority（优先级）或 proxy_ip。这里简化了，但核心思想是任务与执行分离。
asyncio.Semaphore：这是控制并发度的关键。如果没有它，当你有1000个URL时，瞬间发出1000个请求，不仅会拖慢本地网络，更会被目标服务器永久封禁。模拟“大战”不是无脑并发，而是受控并发。
fetch_with_strategy：这里硬编码了两种策略。在实际开发中，这应该是一个策略模式（Strategy Pattern），通过配置加载不同的反制逻辑。注意 360 源对 User-Agent 的校验，这模拟了更严格的反爬策略。
asyncio.gather：这是并发执行的核心。它同时等待所有任务完成。注意 return_exceptions=True，这防止了一个任务失败导致整个批次崩溃。在生产环境中，这是必须的，否则一个坏死的URL会毁掉你的整个【实战项目】。
重试逻辑：在 _execute_task 中，我们根据 status 进行了不同的处理。被封锁（blocked）时增加延迟，这是为了绕过简单的频率检测。这符合 RFC 7231 中关于客户端行为应适应服务器响应的原则。3. 设计思想：从对抗到协同
很多人看源码只看语法，不看设计。这个调度器背后，隐藏着当年搜索引擎竞争的两个核心思想：容错性与适应性。
容错性：永远不要相信网络
在分布式系统中，网络故障是常态。我们的代码中，try-except 块和重试机制就是容错性的体现。在早期的百度架构中，就大量采用了这种“重试+降级”的策略。如果主节点响应慢，自动切换到备用节点；如果某个请求失败，指数退避重试。
在你的【实战项目】中，务必记住：任何网络请求都必须有超时设置（Timeout）。上面的代码中，aiohttp 的 session.get 应该显式设置 timeout=aiohttp.ClientTimeout(total=10)。如果不设置，一个挂起的请求会永久占用协程，导致内存泄漏。这是新手最容易踩的坑，也是“配置环境”后运行不稳定的主要原因。
适应性：策略模式的价值
代码中 source 字段决定了不同的处理逻辑。这实际上是策略模式的一种简化。在真正的生产级爬虫中，你需要一个 StrategyFactory，根据目标站点的特征动态加载策略。例如，检测到是 360 风格站点，就加载 StrictHeaderStrategy；检测到是 baidu 风格，就加载 RateLimitStrategy。
这种设计使得代码易于扩展。如果你明天要加一个“搜狗”源，只需要新增一个策略类，而不需要修改核心调度逻辑。这符合开闭原则（OCP），也是大型【实战项目】维持可维护性的关键。
4. 手写简化版：数据清洗与去重
光有数据抓下来不行，数据质量才是核心竞争力。当年两大巨头在数据清洗上的投入，甚至超过了爬虫本身。这里我们手写一个简化的数据清洗模块，模拟对抓取结果的标准化处理。
import re
import hashlib
from typing import Setclass DataCleaner:def __init__(self):self.seen_hashes: Set[str] = set()self.url_pattern = re.compile(r'^https?://[^\s]+')def clean_url(self, url: str) - str:标准化URL：去除跟踪参数、统一协议模拟搜索引擎对URL的归一化处理# 1. 去除末尾斜杠url = url.rstrip('/')# 2. 移除常见的跟踪参数 (utm_source, utm_medium, etc.)# 这是一个简化的正则，实际项目中需要更复杂的逻辑params_to_remove = ['utm_source', 'utm_medium', 'utm_campaign', 'fbclid']if '?' in url:base, params = url.split('?', 1)filtered_params = []for p in params.split(''):key = p.split('=')[0]if key not in params_to_remove:filtered_params.append(p)url = base + '?' + ''.join(filtered_params) if filtered_params else basereturn urldef is_duplicate(self, content: str) - bool:基于内容哈希的去重模拟搜索引擎的文档去重算法# 1. 预处理：去除空白字符，转小写normalized_content = re.sub(r'\s+', '', content.lower())# 2. 计算SHA256哈希# 注意：对于长文本，全量哈希计算开销大，实际中常采用分块哈希或MinHashcontent_hash = hashlib.sha256(normalized_content.encode('utf-8')).hexdigest()if content_hash in self.seen_hashes:return Trueself.seen_hashes.add(content_hash)return Falsedef process(self, raw_data: str, url: str) - dict:主处理流程# 1. URL标准化clean_url = self.clean_url(url)# 2. 提取正文（简化：假设所有文本都是正文）# 实际项目中需要用 BeautifulSoup 或 lxml 提取 p 标签内容text_content = raw_data# 3. 去重检查if self.is_duplicate(text_content):return {'valid': False, 'reason': 'Duplicate Content'}# 4. 质量评分（简化版）# 基于文本长度和词汇丰富度word_count = len(text_content.split())if word_count 100:return {'valid': False, 'reason': 'Low Quality: Too Short'}return {'valid': True,'url': clean_url,'word_count': word_count,'hash': hashlib.sha256(text_content.encode('utf-8')).hexdigest()[:8] # 截取部分哈希用于展示}设计思想解析：URL归一化：这是搜索引擎排名算法的基础。如果 http://example.com/page 和 https://example.com/page/ 被视为两个页面，会导致重复内容问题，稀释权重。在【实战项目】中，如果不做这一步，你的数据库里会充满冗余数据。
内容哈希去重：使用 SHA256 是一种高成本的方案，但对于中小规模数据是可行的。在大规模数据中，MinHash 和 SimHash 是更常用的近似去重算法，它们能处理“相似度”而非完全一致的情况。这里为了代码简洁，使用了精确匹配。
质量过滤：简单的字数限制是入门级过滤。进阶的【实战项目】会引入 TF-IDF 或 PageRank 的简化版，来评估页面价值。这模拟了搜索引擎的“排名”逻辑，确保抓取的都是高价值数据。5. 应用场景与避坑指南
这个【实战项目】不仅适用于爬虫，其架构思想可以迁移到任何高并发IO密集型场景，如API聚合、日志收集、实时监控等。
避坑指南不要忽视代理池：在模拟“大战”时，IP封禁是必然的。生产环境中，必须集成代理池，并在请求头中动态切换 X-Forwarded-For。
数据库连接池：如果将数据存入 MySQL 或 PostgreSQL，务必使用连接池（如 DBUtils 或 SQLAlchemy 的 Pool）。每次请求都新建连接，会导致性能急剧下降，甚至耗尽数据库连接数。
异常处理要具体：不要捕获所有的 Exception。区分 ConnectionError、TimeoutError 和 HTTPError，针对不同类型采取不同的重试策略。
监控与日志：在 run_battle 中加入日志记录。记录每个任务的成功率、平均延迟、失败原因。没有数据的监控，就无法优化【实战项目】。为什么这个案例值得做
因为它涵盖了异步编程、并发控制、策略模式、数据清洗、异常处理五大核心技能。当你完成这个项目，你不再只是会调库，而是理解了为什么要这样设计。
在配置环境时，记得安装 aiohttp 和 lxml。在运行前，检查你的 Python 版本是否支持 async/await（Python 3.5+）。如果遇到 Event loop is closed 错误，通常是协程生命周期管理不当，检查 async with 的使用是否正确。
结语
技术不是背出来的，是踩坑踩出来的。【360与百度大战】这个【实战项目】，看似简单，实则浓缩了分布式系统设计的精髓。从并发调度到数据清洗，每一个环节都有无数细节等待你去打磨。
你在项目里踩过这个坑吗？比如，你是如何解决异步环境下的数据库写入瓶颈的？或者，你的去重算法在数据量增大后性能下降了多少？评论区聊聊，我们一起把这个架构做扎实。 360与百度大战实战项目源码解析避坑指南
360与百度大战实战项目源码解析避坑指南
配置环境就卡半天，是不是你的常态？很多开发者在复刻经典互联网案例时，往往死在“环境依赖”和“逻辑对齐”上，而不是代码本身。今天咱们聊的【360与百度大战】，并非指商业互怼，而是指在分布式爬虫与高并发搜索架构中，如何模拟两大巨头早期对抗中的核心策略：高可用、反爬对抗与数据清洗。这是一个极具代表性的【实战项目】，能帮你彻底理清从请求到存储的全链路细节。
别被名字吓到，这其实是一个基于Python的异步爬虫架构拆解。很多新手看到“大战”二字，以为要写什么复杂的对抗算法，其实核心在于稳定性与数据一致性。如果你曾在项目中遇到“明明代码没错，但跑着跑着就断连”或者“数据乱码”的问题，这篇源码解析能直接给你答案。
1. 入口定位：为什么选择这个架构作为实战项目
在早期的搜索引擎竞争中，百度与360（及其背后的奇虎）在技术路线上有着显著的差异。百度更侧重垂直领域的深度挖掘，而360在安全与反作弊层面有着独特的投入。在技术实现上，这映射为两个核心模块：并发调度器与数据清洗引擎。
对于初学者而言，直接去爬取真实站点不仅涉及法律风险，还因为目标站点的动态变化导致代码失效。因此，我们构建一个模拟的“双引擎对抗”环境。这里的核心痛点在于：如何在一个统一的框架下，处理两种不同反制策略的数据源。
在实际的【实战项目】中，我们常遇到这种情况：A站点使用简单的IP限制，B站点使用复杂的JS混淆或验证码。如果你的爬虫框架不能动态适配这两种策略，你的系统就会在“配置环境”或“初次运行”阶段频繁崩溃。这就是为什么我们要深入源码，而不是仅仅看API文档。
核心模块拆解
我们将整个系统分为三层：调度层：负责任务分发，模拟“兵分两路”的策略。
执行层：负责实际请求，包含重试机制与代理池切换。
处理层：负责HTML解析、去重与存储，模拟数据清洗。这种分层设计，正是当年两大搜索引擎在架构迭代中逐步形成的共识。虽然当时没有统一的行业标准，但基于 RFC 7231（Hypertext Transfer Protocol -- HTTP/1.1）规范定义的请求方法（GET/POST）与状态码处理，是构建任何稳定爬虫的基石。很多初学者忽略RFC规范中关于幂等性（Idempotency）的定义，导致重试请求时产生了重复数据，这是典型的“环境配置”之外的逻辑陷阱。
2. 核心片段：并发调度器的源码剖析
让我们直接看代码。以下是一个简化版的异步调度器，它模拟了“大战”中双方同时发起请求的场景。这里使用 asyncio 和 aiohttp，这是目前处理高并发IO最主流的方案。
import asyncio
import aiohttp
from dataclasses import dataclass, field
from typing import List, Dict, Any
import time
import random@dataclass
class CrawlTask:定义一个爬虫任务，模拟单个URL请求url: strsource: str # 'baidu' 或 '360'，模拟不同源retries: int = 3 # 默认重试次数headers: Dict[str, str] = field(default_factory=dict)class BattleScheduler:def __init__(self, max_concurrent: int = 50):self.max_concurrent = max_concurrentself.semaphore = asyncio.Semaphore(max_concurrent)self.active_tasks: List[CrawlTask] = []async def fetch_with_strategy(self, session: aiohttp.ClientSession, task: CrawlTask) - Dict[str, Any]:核心执行逻辑：根据来源策略执行请求这里模拟了不同站点的反制措施start_time = time.time()# 模拟网络延迟，真实项目中这是由网络环境决定的await asyncio.sleep(random.uniform(0.1, 0.5))# 模拟360站点的严格策略：检查User-Agentif task.source == '360' and 'User-Agent' not in task.headers:return {'status': 'blocked','reason': 'Missing User-Agent','latency': time.time() - start_time}# 模拟百度站点的宽松策略：允许匿名访问，但限制频率if task.source == 'baidu' and random.random() 0.1:# 10%的概率触发限流await asyncio.sleep(2.0) # 模拟等待return {'status': 'success','data': fContent from {task.source},'latency': time.time() - start_time}async def run_battle(self, urls: List[str]):入口方法：启动大战async with aiohttp.ClientSession() as session:tasks = []# 1. 任务初始化：交替分配任务给两个“阵营”for i, url in enumerate(urls):source = 'baidu' if i % 2 == 0 else '360'task = CrawlTask(url=url, source=source)tasks.append(self._execute_task(session, task))# 2. 并发执行：这里体现了“大战”的核心——并发竞争results = await asyncio.gather(*tasks, return_exceptions=True)# 3. 结果处理for result in results:if isinstance(result, Exception):print(fTask failed: {result})else:print(fTask done: {result['status']} in {result['latency']:.2f}s)async def _execute_task(self, session: aiohttp.ClientSession, task: CrawlTask):带重试机制的单任务执行这里处理了RFC 7231中定义的状态码逻辑async with self.semaphore: # 控制并发数，防止打爆服务器for attempt in range(task.retries):try:# 实际项目中这里是 await session.get(task.url)# 为了演示，我们直接调用模拟方法result = await self.fetch_with_strategy(session, task)# 根据HTTP状态码逻辑处理（模拟）if result['status'] == 'success':return resultelif result['status'] == 'blocked':# 如果是被封锁，增加随机延迟再重试await asyncio.sleep(1.0 * (attempt + 1))continueelse:# 其他错误，直接重试continueexcept Exception as e:if attempt == task.retries - 1:raise eawait asyncio.sleep(0.5)return {'status': 'failed', 'reason': 'Max retries exceeded'}逐行注释与设计要点：@dataclass 的使用：CrawlTask 定义了任务的结构。在实际【实战项目】中，你可能需要更多字段，如 priority（优先级）或 proxy_ip。这里简化了，但核心思想是任务与执行分离。
asyncio.Semaphore：这是控制并发度的关键。如果没有它，当你有1000个URL时，瞬间发出1000个请求，不仅会拖慢本地网络，更会被目标服务器永久封禁。模拟“大战”不是无脑并发，而是受控并发。
fetch_with_strategy：这里硬编码了两种策略。在实际开发中，这应该是一个策略模式（Strategy Pattern），通过配置加载不同的反制逻辑。注意 360 源对 User-Agent 的校验，这模拟了更严格的反爬策略。
asyncio.gather：这是并发执行的核心。它同时等待所有任务完成。注意 return_exceptions=True，这防止了一个任务失败导致整个批次崩溃。在生产环境中，这是必须的，否则一个坏死的URL会毁掉你的整个【实战项目】。
重试逻辑：在 _execute_task 中，我们根据 status 进行了不同的处理。被封锁（blocked）时增加延迟，这是为了绕过简单的频率检测。这符合 RFC 7231 中关于客户端行为应适应服务器响应的原则。3. 设计思想：从对抗到协同
很多人看源码只看语法，不看设计。这个调度器背后，隐藏着当年搜索引擎竞争的两个核心思想：容错性与适应性。
容错性：永远不要相信网络
在分布式系统中，网络故障是常态。我们的代码中，try-except 块和重试机制就是容错性的体现。在早期的百度架构中，就大量采用了这种“重试+降级”的策略。如果主节点响应慢，自动切换到备用节点；如果某个请求失败，指数退避重试。
在你的【实战项目】中，务必记住：任何网络请求都必须有超时设置（Timeout）。上面的代码中，aiohttp 的 session.get 应该显式设置 timeout=aiohttp.ClientTimeout(total=10)。如果不设置，一个挂起的请求会永久占用协程，导致内存泄漏。这是新手最容易踩的坑，也是“配置环境”后运行不稳定的主要原因。
适应性：策略模式的价值
代码中 source 字段决定了不同的处理逻辑。这实际上是策略模式的一种简化。在真正的生产级爬虫中，你需要一个 StrategyFactory，根据目标站点的特征动态加载策略。例如，检测到是 360 风格站点，就加载 StrictHeaderStrategy；检测到是 baidu 风格，就加载 RateLimitStrategy。
这种设计使得代码易于扩展。如果你明天要加一个“搜狗”源，只需要新增一个策略类，而不需要修改核心调度逻辑。这符合开闭原则（OCP），也是大型【实战项目】维持可维护性的关键。
4. 手写简化版：数据清洗与去重
光有数据抓下来不行，数据质量才是核心竞争力。当年两大巨头在数据清洗上的投入，甚至超过了爬虫本身。这里我们手写一个简化的数据清洗模块，模拟对抓取结果的标准化处理。
import re
import hashlib
from typing import Setclass DataCleaner:def __init__(self):self.seen_hashes: Set[str] = set()self.url_pattern = re.compile(r'^https?://[^\s]+')def clean_url(self, url: str) - str:标准化URL：去除跟踪参数、统一协议模拟搜索引擎对URL的归一化处理# 1. 去除末尾斜杠url = url.rstrip('/')# 2. 移除常见的跟踪参数 (utm_source, utm_medium, etc.)# 这是一个简化的正则，实际项目中需要更复杂的逻辑params_to_remove = ['utm_source', 'utm_medium', 'utm_campaign', 'fbclid']if '?' in url:base, params = url.split('?', 1)filtered_params = []for p in params.split(''):key = p.split('=')[0]if key not in params_to_remove:filtered_params.append(p)url = base + '?' + ''.join(filtered_params) if filtered_params else basereturn urldef is_duplicate(self, content: str) - bool:基于内容哈希的去重模拟搜索引擎的文档去重算法# 1. 预处理：去除空白字符，转小写normalized_content = re.sub(r'\s+', '', content.lower())# 2. 计算SHA256哈希# 注意：对于长文本，全量哈希计算开销大，实际中常采用分块哈希或MinHashcontent_hash = hashlib.sha256(normalized_content.encode('utf-8')).hexdigest()if content_hash in self.seen_hashes:return Trueself.seen_hashes.add(content_hash)return Falsedef process(self, raw_data: str, url: str) - dict:主处理流程# 1. URL标准化clean_url = self.clean_url(url)# 2. 提取正文（简化：假设所有文本都是正文）# 实际项目中需要用 BeautifulSoup 或 lxml 提取 p 标签内容text_content = raw_data# 3. 去重检查if self.is_duplicate(text_content):return {'valid': False, 'reason': 'Duplicate Content'}# 4. 质量评分（简化版）# 基于文本长度和词汇丰富度word_count = len(text_content.split())if word_count 100:return {'valid': False, 'reason': 'Low Quality: Too Short'}return {'valid': True,'url': clean_url,'word_count': word_count,'hash': hashlib.sha256(text_content.encode('utf-8')).hexdigest()[:8] # 截取部分哈希用于展示}设计思想解析：URL归一化：这是搜索引擎排名算法的基础。如果 http://example.com/page 和 https://example.com/page/ 被视为两个页面，会导致重复内容问题，稀释权重。在【实战项目】中，如果不做这一步，你的数据库里会充满冗余数据。
内容哈希去重：使用 SHA256 是一种高成本的方案，但对于中小规模数据是可行的。在大规模数据中，MinHash 和 SimHash 是更常用的近似去重算法，它们能处理“相似度”而非完全一致的情况。这里为了代码简洁，使用了精确匹配。
质量过滤：简单的字数限制是入门级过滤。进阶的【实战项目】会引入 TF-IDF 或 PageRank 的简化版，来评估页面价值。这模拟了搜索引擎的“排名”逻辑，确保抓取的都是高价值数据。5. 应用场景与避坑指南
这个【实战项目】不仅适用于爬虫，其架构思想可以迁移到任何高并发IO密集型场景，如API聚合、日志收集、实时监控等。
避坑指南不要忽视代理池：在模拟“大战”时，IP封禁是必然的。生产环境中，必须集成代理池，并在请求头中动态切换 X-Forwarded-For。
数据库连接池：如果将数据存入 MySQL 或 PostgreSQL，务必使用连接池（如 DBUtils 或 SQLAlchemy 的 Pool）。每次请求都新建连接，会导致性能急剧下降，甚至耗尽数据库连接数。
异常处理要具体：不要捕获所有的 Exception。区分 ConnectionError、TimeoutError 和 HTTPError，针对不同类型采取不同的重试策略。
监控与日志：在 run_battle 中加入日志记录。记录每个任务的成功率、平均延迟、失败原因。没有数据的监控，就无法优化【实战项目】。为什么这个案例值得做
因为它涵盖了异步编程、并发控制、策略模式、数据清洗、异常处理五大核心技能。当你完成这个项目，你不再只是会调库，而是理解了为什么要这样设计。
在配置环境时，记得安装 aiohttp 和 lxml。在运行前，检查你的 Python 版本是否支持 async/await（Python 3.5+）。如果遇到 Event loop is closed 错误，通常是协程生命周期管理不当，检查 async with 的使用是否正确。
结语
技术不是背出来的，是踩坑踩出来的。【360与百度大战】这个【实战项目】，看似简单，实则浓缩了分布式系统设计的精髓。从并发调度到数据清洗，每一个环节都有无数细节等待你去打磨。
你在项目里踩过这个坑吗？比如，你是如何解决异步环境下的数据库写入瓶颈的？或者，你的去重算法在数据量增大后性能下降了多少？评论区聊聊，我们一起把这个架构做扎实。