简介本资源是一套面向法律科技研究者与Python爬虫开发者的分布式网络爬虫系统专为中国裁判文书网设计解决其动态加载、验证码识别、请求频率限制等典型反爬难题支持案件信息全量采集、结构化清洗及文书详情页解析下载适用于法学实证分析、司法大数据建模等场景。压缩包共17个文件含13个核心Python脚本覆盖生产者、消费者、日志、配置、命令行接口等模块、1份说明文档.docx、1份README.md、1个日志文件.log和1个文本说明.txt总大小仅42KB轻量但结构完整便于快速部署与二次开发。已有106人学习下载资源提供开箱即用的分布式架构雏形、反反爬策略实现如会话复用、随机延时、User-Agent轮换、文书文本提取逻辑及MySQL存储适配代码目录层级清晰模块职责分明适合中高级开发者参考学习与工程化改造。1. 项目缘起为什么我们需要一个“裁判文书网”爬虫作为一名长期混迹于数据分析和法律交叉领域的技术人我经常被问到“有没有办法批量获取裁判文书网上的案例数据”无论是做学术研究、市场分析还是构建法律知识图谱海量的裁判文书都是极其宝贵的原始资料。然而手动复制粘贴的效率低到令人发指而裁判文书网本身的反爬机制又相当“健壮”普通的单线程脚本跑不了几分钟就会被封IP或者陷入验证码的泥潭。这个项目正是为了解决这个痛点而生的。它不是一个简单的“requests BeautifulSoup”脚本而是一个基于Python构建的、具备完整工业级特性的分布式网络爬虫系统。它的核心目标是实现对“中国裁判文书网”案件信息的自动化、规模化、稳定化采集与存储。这意味着你需要考虑的不只是如何解析一个网页更要系统性地解决IP封锁、请求频率控制、数据清洗、断点续爬、分布式调度等一系列工程问题。如果你正面临类似的数据获取困境或者想深入学习如何构建一个健壮的爬虫系统那么接下来的内容就是为你准备的实战手册。2. 系统架构设计从单兵作战到集团军作战一个能稳定运行的爬虫系统其架构设计决定了它的上限。我们摒弃了“一个脚本打天下”的思路转而采用模块化、分布式的设计。整个系统可以清晰地划分为五个核心层它们协同工作共同应对复杂的网络环境和大规模数据抓取任务。2.1 核心组件与数据流整个系统的数据流和工作流程可以用下面这张组件关系图来理解。它清晰地展示了从任务下发到数据落地的完整路径以及各个模块之间的交互关系。flowchart TD A[“调度中心br(Master Node)”] --|分发任务| B[“爬虫节点集群br(Worker Nodes)”] B -- C{“请求网页br文书列表/详情”} C -- D[“反反爬中间件br代理IP池/请求头轮换/延时”] D -- E{“遇到验证码/封禁”} E -- 是 -- F[“验证码处理模块br识别/打码/人工介入”] F -- C E -- 否 -- G[“网页解析器br列表页/详情页”] G -- H[“数据清洗与校验管道”] H -- I[“数据存储器brMySQL/MongoDB/文件”] I -- J[“任务状态同步”] J -- A调度中心 (Master Node)这是系统的大脑。它不负责具体的爬取工作而是负责任务的调度与状态管理。主要职责包括种子URL管理生成或维护需要爬取的初始URL队列例如根据案由、法院、时间范围等条件生成的搜索列表页URL。任务分发采用队列如Redis的List或RabbitMQ将URL任务分发给空闲的爬虫节点Worker。去重与状态跟踪确保同一个URL不会被重复抓取通常使用布隆过滤器或Redis的Set并记录每个任务的状态待处理、处理中、成功、失败。故障转移与负载均衡监控Worker节点的健康状态如果某个节点宕机将其未完成的任务重新分配给其他节点。爬虫节点集群 (Worker Nodes)这是系统的四肢负责执行具体的HTTP请求、页面解析和数据提取工作。每个Worker都是一个独立的进程或容器可以部署在不同的机器上。它们从调度中心领取任务执行后返回结果。分布式部署的核心优势在于提升速度多节点并行抓取极大缩短数据采集时间。增强稳定性单个节点被目标网站封禁不影响其他节点继续工作。便于扩展随着任务量增加可以简单地通过增加Worker节点来水平扩展系统能力。反反爬中间件这是系统的“隐形护甲”集成在每个Worker中。它不是一个独立的服务而是一系列策略的集合用于模拟人类行为规避网站的反爬虫检测。主要包括User-Agent轮换池准备几十甚至上百个常见的浏览器User-Agent字符串每次请求随机选取。代理IP池这是对抗IP封锁的核心。需要一个稳定的代理IP来源付费服务或自建代理池并在每次请求时动态更换IP。需要实现IP有效性检测和自动剔除失效IP的逻辑。请求延时控制在请求之间加入随机延时例如random.uniform(1, 3)秒避免请求过于频繁。对于列表页和详情页可以采用不同的延时策略。Cookie与Session管理妥善处理登录态如果需要和网站设置的会话Cookie模拟完整的浏览器会话。网页解析器这是系统的“眼睛和手”。它接收下载到的HTML页面从中提取结构化数据。对于裁判文书网通常需要两类解析器列表页解析器解析搜索结果页提取出当前页所有文书的标题、案号、审理法院、裁判日期等摘要信息以及最关键的——每个文书的详情页链接。详情页解析器解析单个裁判文书的详情页提取完整的文书内容包括当事人信息、诉讼请求、法院查明事实、裁判理由、判决结果、法律依据等所有字段。数据清洗与校验管道原始提取的数据往往是“脏”的包含多余的空格、换行、不可见字符或者字段缺失、格式不一致。这一层负责文本清洗去除HTML标签、空白字符规范化、处理特殊编码。字段标准化例如将“2023年5月1日”、“2023-05-01”等不同格式的日期统一为ISO标准格式“2023-05-01”。数据校验检查必填字段是否为空如案号数据格式是否符合预期如金额是否为数字对异常数据进行标记或触发重新抓取。数据存储器这是系统的“仓库”。清洗后的数据需要持久化存储。根据数据量和使用场景可以选择关系型数据库 (如MySQL, PostgreSQL)适合结构化程度高、需要复杂查询和关联分析的场景。可以建立案件表、当事人表、法院表等利用SQL进行高效分析。文档型数据库 (如MongoDB)适合存储嵌套结构复杂、格式可能变化的文书全文。它的Schema-less特性非常灵活可以直接将整个文书JSON存入一个文档。文件存储 (如JSON Lines, Parquet)作为数据库的补充或备份便于数据交换和批量处理。例如可以按日期将文书存储为.jsonl文件每行一个JSON对象。注意在实际部署中调度中心和任务队列如Redis是单点需要保证其高可用性。可以考虑对Redis做主从复制或者使用更可靠的消息队列如RabbitMQ。Worker节点则应设计为无状态的方便随时扩缩容。3. 关键技术实现攻克裁判文书网的“城墙”有了架构蓝图接下来我们深入每个关键模块看看具体如何用Python实现。这里会包含大量代码片段和配置思路你可以直接参考。3.1 请求引擎与反反爬策略实战我们选择requests库作为基础但会对其进行深度封装。aiohttp虽然异步性能更高但在处理复杂的同步逻辑和调试时requests的简洁直观更有优势且通过连接池和多进程也能满足性能需求。核心请求类封装示例import random import time import requests from requests.adapters import HTTPAdapter from urllib3.util.retry import Retry class RobustRequestClient: def __init__(self, proxy_poolNone, user_agent_poolNone): self.session requests.Session() # 1. 设置重试策略应对网络波动 retry_strategy Retry( total3, # 总重试次数 backoff_factor1, # 指数退避因子 status_forcelist[429, 500, 502, 503, 504], # 遇到这些状态码重试 allowed_methods[GET, POST] ) adapter HTTPAdapter(max_retriesretry_strategy) self.session.mount(http://, adapter) self.session.mount(https://, adapter) # 2. 代理IP池和User-Agent池 self.proxy_pool proxy_pool or [] self.user_agent_pool user_agent_pool or [ Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 ..., Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 ..., # ... 更多UA ] self.current_proxy None def get_proxy(self): 从代理池中获取一个有效代理 if not self.proxy_pool: return None # 简单随机选取生产环境应包含健康检查 self.current_proxy random.choice(self.proxy_pool) return {http: self.current_proxy, https: self.current_proxy} def make_request(self, url, methodGET, **kwargs): 执行请求集成反反爬策略 headers kwargs.get(headers, {}) # 随机UA headers[User-Agent] random.choice(self.user_agent_pool) kwargs[headers] headers # 使用代理 proxies self.get_proxy() if proxies: kwargs[proxies] proxies # 随机延时模拟人工操作 time.sleep(random.uniform(1.5, 4.0)) try: response self.session.request(method, url, timeout15, **kwargs) response.raise_for_status() # 非200状态码抛出异常 # 简单检查是否返回了反爬页面如验证码页面 if 验证码 in response.text or 访问过于频繁 in response.text: raise requests.RequestException(触发反爬机制) return response except requests.RequestException as e: print(f请求失败: {url}, 错误: {e}, 使用的代理: {self.current_proxy}) # 标记当前代理可能失效可从池中临时移除 # 然后可以选择重试使用新代理或抛出异常 raise为什么这样设计重试机制网络请求天生不稳定短暂的连接超时或服务器错误5xx很常见。Retry策略能自动处理这些情况提高单次请求的鲁棒性。Session复用使用requests.Session()可以自动保持Cookie复用TCP连接提升效率。代理池动态切换这是对抗IP封锁最有效的手段。关键在于代理IP的质量和数量。免费代理不稳定建议使用付费的隧道代理或高质量HTTP代理服务它们通常提供API来获取动态IP。随机延时固定的延时如time.sleep(2)容易被识别。随机延时更接近人类操作的不确定性。3.2 解析器从HTML到结构化数据裁判文书网的页面结构相对规整但仍有细节需要注意。我们使用lxml库它比BeautifulSoup解析速度更快XPath表达式也更强大。列表页解析示例假设列表页的每个文书条目在一个 class 为caseItem的 div 中。from lxml import html def parse_list_page(html_content): tree html.fromstring(html_content) case_items tree.xpath(//div[contains(class, caseItem)]) cases [] for item in case_items: case {} # 使用XPath提取信息注意处理可能缺失的字段 try: case[title] item.xpath(.//a[classcaseTitle]/text())[0].strip() case[case_number] item.xpath(.//span[classcaseNum]/text())[0].strip() case[court] item.xpath(.//span[classcourtName]/text())[0].strip() case[judge_date] item.xpath(.//span[classjudgeDate]/text())[0].strip() # 提取详情页链接可能需要拼接基础URL relative_url item.xpath(.//a[classcaseTitle]/href)[0] case[detail_url] https://wenshu.court.gov.cn relative_url cases.append(case) except IndexError as e: print(f解析列表项时字段缺失: {e}) continue # 跳过此项继续解析下一个 return cases详情页解析与难点处理详情页的难点在于文书正文可能包含复杂的排版、表格且关键信息如当事人、金额的定位可能因文书类型而异。def parse_detail_page(html_content, case_info): tree html.fromstring(html_content) detail_data {**case_info} # 继承列表页的基础信息 # 1. 提取文书全文可能在一个特定的div或pre标签内 full_text_elem tree.xpath(//div[idFullText]//text() | //pre[idFullText]//text()) if full_text_elem: detail_data[full_text] \n.join([t.strip() for t in full_text_elem if t.strip()]) else: # 如果找不到尝试更通用的选择器或者标记为解析失败 detail_data[full_text] # 2. 尝试提取结构化字段依赖于网站的具体DOM结构这里仅为示例 # 例如当事人信息可能在一个表格里 party_table tree.xpath(//table[contains(class, party-info)]) if party_table: parties [] for row in party_table[0].xpath(.//tr)[1:]: # 跳过表头 cols row.xpath(.//td/text()) if len(cols) 2: parties.append({role: cols[0].strip(), name: cols[1].strip()}) detail_data[parties] parties # 3. 提取裁判结果寻找“判决如下”、“裁定如下”等关键词后的内容 # 这是一个基于文本规则的简单示例更复杂的需要NLP技术 import re judgment_pattern re.compile(r(判决如下|裁定如下)[:]?\s*(.*?)(?\n\n|$), re.DOTALL) match judgment_pattern.search(detail_data.get(full_text, )) if match: detail_data[judgment_result] match.group(2).strip() # 4. 数据清洗处理全角字符、多余空格等 if full_text in detail_data: detail_data[full_text_cleaned] clean_text(detail_data[full_text]) return detail_data def clean_text(text): 简单的文本清洗函数 # 替换全角空格和标点为半角可选根据需求 # 合并多个换行和空格 import re text re.sub(r\s, , text) # 合并所有空白字符为单个空格 text text.strip() return text实操心得裁判文书网的页面结构并非一成不变可能会改版。因此解析器的XPath路径不能写死。一个好的实践是将这些选择器XPath或CSS作为配置文件存储。当网站改版时只需更新配置文件而无需修改核心代码。此外对于解析失败率高的页面应该记录下来供后续人工核查或调整解析策略。3.3 数据清洗与存储让数据真正可用爬取下来的原始数据必须经过清洗才能用于分析。我们使用pandas进行批处理清洗并结合自定义函数处理复杂逻辑。构建数据清洗管道import pandas as pd import numpy as np def data_cleaning_pipeline(raw_data_list): 接收原始数据字典列表返回清洗后的DataFrame df pd.DataFrame(raw_data_list) # 1. 处理缺失值 # 对于关键字段如案号缺失则丢弃该行 df df.dropna(subset[case_number]) # 对于非关键文本字段用空字符串填充 text_columns [title, court, full_text] df[text_columns] df[text_columns].fillna() # 2. 字段格式标准化 # 日期字段标准化 df[judge_date] pd.to_datetime(df[judge_date], errorscoerce) # 转换失败设为NaT # 法院名称去重处理“北京市第一中级人民法院”和“北京一中院”等别名 # 这里可以维护一个法院名称映射字典 court_mapping {北京一中院: 北京市第一中级人民法院, 沪01民终: 上海市第一中级人民法院} df[court_standardized] df[court].map(court_mapping).fillna(df[court]) # 3. 文本深度清洗应用之前定义的clean_text函数 df[full_text_cleaned] df[full_text].apply(clean_text) # 可以计算文本长度过滤掉异常短的文书可能是抓取失败 df[text_length] df[full_text_cleaned].str.len() df df[df[text_length] 100] # 假设少于100字符为无效文书 # 4. 去重基于案号案号应是唯一的 df df.drop_duplicates(subset[case_number], keepfirst) return df存储策略清洗后的DataFrame可以方便地存储到多种目的地。import pymongo from sqlalchemy import create_engine def save_to_database(df, storage_typefile, **kwargs): 将清洗后的数据保存到指定存储 if storage_type csv: df.to_csv(kwargs.get(filepath, cases.csv), indexFalse, encodingutf-8-sig) elif storage_type jsonl: df.to_json(kwargs.get(filepath, cases.jsonl), orientrecords, linesTrue, force_asciiFalse) elif storage_type mysql: engine create_engine(mysqlpymysql://user:passwordlocalhost:3306/law_db) df.to_sql(namekwargs.get(table_name, judgments), conengine, if_existsappend, indexFalse) elif storage_type mongodb: client pymongo.MongoClient(kwargs.get(connection_str, mongodb://localhost:27017/)) db client[kwargs.get(db_name, law_data)] collection db[kwargs.get(collection_name, judgments)] # 将DataFrame转换为字典列表插入 records df.to_dict(records) if records: collection.insert_many(records) else: raise ValueError(f不支持的存储类型: {storage_type})注意直接使用to_sql或insert_many在大批量数据插入时可能会有效率问题或内存压力。对于海量数据应考虑分批次插入或者使用数据库的批量导入工具如MySQL的LOAD DATA INFILE。4. 分布式调度与任务管理用Redis和Celery构建爬虫集群单机爬虫能力有限且容易被封。我们需要将任务分发到多个节点上执行。这里介绍使用Redis作为任务队列结合Celery或自制调度器实现分布式爬虫的方案。4.1 基于Redis的简易任务队列Redis的List数据结构非常适合做先进先出FIFO的任务队列。调度中心任务生产者示例# master_scheduler.py import redis import json class TaskScheduler: def __init__(self): self.redis_client redis.Redis(hostlocalhost, port6379, db0, decode_responsesTrue) self.task_queue_key crawler:tasks:list self.visited_set_key crawler:visited:set # 用于URL去重 def generate_initial_tasks(self): 生成初始种子任务列表页URL base_url https://wenshu.court.gov.cn/website/wenshu/181217BMTKHNT2W0/index.html?page{}s803 # 假设要爬取前100页 list_page_urls [base_url.format(i) for i in range(1, 101)] for url in list_page_urls: task {url: url, type: list_page, depth: 0} self.push_task(task) def push_task(self, task_dict): 将一个任务推入队列 # 先去重 task_id task_dict.get(url) # 用URL作为唯一标识 if not self.redis_client.sismember(self.visited_set_key, task_id): self.redis_client.lpush(self.task_queue_key, json.dumps(task_dict, ensure_asciiFalse)) self.redis_client.sadd(self.visited_set_key, task_id) print(f任务已加入队列: {task_id}) def parse_and_distribute(self, list_page_html, list_page_url): 解析列表页提取详情页URL并生成新任务 case_list parse_list_page(list_page_html) for case in case_list: detail_task {url: case[detail_url], type: detail_page, meta: case} self.push_task(detail_task)爬虫节点任务消费者示例# worker_node.py import redis import json import time from robust_request_client import RobustRequestClient class CrawlerWorker: def __init__(self, worker_id): self.worker_id worker_id self.redis_client redis.Redis(hostlocalhost, port6379, db0, decode_responsesTrue) self.task_queue_key crawler:tasks:list self.request_client RobustRequestClient() # 初始化带反爬功能的客户端 def run(self): print(fWorker {self.worker_id} 启动...) while True: # 从队列右侧弹出任务BRPOP是阻塞操作队列空时等待 _, task_json self.redis_client.brpop(self.task_queue_key, timeout30) if not task_json: print(fWorker {self.worker_id}: 队列为空等待中...) time.sleep(5) continue task json.loads(task_json) print(fWorker {self.worker_id} 获取到任务: {task[url][:50]}...) try: response self.request_client.make_request(task[url]) if task[type] list_page: # 解析列表页并将新的详情页任务推回给Master这里简化Worker直接推 # 实际中Worker可以将解析出的新任务通过另一个队列或直接RPC通知Master case_list parse_list_page(response.text) # ... 将详情页任务推入队列的逻辑 ... pass elif task[type] detail_page: detail_data parse_detail_page(response.text, task.get(meta, {})) # 数据清洗和存储 cleaned_data data_cleaning_pipeline([detail_data]) save_to_database(cleaned_data, storage_typemongodb, collection_nameraw_judgments) print(fWorker {self.worker_id} 成功处理详情页: {task[url]}) except Exception as e: print(fWorker {self.worker_id} 处理任务失败: {task[url]}, 错误: {e}) # 可以将失败的任务放入一个“失败队列”供后续重试或检查 self.redis_client.lpush(crawler:failed:tasks, task_json)4.2 使用Celery进行更专业的任务调度对于更复杂、需要定时任务、任务链、结果回调等功能的系统使用Celery是更专业的选择。Celery是一个强大的分布式任务队列它本身不提供消息服务需要RabbitMQ或Redis作为消息代理Broker。Celery配置示例 (celery_config.py):# celery_config.py broker_url redis://localhost:6379/1 # 使用Redis作为Broker result_backend redis://localhost:6379/2 # 存储任务结果 task_serializer json accept_content [json] result_serializer json timezone Asia/Shanghai enable_utc True定义Celery任务 (tasks.py):# tasks.py from celery import Celery from robust_request_client import RobustRequestClient from parser import parse_detail_page, parse_list_page from data_pipeline import data_cleaning_pipeline, save_to_database app Celery(crawler_tasks, brokerredis://localhost:6379/1) app.config_from_object(celery_config) # 初始化一个全局的请求客户端注意Celery Worker是进程需要考虑资源管理 _request_client None def get_request_client(): global _request_client if _request_client is None: _request_client RobustRequestClient() return _request_client app.task(bindTrue, max_retries3) def crawl_detail_page(self, url, meta_info): 爬取详情页任务 client get_request_client() try: response client.make_request(url) detail_data parse_detail_page(response.text, meta_info) cleaned_data data_cleaning_pipeline([detail_data]) save_to_database(cleaned_data, storage_typemongodb) return {status: success, case_number: meta_info.get(case_number)} except Exception as exc: # 任务失败3秒后重试最多重试3次 raise self.retry(excexc, countdown3) app.task def crawl_list_page(url, page_num): 爬取列表页任务并链式触发详情页任务 client get_request_client() try: response client.make_request(url) case_list parse_list_page(response.text) for case in case_list: # 为每个详情页创建一个异步任务形成任务链 crawl_detail_page.delay(case[detail_url], case) return {status: success, page: page_num, cases_found: len(case_list)} except Exception as e: return {status: failed, page: page_num, error: str(e)}启动Worker和发送任务在命令行启动Celery Workercelery -A tasks worker --loglevelinfo --concurrency4--concurrency4表示启动4个Worker进程并行处理任务。在调度中心发送任务# master_with_celery.py from tasks import crawl_list_page # 分发100个列表页任务 for i in range(1, 101): url fhttps://wenshu.court.gov.cn/...page{i}... crawl_list_page.delay(url, i) # .delay() 是异步调用 print(f已分发第 {i} 页任务)使用Celery的优势在于其成熟稳定提供了丰富的功能如任务重试、结果跟踪、监控面板Flower非常适合构建生产级的分布式爬虫系统。5. 部署、监控与伦理考量5.1 系统部署与运维一个完整的系统需要部署在服务器上持续运行。推荐使用Docker进行容器化部署这能保证环境一致性方便扩展。Docker Compose 示例 (docker-compose.yml):version: 3.8 services: redis: image: redis:alpine container_name: crawler-redis ports: - 6379:6379 volumes: - redis-data:/data command: redis-server --appendonly yes mongodb: image: mongo:latest container_name: crawler-mongodb ports: - 27017:27017 volumes: - mongo-data:/data/db environment: MONGO_INITDB_ROOT_USERNAME: admin MONGO_INITDB_ROOT_PASSWORD: your_password celery-worker: build: . container_name: crawler-worker command: celery -A tasks worker --loglevelinfo --concurrency10 depends_on: - redis - mongodb environment: - REDIS_HOSTredis - MONGO_HOSTmongodb # 可以部署多个实例 deploy: replicas: 3 # 启动3个Worker容器 scheduler: build: . container_name: crawler-scheduler command: python master_scheduler.py depends_on: - redis environment: - REDIS_HOSTredis volumes: redis-data: mongo-data:监控与日志日志使用Python的logging模块将不同级别的日志INFO, ERROR输出到文件并集成到Docker的日志驱动中方便使用docker logs或ELK栈查看。健康检查为Celery Worker和调度器设计健康检查接口或使用进程监控工具如supervisord确保服务崩溃后能自动重启。进度监控可以通过Redis键来监控队列长度 (LLEN crawler:tasks:list)、已处理任务数等直观了解爬取进度。5.2 法律与伦理红线这是爬虫项目中最重要也最容易被忽视的部分。在动手之前必须清醒认识到以下几点遵守Robots协议检查目标网站的robots.txt文件通常位于网站根目录如https://wenshu.court.gov.cn/robots.txt。这个文件规定了哪些目录允许爬取哪些禁止。虽然不具法律强制力但违反它是极不友好的行为也可能成为对方采取法律行动的依据。尊重网站负载即使robots.txt允许也应控制请求频率避免对目标网站服务器造成过大压力影响其正常服务。我们的随机延时和分布式控制本身也是出于这个目的。数据使用限制爬取到的裁判文书数据其著作权通常属于发布法院或相关机构。这些数据严禁用于商业牟利、非法用途或对当事人进行骚扰。仅可用于个人学习、学术研究或符合法律法规的统计分析。公开数据时务必对当事人的姓名、身份证号、住址等个人信息进行脱敏处理。用户协议仔细阅读裁判文书网的用户协议明确其关于数据获取和使用的条款。违反用户协议可能导致账号被封禁甚至承担违约责任。隐私与个人信息保护根据《个人信息保护法》等相关法律处理个人信息需有合法依据。在研究和分析中应尽可能使用匿名化、去标识化的数据。一个负责任的爬虫开发者应该是一个“好网民”。技术的目的是解决问题和创造价值而不是制造麻烦。在开始任何爬虫项目前请务必评估其合法性与正当性。6. 常见问题与排错指南在实际运行中你一定会遇到各种各样的问题。这里列举一些典型问题及其排查思路。问题1爬虫运行一段时间后返回的都是验证码页面或空白页。可能原因IP地址被目标网站封禁。排查步骤检查当前使用的代理IP是否有效。可以写一个简单的测试脚本用当前代理去访问http://httpbin.org/ip看返回的IP是否与预期一致。检查请求头特别是User-Agent和Cookie。尝试更换一批新的User-Agent。检查请求频率是否过高。即使有代理单个代理IP的请求速度也可能触发风控。进一步增加请求间的随机延时。模拟更真实的浏览器行为。可以考虑使用selenium或playwright这类浏览器自动化工具来绕过简单的反爬但代价是速度会慢很多。问题2解析数据时某些字段经常提取为空或错误。可能原因网页结构发生变化或不同文书类型判决书、裁定书、调解书的页面结构不同。排查步骤将解析失败的页面的HTML保存到本地文件用浏览器打开对比当前的XPath/CSS选择器是否还能定位到目标元素。编写更健壮的解析逻辑。例如使用try...except捕获索引错误使用更通用的选择器如contains(class, ‘xxx’)或者准备多套解析规则针对不同文书类型。实施“解析监控”。记录每个页面的解析成功率对失败率高的页面类型进行重点分析和规则更新。问题3数据库写入速度慢成为系统瓶颈。可能原因单条插入效率低数据库连接数不足未使用批量插入。解决方案批量操作无论是SQL还是MongoDB都应尽可能使用批量插入executemany,insert_many而不是在循环中单条插入。异步写入将数据存储操作也放入任务队列如另一个Celery任务让爬取和存储解耦避免因存储慢而阻塞爬取。调整数据库配置增加数据库连接池大小对于MySQL可以临时关闭索引更新在数据导入完成后再重建索引。考虑更合适的存储对于纯粹的归档和离线分析写入文件系统如Parquet格式的速度可能远快于数据库。问题4Celery Worker进程意外退出或内存泄漏。可能原因代码中存在未处理的异常导致进程崩溃长时间运行后内存未释放。排查步骤查看Celery Worker的日志寻找崩溃前的错误信息。使用--maxtasksperchild参数。例如--concurrency4 --maxtasksperchild100这会让每个Worker进程在执行100个任务后重启释放可能积累的内存碎片。在任务函数内部做好异常捕获确保单个任务失败不会导致整个Worker进程崩溃。使用flower等监控工具观察Worker的状态和资源使用情况。构建这样一个系统更像是在进行一场持久的“攻防演练”。网站的反爬策略会升级你的爬虫策略也需要随之迭代。保持耐心持续观察日志不断调整你的“战术”是让爬虫系统长期稳定运行的关键。希望这份详尽的指南能为你打开法律数据挖掘的大门并提供一个坚实可靠的工程化起点。本文还有配套的精品资源点击获取