分布式爬虫农场架构解析：从核心原理到工程实践

1. 项目概述：从“权限实验室”到“爬虫农场”的构想

最近在GitHub上看到一个挺有意思的项目，叫claw-farm，来自一个叫PermissionLabs的组织。光看这个名字，就透着一股子“规模化”、“工业化”的味道。Claw是爪子，通常指代爬虫（Crawler），Farm是农场，合起来就是“爬虫农场”。这可不是一个简单的单机爬虫脚本，而是一个旨在管理和运行大规模、分布式网络爬虫集群的框架或平台。PermissionLabs这个名字也很有意思，直译是“权限实验室”，暗示着项目可能对爬虫的访问权限、频率控制、合规性有特别的关注。

对于任何一个处理过海量数据采集的开发者来说，单点爬虫的局限性是显而易见的：IP容易被封、速度受限于单机带宽、任务管理混乱、数据去重和存储成为瓶颈。claw-farm瞄准的正是这个痛点。它试图将爬虫任务像农作物一样，在“农场”里进行播种、培育、收割和轮作，实现自动化、可观测和弹性伸缩。简单来说，它想让你像管理一个服务器集群一样，去管理你的成千上万个爬虫“工人”。

这个项目适合谁呢？首先是数据工程师和爬虫工程师，当你需要从成百上千个网站稳定、高效地采集数据，并且数据量达到TB甚至PB级别时，自己从零搭建分布式系统会非常痛苦。其次是业务分析师或研究者，你可能不擅长底层架构，但你需要一个开箱即用的工具来帮你调度复杂的采集任务。最后，任何对分布式系统、任务队列、反爬对抗实战感兴趣的技术爱好者，都能从这个项目的设计中汲取灵感。

2. 核心架构与设计哲学解析

一个优秀的分布式爬虫框架，其价值远不止于把代码扔到多台机器上跑。claw-farm的设计必然围绕几个核心问题展开：任务如何分发？状态如何同步？故障如何应对？资源如何调度？虽然我们看不到其全部源码，但可以基于同类优秀项目（如Scrapy Cluster、Colly + NSQ等）和其项目名隐含的意图，来拆解其可能的设计思路。

2.1 中心化调度与去中心化执行的权衡

分布式系统首要的设计抉择就是中心化与去中心化。纯粹的P2P爬虫网络（如早期一些比特币相关的爬虫）虽然健壮，但协调成本高，难以统一管理。claw-farm更可能采用一种“中心调度，边缘执行”的混合架构。

• 调度中心（Master/Farmer）：这是农场的大脑。它负责任务队列的管理、爬虫节点的状态监控、任务的分发与回收、全局去重（Bloom Filter或Redis Set）以及策略的下发（如爬取频率、代理IP池分配）。它可能是一个独立的服务，基于如 Celery + RabbitMQ/Redis， 或更专业的如 Apache Airflow、Dagster 进行DAG（有向无环图）任务编排。
• 爬虫节点（Worker/Crawler）：这些是农场的“手”和“脚”。它们从调度中心领取任务（一个URL或一个网站域名），执行具体的下载、解析、数据提取工作，然后将结果（数据和新的URL）回传给调度中心。每个节点应该是无状态的，可以随时扩容或销毁。它们可能基于 Scrapy、Playwright、Selenium 等爬虫框架构建。

注意：调度中心是单点故障源。高可用设计至关重要，通常采用主从（Master-Slave）或基于Raft/Paxos共识算法的多主集群。PermissionLabs的命名可能意味着它在这方面（如基于ZooKeeper/Etcd的服务发现与选举）有特别的设计。

2.2 任务队列与消息通信

这是分布式爬虫的血管系统。任务（URL请求）、结果（Item数据）、控制指令（如暂停、变更频率）都需要在组件间流动。

1. 任务队列：通常使用 Redis List/Sorted Set 或专业的消息队列如 RabbitMQ、Kafka、NSQ。Redis 简单高效，适合任务量不是极端巨大的场景；Kafka 吞吐量极高，适合海量数据流，但运维复杂；NSQ 去中心化，部署简单。claw-farm可能会抽象一层，支持可插拔的后端。
2. 消息格式：消息体需要标准化。一个任务消息可能包含：url,method,headers,cookies,meta（深度、优先级、回调函数名、代理要求等）。结果消息则包含：原始url,状态码,响应内容/数据,新发现的urls列表。
3. 优先级与去重：不是所有URL都平等。首页、详情页、列表页应有不同的优先级（可在Redis Sorted Set中用分数表示）。去重必须在调度中心全局进行，通常使用Redis的Set结构，或更节省内存的Bloom Filter（有误判率，但可接受）。

2.3 资源管理与反爬策略集成

“农场”意味着对资源的精细化管理。

• IP代理池：这是大规模爬虫的命脉。框架需要集成代理IP池的管理模块，包括代理的获取（从供应商API或自建）、验证（定时检查可用性和速度）、分配（按任务、按网站分配不同的代理）和熔断（标记失效代理）。
• 频率控制：必须尊重robots.txt并对每个目标域名进行独立的请求频率控制。这需要在调度中心维护一个“域名-最后访问时间”的字典，并结合漏桶或令牌桶算法进行限流。PermissionLabs可能强调这方面的合规性设计。
• 浏览器指纹与会话管理：对于需要登录或JavaScript渲染的网站，爬虫节点需要管理复杂的会话（Cookies, LocalStorage）和模拟不同的浏览器指纹（User-Agent, Viewport等）。框架可能需要为每个“爬虫身份”维护一套隔离的环境。

2.4 数据持久化与监控

采集来的数据需要安全、有序地存储。框架可能不强制规定存储介质，但会提供灵活的Pipeline接口，让数据可以写入到文件（JSON Lines）、数据库（MySQL, PostgreSQL）、数据仓库（ClickHouse）、搜索引擎（Elasticsearch）或消息队列（Kafka）中。

监控是运维的“眼睛”。一个成熟的claw-farm应当提供：

• 指标仪表盘：实时显示总任务数、进行中任务数、成功/失败率、各节点负载、数据采集速度。
• 日志聚合：所有节点的日志集中收集到如 ELK（Elasticsearch, Logstash, Kibana）或 Loki 栈中，方便排查问题。
• 告警机制：当失败率飙升、节点失联或采集速度低于阈值时，通过邮件、Slack、钉钉等渠道告警。

3. 核心模块的实操实现与代码拆解

让我们构想一个简化版的claw-farm核心实现，使用 Python 语言，结合 Redis 作为消息中间件和状态存储。我们将构建三个核心组件：TaskScheduler（调度器）、CrawlerWorker（爬虫工人）和ResultProcessor（结果处理器）。

3.1 调度器（TaskScheduler）的实现

调度器是单点，我们使用 Flask 提供一个简单的API来接收任务，并使用 Redis 作为后端。

# scheduler.py import redis import json import time from flask import Flask, request, jsonify from bloom_filter import BloomFilter # 需要安装 pybloom-live app = Flask(__name__) # 连接Redis redis_client = redis.Redis(host='localhost', port=6379, db=0) # 初始化布隆过滤器，预计100万条数据，误判率0.001 url_bloom = BloomFilter(max_elements=1000000, error_rate=0.001) # 定义Redis键名 TASK_QUEUE = 'claw_farm:tasks' DOMAIN_DELAY = 'claw_farm:domain_delay' # 存储每个域名下一次允许请求的时间戳 @app.route('/submit_seed', methods=['POST']) def submit_seed(): """接收初始种子URL""" data = request.json urls = data.get('urls', []) for url in urls: # 去重检查 if url in url_bloom: continue # 构造任务消息 task = { 'url': url, 'meta': { 'depth': 0, 'priority': 1, 'callback': 'parse_list', # 指定回调函数 'proxy': None } } # 推入任务队列（左进） redis_client.lpush(TASK_QUEUE, json.dumps(task)) # 加入布隆过滤器 url_bloom.add(url) return jsonify({'status': 'ok', 'submitted': len(urls)}) def dispatch_task(): """核心调度循环：从队列取任务，检查频率限制，分发给空闲Worker""" while True: # 从任务队列右边阻塞弹出任务（BRPOP是阻塞的，避免空转） _, task_json = redis_client.brpop(TASK_QUEUE, timeout=30) if not task_json: continue task = json.loads(task_json) url = task['url'] domain = get_domain(url) # 频率控制：检查该域名是否处于冷却期 next_allowed = redis_client.hget(DOMAIN_DELAY, domain) current_time = time.time() if next_allowed and float(next_allowed) > current_time: # 还没到时间，把任务塞回队列，稍后再处理。可以放入一个延迟队列（如Redis Sorted Set）。 delay = float(next_allowed) - current_time redis_client.zadd('claw_farm:delayed_tasks', {task_json: current_time + delay}) continue # 找到空闲的Worker（这里简化，实际可用Redis的Set记录空闲Worker ID） # 假设我们通过一个'claw_farm:free_workers'的List来管理 worker_id = redis_client.rpop('claw_farm:free_workers') if worker_id: # 将任务分配给这个Worker redis_client.lpush(f'claw_farm:worker:{worker_id}:inbox', task_json) # 设置该域名的下一次允许请求时间（例如，3秒后） redis_client.hset(DOMAIN_DELAY, domain, current_time + 3.0) else: # 没有空闲Worker，把任务放回原队列头部，稍后重试 redis_client.lpush(TASK_QUEUE, task_json) time.sleep(1) if __name__ == '__main__': # 启动调度循环线程 import threading dispatcher_thread = threading.Thread(target=dispatch_task, daemon=True) dispatcher_thread.start() # 启动Flask API服务 app.run(host='0.0.0.0', port=5000)

关键点解析：

1. 去重：使用内存中的布隆过滤器，速度快且省内存。但重启后数据丢失，因此生产环境需要可持久化的布隆过滤器（如RedisBloom模块）或结合Redis Set做二级备份。
2. 频率控制：使用一个Redis Hash来记录每个域名下一次允许爬取的时间戳。这是一种简化的令牌桶实现。更精细的控制需要维护每个域名的请求历史队列。
3. 任务分配：通过一个“空闲工人列表”来模拟简单的负载均衡。实际生产环境会用更健壮的服务发现机制，如每个Worker定期向调度中心发送心跳。

3.2 爬虫工人（CrawlerWorker）的实现

工人节点是独立的进程，可以从任何地方启动，只要它能连接到Redis和调度中心。

# worker.py import redis import json import requests from urllib.parse import urljoin import logging import sys import threading logging.basicConfig(level=logging.INFO) logger = logging.getLogger(__name__) class CrawlerWorker: def __init__(self, worker_id, redis_host='localhost', redis_port=6379): self.worker_id = worker_id self.redis_client = redis.Redis(host=redis_host, port=redis_port, db=0) self.inbox_key = f'claw_farm:worker:{worker_id}:inbox' self.result_queue = 'claw_farm:results' self.session = requests.Session() # 向调度中心注册自己为空闲状态 self._register() def _register(self): """注册到空闲工人列表""" self.redis_client.lpush('claw_farm:free_workers', self.worker_id) logger.info(f"Worker {self.worker_id} registered.") def _fetch_task(self): """从自己的收件箱获取任务（阻塞）""" _, task_json = self.redis_client.brpop(self.inbox_key, timeout=5) return json.loads(task_json) if task_json else None def _crawl(self, task): """执行实际的爬取任务""" url = task['url'] meta = task.get('meta', {}) try: # 这里可以加入代理逻辑：meta.get('proxy') response = self.session.get(url, headers={'User-Agent': 'Mozilla/5.0'}, timeout=10) response.raise_for_status() html_content = response.text # 根据meta中的callback字段，调用对应的解析函数 callback_name = meta.get('callback', 'parse_general') parse_func = getattr(self, callback_name, self.parse_general) items, new_urls = parse_func(html_content, url) # 处理结果 result = { 'original_url': url, 'status': 'success', 'data': items, 'new_urls': new_urls, 'worker_id': self.worker_id } # 将结果推送到结果队列 self.redis_client.lpush(self.result_queue, json.dumps(result)) logger.info(f"Worker {self.worker_id} successfully crawled {url}") except Exception as e: logger.error(f"Worker {self.worker_id} failed to crawl {url}: {e}") # 推送失败结果 result = { 'original_url': url, 'status': 'failed', 'error': str(e), 'worker_id': self.worker_id } self.redis_client.lpush(self.result_queue, json.dumps(result)) def parse_list(self, html, base_url): """示例：解析列表页，提取详情页链接和本页数据""" # 这里应使用如BeautifulSoup或Parsel进行解析 # 假设我们提取到了详情页链接 items = [] # 列表页本身的数据 new_urls = [] # 模拟解析出5个详情页链接 for i in range(5): detail_url = urljoin(base_url, f'/detail/{i}') new_urls.append(detail_url) return items, new_urls def parse_general(self, html, base_url): """默认解析函数""" return [], [] # 不提取数据，不发现新URL def run(self): """主循环：领取任务 -> 执行 -> 标记空闲""" logger.info(f"Worker {self.worker_id} started.") while True: # 1. 标记自己为空闲，等待任务 self._register() # 2. 阻塞获取任务 task = self._fetch_task() if not task: continue # 3. 执行爬取 self._crawl(task) # 循环回到第一步，重新标记空闲 if __name__ == '__main__': worker_id = sys.argv[1] if len(sys.argv) > 1 else 'worker-1' worker = CrawlerWorker(worker_id) worker.run()

实操心得：

• 会话保持：使用requests.Session()可以自动管理Cookies，对于需要登录的网站至关重要。
• 错误处理：必须将爬取失败的任务和原因记录下来，以便后续重试或分析。重试策略（如指数退避）应该在调度器层面实现，而不是Worker。
• 资源隔离：每个Worker进程应该是独立的，避免共享内存状态。这样Worker可以部署在Docker容器中，实现快速扩缩容。

3.3 结果处理器与数据管道

结果处理器监听结果队列，负责去重、数据清洗和持久化。

# result_processor.py import redis import json import pymongo # 假设用MongoDB存储 import threading class ResultProcessor: def __init__(self): self.redis_client = redis.Redis(host='localhost', port=6379, db=0) self.result_queue = 'claw_farm:results' # 连接MongoDB self.mongo_client = pymongo.MongoClient('localhost', 27017) self.db = self.mongo_client['claw_farm_db'] self.collection = self.db['items'] def process(self): """处理结果的主循环""" while True: _, result_json = self.redis_client.brpop(self.result_queue, timeout=5) if not result_json: continue result = json.loads(result_json) if result['status'] == 'success': # 1. 数据持久化 if result['data']: self.collection.insert_many(result['data']) print(f"Inserted {len(result['data'])} items into MongoDB.") # 2. 处理新发现的URL，提交回调度器 new_urls = result.get('new_urls', []) if new_urls: # 这里可以做一个简单的过滤，比如只提交特定域名的URL # 然后通过HTTP请求调用调度器的 /submit_seed API self._submit_new_urls(new_urls) else: # 处理失败任务，可以记录到失败日志，或放入重试队列 print(f"Task failed: {result['original_url']}, error: {result['error']}") self._handle_failure(result) def _submit_new_urls(self, urls): """将新URL提交回调度中心""" import requests try: # 这里调用调度器的API resp = requests.post('http://localhost:5000/submit_seed', json={'urls': urls}, timeout=5) if resp.status_code == 200: print(f"Submitted {len(urls)} new URLs to scheduler.") except Exception as e: print(f"Failed to submit new URLs: {e}") def _handle_failure(self, failed_result): """失败处理策略：例如，重试3次""" url = failed_result['original_url'] retry_key = f'claw_farm:retry:{url}' retry_count = self.redis_client.incr(retry_key) if retry_count <= 3: # 重新构造任务，放回任务队列 task = {'url': url, 'meta': failed_result.get('meta', {})} self.redis_client.lpush('claw_farm:tasks', json.dumps(task)) print(f"Retry ({retry_count}/3) for {url}") else: print(f"URL {url} failed after 3 retries, giving up.") self.redis_client.delete(retry_key) if __name__ == '__main__': processor = ResultProcessor() processor.process()

数据管道设计要点：

• 异步处理：结果处理器应与爬虫Worker异步，避免阻塞爬取流程。
• 幂等性：数据存储操作应保证幂等，防止因重试导致数据重复。
• 背压处理：如果数据写入速度跟不上爬取速度（如数据库慢），需要有机制通知调度器减缓任务分发，避免内存或队列溢出。

4. 部署、运维与性能调优实战

一个框架设计得再好，不能稳定高效地跑起来也是白搭。下面我们谈谈如何将上面这个“玩具”框架，升级为一个可用的“农场”。

4.1 容器化部署与编排

现代分布式系统的首选部署方式是容器化。我们为每个组件（Scheduler, Worker, ResultProcessor）创建Docker镜像。

# Dockerfile for Worker FROM python:3.9-slim WORKDIR /app COPY requirements.txt . RUN pip install --no-cache-dir -r requirements.txt COPY worker.py . CMD ["python", "worker.py", "worker-${HOSTNAME}"] # 使用容器主机名作为Worker ID

然后使用 Docker Compose 或 Kubernetes 进行编排。

# docker-compose.yml 简化版 version: '3.8' services: redis: image: redis:alpine ports: - "6379:6379" scheduler: build: ./scheduler ports: - "5000:5000" depends_on: - redis environment: - REDIS_HOST=redis worker: build: ./worker deploy: replicas: 4 # 启动4个Worker实例 depends_on: - redis - scheduler environment: - REDIS_HOST=redis - SCHEDULER_HOST=scheduler result-processor: build: ./result-processor depends_on: - redis - mongodb environment: - REDIS_HOST=redis - MONGO_HOST=mongodb mongodb: image: mongo:latest ports: - "27017:27017" volumes: - mongo_data:/data/db volumes: mongo_data:

在K8s中，你可以为Worker设置一个Deployment，并轻松地通过kubectl scale命令调整副本数，实现弹性伸缩。

4.2 监控与告警体系建设

没有监控的系统就是在“裸奔”。

1. 指标收集：在每个组件中集成Prometheus客户端库，暴露关键指标。
   • 调度器：任务队列长度、任务分发速率、各域名请求频率。
   • Worker：爬取成功率、平均响应时间、当前活跃任务数。
   • Redis：内存使用量、连接数、命令延迟。
   • 系统：CPU、内存、网络IO（通过Node Exporter）。
2. 日志聚合：将所有容器的日志输出到标准输出（stdout），然后由 Docker 的日志驱动或 K8s 的 DaemonSet（如Fluentd或Filebeat）收集，并发送到Elasticsearch。在Kibana中你可以轻松搜索所有日志，例如：“ERROR” AND “worker-3”。
3. 可视化与告警：使用Grafana连接 Prometheus 数据源，绘制丰富的仪表盘。针对关键指标（如失败率 > 5% 持续5分钟）设置告警规则，并通过Alertmanager将告警发送到钉钉、企业微信或PagerDuty。

4.3 性能瓶颈分析与调优

当你的农场规模变大，一定会遇到瓶颈。以下是常见的瓶颈点及优化思路：

4.4 安全、合规与伦理考量

PermissionLabs的名字提醒我们，权限和合规至关重要。

1. 遵守robots.txt：调度器在分发任务前，应首先获取并解析目标域名的robots.txt，对于明确禁止的目录，直接过滤掉任务。
2. 设置合理的爬取延迟：Crawl-Delay指令或在DOMAIN_DELAY中设置保守的默认值（如3-5秒），避免对目标网站造成压力。
3. 身份标识：在HTTP请求头中设置清晰的User-Agent，包含你的联系邮箱（如YourBotName/1.0 (contact@example.com)），以示友好。
4. 数据使用：仅采集公开数据，尊重版权和隐私。对于个人敏感信息，即使公开也应谨慎处理，必要时进行匿名化。
5. 法律风险：了解目标网站所在地区的法律法规（如欧盟的GDPR，美国的CFAA），确保你的爬取行为在法律允许的范围内。

5. 常见问题排查与实战技巧

在实际运行中，你会遇到各种各样稀奇古怪的问题。下面是一些典型问题的排查思路和实战中积累的技巧。

5.1 任务堆积，Worker却空闲

现象：Redis任务队列很长，但监控显示Worker处于空闲状态，claw_farm:free_workers列表也有Worker ID。

排查步骤：

1. 检查调度器日志：看dispatch_task函数是否在正常运行，是否有异常抛出。
2. 检查频率控制：可能是频率控制过于严格。查看DOMAIN_DELAYHash中，目标域名的下一次允许时间是否被设置到了一个未来的很远的时间点。检查调度器中设置延迟的代码逻辑。
3. 检查网络分区：调度器所在的机器能否ping通Worker？Worker能否连接上Redis？使用redis-cli在调度器主机上尝试连接Redis并执行简单命令。
4. 检查消息格式：Worker的_fetch_task方法是否能正确解析从inbox取出的消息？在Worker代码中加入调试日志，打印收到的原始task_json。

技巧：在调度器中加入一个“看门狗”线程，定期（如每分钟）检查队列长度和空闲Worker数。如果发现队列有任务但长时间无Worker领取，就记录告警并尝试将一些老任务重新放入主队列头部。

5.2 数据重复采集

现象：数据库中出现了大量完全相同的记录。

原因与解决：

1. 去重失效：布隆过滤器存在误判率（我们设置了0.001），意味着有0.1%的URL可能被误判为“未见过”，从而导致重复爬取。解决方案：对于已成功爬取并存储的数据，在数据库层面建立唯一索引（如URL的MD5值）。在ResultProcessor写入前做一次去重查询。这是一种“最终去重”的保障。
2. 任务重试导致重复：网络超时导致任务失败，被重新放回队列，但实际请求可能已到达服务器并成功。解决方案：实现幂等性爬取。为每个任务生成唯一ID，Worker在处理前，先在Redis中用一个Set记录“正在处理的任务ID”。如果处理成功，将ID移入“已处理集合”；如果失败，则从“正在处理集合”中移除。调度器在分发任务前，检查该任务ID是否已在“已处理集合”中。
3. 新URL发现逻辑有误：解析函数parse_list可能从不同页面解析出了相同的URL。解决方案：在解析函数内部，对提取到的URL进行一次简单的基于集合的去重。

5.3 Worker进程莫名崩溃或失联

现象：K8s或Docker Compose日志显示Worker容器不断重启，或者调度器发现Worker心跳停止。

排查：

1. 查看容器退出码和日志：docker logs <container_id>或kubectl logs <pod_name>。常见原因：
   • 内存溢出：解析一个巨大的HTML文件，或数据累积导致内存耗尽。需优化解析代码，使用流式解析（如lxml的迭代解析），或限制单个任务的处理数据量。
   • 被目标网站屏蔽：IP被封，请求返回403/429，如果代码未妥善处理异常可能导致崩溃。加强异常捕获，将任何导致进程退出的异常都在最外层捕获并记录。
   • 依赖库版本冲突：确保所有Worker镜像使用相同版本的基础依赖。
2. 实现健壮的心跳机制：让Worker定期（如每30秒）向Redis写入一个带有时间戳的键（claw_farm:worker_heartbeat:<worker_id>）。调度器启动一个健康检查线程，定期扫描这些键，如果某个Worker的心跳时间超过阈值（如2分钟），则认为其死亡，并将其从空闲列表移除，并将其未完成的任务（可能还在其inbox中）重新收归主队列。

5.4 面对动态渲染（JavaScript）网站

问题：使用requests+BeautifulSoup无法获取到由JavaScript动态生成的内容。

解决方案：

1. 集成无头浏览器：在Worker中集成Playwright或Selenium。这会使Worker从轻量的HTTP客户端变为重量级的浏览器实例，资源消耗大增。
   • 优化：使用浏览器上下文（Context）和页面池，避免为每个任务都启动新浏览器。
   • 部署：需要为Worker镜像安装浏览器和相应的驱动（如Chromium）。
2. 分离渲染层：架构上升级，引入专门的“渲染农场”。普通Worker只处理静态页面，遇到需要JS渲染的URL，将其放入一个特殊的队列。由一组专门运行无头浏览器的“渲染Worker”来消费这个队列，执行JS并将最终HTML返回给普通Worker或直接提交给结果处理器。这样解耦了逻辑，便于单独扩展渲染层。

技巧：不是所有页面都需要JS。先尝试用普通HTTP客户端请求，如果返回的内容中包含诸如<div id="app"></div>这种典型的SPA占位符，再决定是否启用渲染层。

从零开始构建一个稳定、高效、易维护的分布式爬虫农场是一项复杂的工程，claw-farm这类项目为我们提供了宝贵的范式。它不仅仅是一套代码，更是一套包含资源调度、故障容错、监控告警、合规伦理在内的完整解决方案。理解其背后的设计哲学，比单纯使用它更为重要。在实际操作中，你会遇到更多细节挑战，例如CAP定理的权衡、分布式锁的使用、数据一致性保证等，每一个问题都值得深入探索。最好的学习方式，就是亲手搭建一个简化版，然后看着它在你面前“生长”和“劳作”，在这个过程中积累的经验，才是最宝贵的。