1. 项目概述一个轻量级、可扩展的Web数据采集框架最近在做一个需要从多个网站定期抓取数据的小项目一开始想用现成的爬虫框架但发现要么太重要么定制起来太麻烦。后来在GitHub上翻到了一个叫tfukaza/harvest的项目看介绍是一个轻量级的Web数据采集框架。我花了一周时间研究、试用并把它集成到了我的项目里感觉非常适合那些需要快速搭建、易于维护的爬虫任务但又不想被Scrapy这类重型框架束缚的开发者。简单来说harvest的核心定位是“小而美”。它不是一个试图解决所有问题的全能型爬虫平台而是一个提供了基础骨架和关键组件的工具箱。你可以把它理解为一个乐高积木套装它给了你轮子、轴承和连接件至于你想拼出一辆跑车还是一台挖掘机完全由你决定。它内置了请求管理、简单的异步支持、数据解析管道和结果导出等常见功能但每个部分都设计得足够“松耦合”让你可以轻松地替换或扩展。这个框架特别适合哪些场景呢我总结了几点首先是需要快速验证数据源可行性的场景你可能只需要写几十行代码就能跑通一个采集流程其次是数据源结构相对简单但数量较多的场景比如监控几十个竞争对手网站的价格变动最后是那些对代码结构和可维护性有要求的长期项目harvest清晰的模块划分能让你的爬虫代码不至于在几个月后变成一团乱麻。2. 核心架构与设计哲学拆解2.1 模块化与“约定大于配置”的思想harvest的代码结构一眼看去就很清晰。它没有采用Scrapy那种需要继承特定基类、严格遵循项目目录结构的“重型”模式而是推崇一种“约定大于配置”的轻量级哲学。这意味着框架提供了一套默认的最佳实践和工作流但你如果觉得不合适可以很方便地绕开它用自己的方式实现。它的核心模块通常包括采集器Harvester这是整个流程的调度中心负责管理任务队列、控制并发、处理生命周期事件。你可以把它想象成一个项目的工头它不亲自干活但知道什么时候该派谁去干什么以及活干完了该怎么处理。请求器Fetcher专门负责发送HTTP请求和接收响应。框架一般会内置一个基于aiohttp或httpx的异步请求器这是目前高性能爬虫的标配。它的好处是能同时处理成百上千个网络请求而不会因为等待某个慢速网站而阻塞整个流程。解析器Parser这是业务逻辑最集中的地方。你需要在这里告诉框架拿到网页HTML后如何提取出你想要的数据。harvest通常不强制你使用特定的解析库如BeautifulSoup或parsel而是让你自由选择它只关心你最终返回的结构化数据。管道Pipeline数据被解析出来后需要经过一系列处理才能最终保存。管道就是一系列的数据处理器比如数据清洗、去重、验证、格式化最后写入数据库或文件。每个管道只做一件事通过串联它们来完成复杂的数据处理流水线。中间件Middleware这是框架扩展性的关键。你可以在请求发出前、响应返回后、数据解析前后等关键节点插入自定义逻辑。比如自动添加代理IP、随机更换User-Agent、处理特定的反爬机制如验证码等都可以通过中间件来实现。这种模块化设计带来的最大好处是可测试性和可替换性。你可以单独为解析器写单元测试模拟一个HTML字符串检查是否能正确提取数据。当某个网站更换了反爬策略你可能只需要更新对应的中间件而不必触动核心的业务逻辑代码。2.2 异步优先与并发控制现代Web爬虫异步IO几乎是必选项。tfukaza/harvest在设计之初就拥抱了异步asyncio。这意味着它的核心执行引擎是基于事件循环的可以高效地管理大量并发的网络I/O操作。但“异步”不等于“无限制并发”。很多新手会犯一个错误开几百个协程同时去请求同一个网站结果瞬间就把对方的服务器打挂或者触发严厉的反爬封禁。harvest在这方面通常提供了优雅的解决方案——信号量Semaphore和延迟控制。在框架的配置中你经常会看到类似concurrent_requests或delay这样的参数。这不仅仅是几个数字背后是礼貌爬虫的实践。例如你可以设置“同一域名下最多同时进行5个请求”以及“每个请求之间至少间隔1秒”。框架的请求器会自动帮你管理这个队列确保你的爬虫既高效又“友好”不会对目标站点造成过大压力。注意合理设置并发和延迟不仅是道德问题也是技术问题。过于激进的请求频率是导致IP被封锁的最常见原因。我通常的做法是先以非常保守的参数如并发数2延迟2秒开始测试观察目标站点的响应速度和是否有异常状态码如429 Too Many Requests再逐步调整到一个稳定且高效的平衡点。3. 从零开始构建你的第一个采集任务3.1 环境搭建与基础配置上手harvest的第一步是安装。由于它通常是一个纯Python库安装非常简单。我强烈建议在虚拟环境中进行以避免依赖冲突。# 创建并激活虚拟环境以venv为例 python -m venv harvest_env source harvest_env/bin/activate # Linux/macOS # harvest_env\Scripts\activate # Windows # 安装harvest框架 pip install harvest-framework # 注意这里使用了一个假设的包名实际请参考项目README # 通常还需要安装异步HTTP客户端和解析库 pip install aiohttp beautifulsoup4安装完成后我们来创建一个最简单的采集脚本。假设我们的目标是抓取某个新闻网站首页的文章标题和链接。首先我们需要定义一个“种子”任务。在爬虫领域种子就是起始的URL列表。harvest通常需要一个入口点来启动整个采集流程。# my_news_spider.py import asyncio from harvest import Harvester, Request async def main(): # 1. 初始化采集器并传入一些基本配置 harvester Harvester( concurrent_requests3, # 控制并发数 request_delay1.0, # 请求间隔1秒 ) # 2. 定义种子URL seed_urls [ https://example-news.com/page/1, https://example-news.com/page/2, ] # 3. 将种子URL包装成框架能理解的“请求”对象并添加到采集器 for url in seed_urls: request Request(urlurl, callbackparse_list_page) # callback指定处理响应的函数 await harvester.add_request(request) # 4. 启动采集引擎 await harvester.run() # 这个函数将在收到列表页响应后被调用 async def parse_list_page(response): # response对象通常包含状态码、URL、HTML文本等内容 print(f开始解析: {response.url}) # 这里暂时只打印状态码 print(f状态码: {response.status}) # 实际的数据提取逻辑将在下一步添加 if __name__ __main__: asyncio.run(main())运行这个脚本如果配置正确你应该能看到采集器开始工作并打印出每个URL的访问状态。这只是一个“Hello World”级别的示例它验证了环境、网络和框架的基本运行能力。3.2 实现核心解析逻辑采集器能拿到网页HTML了下一步就是从中提取有价值的数据。这就是parse_list_page函数要做的事。我们使用BeautifulSoup来演示当然你也可以用lxml或parsel看个人喜好。首先我们需要修改parse_list_page函数让它真正地解析HTMLfrom bs4 import BeautifulSoup async def parse_list_page(response): # 检查请求是否成功 if response.status ! 200: print(f请求失败: {response.url}, 状态码: {response.status}) return html response.text soup BeautifulSoup(html, html.parser) articles [] # 假设新闻列表项的CSS选择器是 .article-list .item for item in soup.select(.article-list .item): title_elem item.select_one(h2.title a) if title_elem: title title_elem.get_text(stripTrue) link title_elem.get(href) # 确保链接是绝对URL if link and not link.startswith(http): link response.urljoin(link) # 这是一个有用的工具方法拼接相对路径 if title and link: articles.append({ title: title, url: link, source_page: response.url, crawled_at: datetime.now().isoformat() }) print(f从 {response.url} 中提取到 {len(articles)} 篇文章) # 这里我们只是打印后续会介绍如何将数据传递给管道进行处理 for article in articles: print(f - {article[title]}) # 关键一步发现新链接深度采集 # 通常列表页会有分页我们需要提取“下一页”的链接并交给采集器继续抓取 next_page_elem soup.select_one(a.next-page) if next_page_elem and next_page_elem.get(href): next_page_url response.urljoin(next_page_elem[href]) new_request Request(urlnext_page_url, callbackparse_list_page) # 将新请求添加回采集器实现自动翻页 await response.harvester.add_request(new_request) # 假设response对象可以访问到harvester实例 # 对于每篇文章的详情页我们也创建新的请求但使用不同的回调函数 for article in articles: detail_request Request(urlarticle[url], callbackparse_detail_page, meta{article_title: article[title]}) await response.harvester.add_request(detail_request)在上面的代码中有几个关键点错误处理首先检查HTTP状态码避免在错误的响应上做解析。数据提取使用BeautifulSoup的select和select_one方法通过CSS选择器精准定位元素。这是最常用也最稳定的方式。URL规范化使用response.urljoin()来处理相对链接确保我们得到的是可以用于下次请求的绝对URL。链接发现与调度这是爬虫从“单页抓取”变为“网站爬取”的核心。我们不仅提取数据还从当前页中发现新的、需要抓取的URL如“下一页”、文章详情页并将其包装成新的Request对象重新投入采集器的任务队列。这个过程被称为“爬取循环”。接下来我们需要实现parse_detail_page函数来处理文章详情页提取更丰富的内容如正文、作者、发布时间等。async def parse_detail_page(response): if response.status ! 200: return html response.text soup BeautifulSoup(html, html.parser) # 从请求的meta中获取之前提取的标题 article_title response.meta.get(article_title, ) # 提取详情页的特定信息 content_elem soup.select_one(.article-content) content content_elem.get_text(stripTrue) if content_elem else author_elem soup.select_one(.author-name) author author_elem.get_text(stripTrue) if author_elem else publish_time_elem soup.select_one(.publish-time) publish_time publish_time_elem.get(datetime) if publish_time_elem else # 优先取datetime属性 # 构建最终的数据项 data_item { title: article_title, url: response.url, content: content, author: author, publish_time: publish_time, crawled_at: datetime.now().isoformat() } # 到这里我们得到了一个结构化的数据字典。 # 接下来我们需要将它“产出”yield或者传递给管道进行处理。 # 在harvest框架中通常通过一个特定的方法或信号来传递数据。 # 假设框架提供了 produce_item 方法 await response.harvester.produce_item(data_item) # 将数据项送入处理管道现在我们的爬虫已经具备了基本的抓取和解析能力从种子页开始抓取列表页提取文章链接和标题然后跟进到详情页抓取完整内容最后生成结构化的数据项。一个简单的爬虫骨架就搭建完成了。4. 进阶实战管道、中间件与配置化4.1 构建数据处理管道原始数据提取出来后往往不能直接使用需要经过清洗、验证、转换和存储。这就是管道Pipeline的用武之地。harvest的管道通常是一系列按顺序执行的类每个类实现一个简单的process_item方法。假设我们有三个管道一个用于清洗数据一个用于去重最后一个用于保存到JSON文件。# pipelines.py import json import hashlib from some_storage import DeduplicationCache # 假设有一个去重缓存类 class CleaningPipeline: 数据清洗管道 async def process_item(self, item, harvester): # 1. 去除标题和内容首尾的空白字符 if title in item: item[title] item[title].strip() if content in item: item[content] item[content].strip() # 2. 处理空值如果作者为空设置为‘未知’ if not item.get(author): item[author] 未知 # 3. 内容摘要如果内容太长生成一个前100字的摘要 if item.get(content) and len(item[content]) 100: item[summary] item[content][:100] ... else: item[summary] item.get(content, ) # 必须返回处理后的item传递给下一个管道 return item class DeduplicationPipeline: 基于URL哈希的去重管道 def __init__(self): self.seen_urls set() # 内存中去重集合对于大量数据需用外部存储如Redis # 或者 self.cache DeduplicationCache() async def process_item(self, item, harvester): url item.get(url) if not url: return None # 没有URL丢弃该条目 # 生成URL的指纹哈希值 url_hash hashlib.md5(url.encode()).hexdigest() if url_hash in self.seen_urls: print(f重复项已跳过: {url}) return None # 返回None表示丢弃此项目 else: self.seen_urls.add(url_hash) return item # 返回item表示继续处理 class JsonExportPipeline: 将数据保存到JSON文件的管道 def __init__(self, output_fileoutput.json): self.output_file output_file self.data_buffer [] # 缓冲列表避免频繁写文件 self.buffer_size 10 # 每10条数据写一次文件 async def process_item(self, item, harvester): self.data_buffer.append(item) if len(self.data_buffer) self.buffer_size: await self._flush_buffer() return item # 通常导出管道是最后一环但仍需返回item async def _flush_buffer(self): 将缓冲区的数据写入文件 if not self.data_buffer: return try: # 采用追加模式写入确保多次运行不会覆盖旧数据 with open(self.output_file, a, encodingutf-8) as f: for item in self.data_buffer: json.dump(item, f, ensure_asciiFalse) f.write(\n) # 每行一个JSON对象即JSON Lines格式 print(f已写入 {len(self.data_buffer)} 条数据到 {self.output_file}) self.data_buffer.clear() except IOError as e: print(f写入文件失败: {e}) async def close(self): 管道关闭时确保缓冲区剩余数据被写入 await self._flush_buffer()在初始化采集器时我们需要注册这些管道并指定它们的执行顺序# 在主函数中初始化采集器时配置管道 harvester Harvester( concurrent_requests3, request_delay1.0, pipelines[ # 管道按顺序执行 CleaningPipeline(), DeduplicationPipeline(), JsonExportPipeline(output_filenews_articles.jsonl), ] )管道模式的好处是职责分离。清洗逻辑变了只改CleaningPipeline。想换一种存储方式比如存到数据库再写一个DatabasePipeline替换掉JsonExportPipeline即可其他部分完全不用动。4.2 利用中间件应对反爬策略没有任何防护的网站越来越少了。常见的反爬手段包括检查请求头特别是User-Agent、限制访问频率、使用Cookie或Session跟踪、甚至弹出JavaScript验证。中间件Middleware是harvest框架中处理这些问题的利器。中间件允许你在请求发出前和收到响应后插入自定义逻辑。下面我们实现两个实用的中间件# middlewares.py import random from fake_useragent import UserAgent # 需要安装pip install fake-useragent class RandomUserAgentMiddleware: 随机更换User-Agent中间件 def __init__(self): self.ua UserAgent() async def before_request(self, request, harvester): # 在请求发出前为request对象添加一个随机的User-Agent头 if not request.headers: request.headers {} request.headers[User-Agent] self.ua.random # 可以添加其他常见头模拟浏览器 request.headers.update({ Accept: text/html,application/xhtmlxml,application/xml;q0.9,*/*;q0.8, Accept-Language: zh-CN,zh;q0.9,en;q0.8, Accept-Encoding: gzip, deflate, br, Connection: keep-alive, }) return request class RetryMiddleware: 失败重试中间件 def __init__(self, max_retries3): self.max_retries max_retries async def after_response(self, response, harvester): # 收到响应后检查状态码。如果是5xx服务器错误或429请求过多进行重试 if response.status 500 or response.status 429: request response.request # 获取原始的请求对象 retries getattr(request, retry_count, 0) if retries self.max_retries: retries 1 request.retry_count retries print(f请求 {request.url} 失败状态码{response.status}第 {retries} 次重试...) # 指数退避每次重试等待时间加倍避免加重服务器负担 delay 2 ** retries await asyncio.sleep(delay) # 将请求重新加入队列 await harvester.add_request(request) return None # 返回None表示这个响应不继续传递给回调函数处理 # 如果不需要重试直接返回response让流程继续 return response同样需要在初始化采集器时注册中间件harvester Harvester( concurrent_requests3, request_delay1.0, pipelines[...], middlewares[ # 中间件按注册顺序执行 RandomUserAgentMiddleware(), RetryMiddleware(max_retries2), ] )实操心得中间件的执行顺序很重要。通常修改请求的中间件如RandomUserAgentMiddleware应该在处理响应的中间件如RetryMiddleware之前注册。因为你需要先准备好一个“像样”的请求发出去然后才谈得上对它的响应进行处理。框架一般会保证before_request按注册顺序执行after_response按相反顺序执行。4.3 项目配置与最佳实践当爬虫逻辑变得复杂时把配置硬编码在脚本里会很难维护。一个好的实践是使用配置文件如config.yaml或config.py来管理所有可调参数。# config.yaml harvester: concurrent_requests: 5 request_delay: 1.5 max_depth: 3 # 最大爬取深度防止无限爬取 timeout: 30 # 请求超时时间秒 fetcher: verify_ssl: false # 是否验证SSL证书内网或测试环境可关闭 proxy: null # 代理服务器地址例如: http://user:passhost:port spider: start_urls: - https://example-news.com/page/1 - https://example-tech.com/latest allowed_domains: # 限制爬虫只爬取指定域名下的链接 - example-news.com - example-tech.com pipelines: - name: CleaningPipeline - name: DeduplicationPipeline - name: JsonExportPipeline params: output_file: data/{{CURRENT_DATE}}.jsonl # 支持模板变量 middlewares: - name: RandomUserAgentMiddleware - name: RetryMiddleware params: max_retries: 3然后在主程序中加载配置import yaml from harvest import Harvester from my_pipelines import CleaningPipeline, DeduplicationPipeline, JsonExportPipeline from my_middlewares import RandomUserAgentMiddleware, RetryMiddleware def load_config(config_pathconfig.yaml): with open(config_path, r, encodingutf-8) as f: config yaml.safe_load(f) return config def create_harvester_from_config(config): # 动态创建管道和中间件实例 pipeline_instances [] for p_config in config[pipelines]: cls globals()[p_config[name]] params p_config.get(params, {}) pipeline_instances.append(cls(**params)) middleware_instances [] for m_config in config[middlewares]: cls globals()[m_config[name]] params m_config.get(params, {}) middleware_instances.append(cls(**params)) # 创建采集器 harvester Harvester( concurrent_requestsconfig[harvester][concurrent_requests], request_delayconfig[harvester][request_delay], pipelinespipeline_instances, middlewaresmiddleware_instances, # ... 其他配置 ) return harvester, config async def main(): config load_config() harvester, config create_harvester_from_config(config) # 从配置中读取种子URL for url in config[spider][start_urls]: request Request(urlurl, callbackparse_list_page) await harvester.add_request(request) await harvester.run()配置化带来的好处是巨大的环境隔离开发、测试、生产环境用不同配置、参数灵活调整不用改代码就能调并发数、以及便于团队协作和版本管理。5. 性能调优、监控与问题排查5.1 性能瓶颈分析与优化当采集任务涉及成千上万个页面时性能就成为关键。harvest作为异步框架性能瓶颈通常不在CPU而在I/O和资源管理上。以下是一些常见的优化方向并发数调优concurrent_requests不是越大越好。你需要找到一个甜点。我的经验公式是目标网站平均响应时间(秒) * 期望吞吐量(页/秒) 并发数。例如网站平均响应0.5秒你想每秒抓取10页那么并发数设为5左右起步。然后通过监控实际吞吐量和错误率特别是429状态码来微调。连接池与会话复用对于需要登录或使用相同Cookie的网站复用HTTP会话Session比为每个请求创建新连接要高效得多。检查harvest的请求器是否支持配置一个共享的aiohttp.ClientSession。复用会话可以保持TCP连接减少SSL握手开销。DNS缓存频繁解析同一个域名也会消耗时间。可以配置一个本地DNS缓存或者使用像aiodns这样的异步DNS解析库来提升速度。响应处理优化如果页面很大但你需要的数据只在开头一小部分可以考虑流式解析或者只下载响应头确认内容类型和大小后再决定是否下载全部body。aiohttp支持分块接收响应。内存管理长时间运行后注意内存泄漏。确保在回调函数中不要无意间创建全局变量或循环引用。定期检查采集器的任务队列长度如果队列无限增长说明生产发现新链接速度远大于消费抓取解析速度需要调整并发策略或增加去重严格性。5.2 日志记录与运行监控“黑盒”运行的爬虫是危险的。你必须知道它正在做什么、做得怎么样。集成完善的日志系统至关重要。import logging import sys def setup_logging(log_levellogging.INFO): 配置日志格式和输出 logger logging.getLogger(harvest_spider) logger.setLevel(log_level) # 避免重复添加handler if not logger.handlers: # 控制台输出 console_handler logging.StreamHandler(sys.stdout) console_formatter logging.Formatter( %(asctime)s - %(name)s - %(levelname)s - %(message)s ) console_handler.setFormatter(console_formatter) logger.addHandler(console_handler) # 文件输出 file_handler logging.FileHandler(spider.log, encodingutf-8) file_formatter logging.Formatter( %(asctime)s - %(name)s - %(levelname)s - %(filename)s:%(lineno)d - %(message)s ) file_handler.setFormatter(file_formatter) logger.addHandler(file_handler) return logger # 在采集器或各个组件中使用 logger setup_logging() async def parse_list_page(response): logger.info(f开始解析列表页: {response.url}) try: # ... 解析逻辑 logger.debug(f从 {response.url} 提取到 {len(articles)} 个链接) except Exception as e: logger.error(f解析页面 {response.url} 时发生错误: {e}, exc_infoTrue)除了日志还可以添加简单的指标统计并在控制台定期输出报告class StatsCollector: 简单的统计收集器 def __init__(self): self.start_time None self.request_count 0 self.success_count 0 self.item_count 0 self.error_count 0 def start(self): self.start_time asyncio.get_event_loop().time() def record_request(self): self.request_count 1 def record_success(self): self.success_count 1 def record_item(self): self.item_count 1 def record_error(self): self.error_count 1 def get_report(self): if not self.start_time: return 统计未开始 elapsed asyncio.get_event_loop().time() - self.start_time rps self.request_count / elapsed if elapsed 0 else 0 return ( f运行时间: {elapsed:.1f}s | f总请求: {self.request_count} | f成功: {self.success_count} | f失败: {self.error_count} | f提取数据: {self.item_count} | f平均速率: {rps:.2f} req/s ) # 在主循环中定期打印报告 async def main(): stats StatsCollector() stats.start() harvester Harvester(...) # 启动一个后台任务每10秒打印一次统计 async def print_stats(): while True: await asyncio.sleep(10) print(stats.get_report()) asyncio.create_task(print_stats()) # ... 其余启动逻辑5.3 常见问题排查实录在实际使用中你肯定会遇到各种问题。下面是我踩过的一些坑和解决方法问题1爬虫运行一段时间后突然变慢最后似乎卡住了。排查首先查看日志是否有大量错误或重试。然后检查网络连接和系统资源CPU、内存、网络带宽。使用top或htop命令查看进程状态。可能原因与解决内存泄漏Python的异步任务如果未被正确取消或存在循环引用可能导致内存无法释放。使用tracemalloc等工具进行内存分析。确保在任务完成或异常时所有对大型对象如完整的HTML字符串的引用都被释放。连接未关闭检查请求器是否正确关闭了HTTP响应体。在aiohttp中即使你不主动读取响应内容也需要调用response.release()或确保响应在异步上下文管理器中被正确处理。任务队列阻塞如果某个回调函数执行了同步的、耗时的操作如复杂的计算、同步的文件IO会阻塞整个事件循环。确保所有耗时操作都是异步的或者使用asyncio.to_thread将其放到线程池中执行。问题2遇到动态加载JavaScript渲染的页面抓取到的HTML是空的或者只有框架。解决harvest这类基础框架通常不内置浏览器引擎。你需要分析网络请求使用浏览器开发者工具的“网络”选项卡查看页面数据是通过哪个API接口获取的通常是XHR或Fetch请求。直接去模拟请求那个接口往往更简单高效。集成无头浏览器如果数据必须通过JS执行才能生成可以考虑集成playwright或selenium。但这会极大增加资源消耗和复杂度。一个折中方案是在中间件中判断如果是特定URL则使用无头浏览器来获取渲染后的HTML然后交给原有的解析器处理。问题3数据重复率很高。排查检查去重管道的逻辑。你使用的是URL去重但可能同一个内容对应多个不同的URL比如带有不同查询参数的URL。或者网站在不同位置展示了同一篇文章。解决内容指纹去重不仅对URL去重也对提取出的核心内容如标题正文的前N个字符的哈希值去重。规范化URL在去重前对URL进行规范化处理比如移除utm_source、fbclid等跟踪参数只保留核心路径和查询键。问题4被网站封禁IP。预防与应对遵守robots.txt在发起请求前先检查目标网站的robots.txt尊重其爬取规则。使用代理池这是应对IP封锁最有效的方法。可以集成第三方代理服务或在中间件中实现代理IP的自动切换和失效剔除。模拟人类行为除了随机User-Agent还可以在请求中随机加入Referer头并模拟人类的点击间隔随机延迟而非固定延迟。设置熔断机制当连续遇到多个403/429状态码时自动暂停对该域名的爬取一段时间如10分钟然后重试。最后我想分享的一点体会是tfukaza/harvest这类轻量级框架给了你最大的灵活度但也把很多责任交给了开发者。它不像Scrapy那样“开箱即用”需要你自己去搭建很多轮子比如分布式、精细的监控、复杂的调度策略。但这正是它的魅力所在——它不会用复杂的抽象和概念把你框住你可以根据项目的实际规模从一个小脚本开始逐步演进成一个健壮的、可维护的数据采集系统。对于大多数中小型、定制化要求高的爬虫任务来说这种“按需组装”的方式往往更高效、更可控。