爬虫工程师进阶：数据存储与数据清洗实战指南

做爬虫最容易被忽略的一件事，我放在最前面说：爬虫工程师学习路径走到第五阶段，才真正决定你是否能从“会写脚本”进化成“能交付项目”。前四个阶段你在解决怎么把数据拿下来，requests也好、Scrapy也好、Playwright也好，核心都是“抓”。但抓下来的数据到底怎么存、存完怎么用，绝大多数新手是没想清楚的。我在带人的时候经常看到这种情况：爬虫跑得飞快，结果一到数据落库就开始乱来——有人直接往CSV里塞了一堆带换行的字段，有人把所有内容都存成字符串丢进MongoDB，还有人干脆print到控制台就算“存完了”。

这一篇是爬虫工程师学习路径的阶段五完整学习文档，核心就两件事：数据存储和数据清洗。这篇文章适合已经在学爬虫但卡在“数据拿下来之后不知道怎么办”的朋友，也适合那些爬虫能跑但数据质量一塌糊涂、不敢拿去分析的开发者。我会从存储选型、入库实操、清洗方法论、框架整合到问题排查，把我在实际项目里踩过的坑和沉淀下来的套路一次讲清楚。

1. 为什么我把数据存储与清洗放在第五阶段

1.1 如果把爬虫工程师的学习路径看成一棵技能树

阶段一通常是Python基础加网络请求，阶段二学解析（正则、XPath、CSS选择器），阶段三上框架（Scrapy、Playwright这类），阶段四搞并发和反爬应对。到了阶段五，也就是现在，很多人会有一个误区：觉得存储不就是to_csv、insert两个操作吗？实际上完全不是。

存储和清洗之所以必须排在靠后的位置，是因为它们对前置技能有真实要求。你至少需要先理解Python的数据结构——列表、字典、集合的去重机制，MapReduce式的分组聚合思路；需要理解文件系统和编码——UTF-8和GBK的区别，二进制和文本的模式差异；还需要理解基本的关系型数据库查询——建表、插入、去重、索引。这些如果不是在前面几个阶段积累起来的，到了阶段五就会非常吃力。

我当时给团队定的标准是：进入阶段五之前，必须能用Scrapy独立写完一个分页爬虫，并能把数据按字段完整打印出来。这个门槛看起来很低，但它能保证你已经知道“完整的数据长什么样”。如果抓下来的字段都是缺胳膊少腿的，谈存储和清洗都是空中楼阁。

1.2 数据存储与清洗在整个爬虫链路的定位

爬虫的整体链路是“采集 → 解析 → 存储 → 清洗 → 分析/使用”。多数教程把大量篇幅放在采集和解析上，存储往往一笔带过，清洗更是不怎么讲。但在真实项目里，采集和解析可能只占工作量的40%，剩下60%全在存储设计和数据清洗上。

举个实际案例。我们曾经做过头条系资讯的采集，单机并发16个线程，一天大概能抓30万条数据。第一版方案是直接把每条数据json.dumps之后往MySQL里塞，结果跑了两天直接暴露出问题：评论数这个字段抓下来是字符串，有的带“万”字（比如“1.2万”），有的还带“+”（比如“999+”），直接用来排序完全没法看。这就是典型的“数据拿下来但没清洗”造成的脏数据问题。

存储解决的是“数据放哪、怎么放才能高效读写”，清洗解决的是“数据能不能直接用、用起来有没有坑”。这两个环节直接决定了你的爬虫产出是“数据”还是“垃圾”，也决定了后续的数据分析和可视化能不能做下去。第五阶段把这个能力补齐，你的爬虫技术栈才算真正闭环。

2. 数据存储：从文件落盘到数据库入库

2.1 存储格式选型：CSV、JSON、Parquet还是数据库

新手做爬虫存储，第一个问题往往是“到底存成什么格式”。我直接把我实测下来的选型逻辑列出来：

我的习惯是分场景处理：如果是临时调试用的数据，直接CSV；如果字段结构会频繁变化，先用JSONL落盘；如果确定要长期用，则直接进MySQL或MongoDB。对于阶段性学习的练手项目，我强烈建议从CSV和SQLite入手，因为它们的上手成本最低，又能覆盖“文件存储”和“数据库存储”两种典型思路。

另外说一个容易被忽略的点：不要一上来就上数据库。数据量在1万条以内的时候，CSV和JSONL的性能实际上比数据库更好，调试也更方便。数据库是给“数据需要重复查询、多程序共享、增量更新”的场景用的。爬虫数据少的时候硬上数据库，你会发现大半时间都花在建表、改表结构上了。

2.2 MySQL入库实操：从建表到批量插入

如果数据量过了单机的量级，或者项目需要多人协作、需要做增量更新，那MySQL基本是首选。我以资讯爬虫为例，给出一套可以直接抄的落库方案。

先说建表。资讯类数据最常见的字段结构大概是这样的：

CREATE TABLE article ( id BIGINT PRIMARY KEY AUTO_INCREMENT, article_id VARCHAR(64) NOT NULL COMMENT '第三方平台文章ID', title VARCHAR(512) NOT NULL COMMENT '标题', author VARCHAR(128) DEFAULT '' COMMENT '作者', source VARCHAR(64) DEFAULT '' COMMENT '来源站点', publish_time DATETIME DEFAULT NULL COMMENT '发布时间', content MEDIUMTEXT COMMENT '正文', comment_count INT DEFAULT 0 COMMENT '评论数', read_count INT DEFAULT 0 COMMENT '阅读数', url VARCHAR(1024) DEFAULT '' COMMENT '原文链接', created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP, updated_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, UNIQUE KEY uk_article_id (article_id) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='资讯文章表';

几个关键点说一下。第一，article_id一定要加唯一索引，这是做重复判断的关键。很多平台的文章都会在URL或者返回字段里带一个全局唯一ID，它就是天然的幂等键。第二，publish_time用DATETIME而不是字符串。我在项目里见过太多“2024-03-15 08:30:00”这种看似正常的时间字符串，等你要按小时统计的时候才后悔当初没转换。第三，comment_count这种数值字段一定要在清洗后入库，如果原数据是“1.2万”这种，入库前就必须转成整数12000，否则后续做排序分析就是灾难。

写数据不要一条一条INSERT，效率太低。实测下来，单条插入100万条数据可能要跑几个小时，而分批批量插入几分钟就能完成。下面这段是我常用的写法：

import pymysql def batch_insert_articles(items: list, conn): """items: list[dict], 每项包含 article_id, title, author 等字段""" sql = """ INSERT INTO article (article_id, title, author, source, publish_time, content, comment_count, read_count, url) VALUES (%s, %s, %s, %s, %s, %s, %s, %s, %s) ON DUPLICATE KEY UPDATE title = VALUES(title), comment_count = VALUES(comment_count), read_count = VALUES(read_count), updated_at = CURRENT_TIMESTAMP """ params = [] for item in items: params.append(( item["article_id"], item["title"], item["author"], item["source"], item["publish_time"], item["content"], int(item["comment_count"]), int(item["read_count"]), item["url"] )) with conn.cursor() as cursor: cursor.executemany(sql, params) conn.commit()

这里用了INSERT ... ON DUPLICATE KEY UPDATE，目的就是幂等写库。同一个article_id如果已经存在，就更新标题、评论数、阅读数，而不会重复插入。这种方式在面对增量爬取时非常省心：你不需要先查一遍数据是否存在再决定插入还是更新，数据库自己会处理。

批量大小也有讲究。我测试的时候发现，executemany一次批量提交500到1000条左右表现最稳定。太少的话数据库交互次数太多，太多的话Python层拼参数和MySQL层解析都会变慢，甚至可能撑爆max_allowed_packet的限制。

2.3 再说说SQLite和MongoDB的适用差别

有一段时期我挺喜欢用SQLite存中小型爬虫数据的，因为它真的零配置，文件往项目目录一放就能跑。SQLite和MySQL用起来非常像，只需要把连接方式从pymysql.connect换成sqlite3.connect("data.db")就行，SQL语句基本通用。它的最大限制是并发写入能力差——如果你的爬虫是多线程同时写库，SQLite很容易报database is locked。解决办法是让所有写操作都经过一个队列串行化，或者直接换MySQL。

MongoDB则适合字段结构经常变的场景。比如爬电商商品时，有的商品有优惠券字段，有的有促销活动字段，还可能有赠品信息，你如果每次都要去修改MySQL表结构会想死。MongoDB的文档模型天然支持这种半结构化的数据，直接insert_one(dict)就能存进去。不过要注意，MongoDB没有MySQL那种ON DUPLICATE KEY UPDATE级别的唯一冲突插入，去重要靠你自己先查询再判断，或者用update_one加$setOnInsert操作符配合唯一索引来实现。

2.4 并发场景下写库的正确姿势

爬虫学到后面都会上并发，但并发采集之后的写库如果处理不好，数据库很容易被冲垮。我的经验是设计一个带缓冲的写入器：

import threading import time import queue class AsyncDBWriter: """带缓冲队列的异步写库器，避免每条数据都直接打数据库""" def __init__(self, batch_size=500, interval=2.0): self.queue = queue.Queue() self.batch_size = batch_size self.interval = interval self._stop = False self._thread = threading.Thread(target=self._run, daemon=True) self._thread.start() def submit(self, item: dict): self.queue.put(item) def _run(self): buffer = [] while not self._stop or not self.queue.empty(): try: item = self.queue.get(timeout=0.5) buffer.append(item) if len(buffer) >= self.batch_size: self.flush(buffer) buffer = [] except queue.Empty: if buffer: self.flush(buffer) buffer = [] def flush(self, items): # 内部调用 batch_insert_articles 之类的函数 batch_insert_articles(items, get_conn()) def stop(self): self._stop = True self._thread.join(timeout=10)

用队列做缓冲，生产者（爬虫线程）只管往队列里丢数据，消费者（写库线程）攒够一批或者超过一定时间就批量写一次。这样即使采集端再繁忙，数据库端的压力也是一阵一阵的，而不是每抓一条就打一下库。这样设计之后，我之前那套16线程的采集脚本，数据库负载直接降了一个量级。

在并发写库这里还要提一个容易出问题的点：数据库连接不能所有线程共用。MySQL连接不是线程安全的，多线程使用同一个连接会导致数据错乱或者连接断开。正确的做法要么是每个线程一个独立连接，要么像上面这样用单线程消费者来管理连接。

3. 数据清洗：把脏数据变成能用的数据

3.1 数据清洗到底在洗什么

先说一个宏观结论：所谓数据清洗，就是把你抓下来的原始数据从“能用”变成“有用”。爬虫抓到的数据天然是脏的，主要原因有四个。

第一是缺失。网页改版导致某些字段为空，接口异常导致部分字段缺失，或者本来就只有部分数据包含某个属性。第二是重复。同一个内容在列表页和详情页各抓到一次，不同时间抓取的数据互相重叠，甚至抓取策略本身就会产生重复。第三是格式错乱。数值像字符串、时间戳是多种格式混合、有的文本里带了HTML标签、有的字段混入了空格和换行符。第四是逻辑异常。比如销售量为负数、发布年份为2099年、评论数远大于阅读数。这些数据如果不做处理，拿去做统计、做机器学习训练，出来的结果必然不可信。

我用一个生活化的类比来解释这件事：爬虫采集是这样的——你去菜市场把每一家摊位的菜都收了一遍，有些菜上带了泥，有些菜已经烂了一半，有些根本就是残次品。数据清洗就是把这些菜摘洗干净、挑出坏掉的部分，最后切配好，让后厨（数据分析、算法模型）能直接用。不做清洗的爬虫项目，就是直接把带着泥巴的菜丢给厨师，厨师骂娘是必然的。

3.2 数据清洗的标准流程

我在项目里沉淀下来的清洗流程大致分五步：

1. 格式统一：把所有字段统一成目标类型，字符串去掉首尾空格，时间统一转成datetime或标准字符串，数值统一转成int或float。
2. 缺失值处理：判断每个字段的缺失比例，缺失少的按业务规则填充，缺失多的直接丢弃该字段或该行。
3. 去重：根据业务主键去重，保留最新一条或信息最全的一条。
4. 异常值修正：对取值范围做约束，超出合理范围的值标记或修正。
5. 内容规整：清理文本中的HTML标签、特殊字符、不可见字符，对文本做简体化（如果业务需要）。

这五步的顺序是有讲究的。格式统一放最前面，是因为后面所有处理都依赖统一的类型；去重放中间，是因为去重前需要先决定保留哪一条；异常值修正放第四步，是因为很多异常可能要等到格式统一之后才看得见。如果你上来就做缺失值填充，填进去的数据可能是错位的。

3.3 用Pandas做清洗实操

Pandas是Python数据清洗的地基工具，爬虫工程师到了阶段五必须会用。我直接用一个咨询文章数据清洗的完整案例来演示。

假设我们从接口抓到了下面这种结构的原始数据：

raw_data = [ {"title": " 爬虫入门实战（完整版）", "comment_count": "1.2万", "read_count": "34567", "publish_time": "2024年3月15日 08:30", "content": "<p>文章正文内容...</p>"}, {"title": "如何设计分布式爬虫", "comment_count": "328", "read_count": "120万", "publish_time": "2024-03-14 21:00:00", "content": "文章正文内容..."}, {"title": "Python爬虫反爬策略", "comment_count": "1.2万", "read_count": "8999", "publish_time": "2024/03/13", "content": None}, ]

第一步，先转成DataFrame并做格式统一：

import pandas as pd import re df = pd.DataFrame(raw_data) # 1. 去除字符串首尾空格 df["title"] = df["title"].str.strip() # 2. 把"1.2万"转成整数 def to_number(s): if s is None: return 0 if isinstance(s, (int, float)): return int(s) s = str(s).strip().replace(",", "") if s.endswith("万"): return int(float(s[:-1]) * 10000) if s.endswith("+"): s = s[:-1] return int(float(s)) if s else 0 df["comment_count"] = df["comment_count"].apply(to_number) df["read_count"] = df["read_count"].apply(to_number)

这里有个我在实际项目里反复遇到的坑：“1.2万”不能直接int()转换。字符串转数字看起来简单，一旦出现“万”“亿”“+”这些单位，处理逻辑就不一样了。所以上面的to_number函数是专门处理这类中文数字单位的，实战中你会看到各种奇怪的写法，比如“10万+”“1,200”“1.2亿”，最好提前封装一个通用转换函数。

第三步是时间字段的清洗。这个在爬虫项目里是重灾区，同一个采集项目里可能同时存在“2024年3月15日 08:30”“2024-03-14 21:00:00”“2024/03/13”三种写法。我建议统一转成ISO标准格式字符串，方便入库和比对：

def normalize_time(s): if s is None: return None s = str(s).strip() # 统一把中文年月日替换为横线 s = s.replace("年", "-").replace("月", "-").replace("日", " ") s = re.sub(r"\s+", " ", s).strip() # 缺省时分秒的补上 00:00:00 if re.match(r"^\d{4}-\d{1,2}-\d{1,2}$", s): s = s + " 00:00:00" # 统一斜杠日期 s = s.replace("/", "-") return s df["publish_time"] = df["publish_time"].apply(normalize_time)

写这段函数的时候，要注意正则的匹配边界。我一开始只处理了“年-月-日”，后来同一个函数里又加了对斜杠日期的处理，结果处理“2024/03/13”时因为后面的.replace("/", "-")放在正则判断之后，导致缺省时分秒的判断没触发。调试了半天。正确顺序是先统一分隔符，再做格式补全判断。

第四步处理缺失值和去重：

# 缺失值处理：正文为空的填充 df["content"] = df["content"].fillna("") # 去重：以标题为重复判断键，保留第一条 df = df.drop_duplicates(subset=["title"], keep="first")

去重这块有个原则：去重键的选择决定去重效果。如果是文章类数据，最好用平台的article_id去重，而不是标题。因为有些平台会修改标题或者标题本身就可能重复。如果没有唯一键，再考虑用标题+发布时间组合去重。

3.4 正则与多线程下的清洗边界

除了Pandas，正则表达式也是数据清洗的必备武器。上面已经用到了re.sub，但我多说一句：清洗逻辑里如果涉及到复杂的文本抽取，比如从一段混杂文本中提取电话号码、邮箱、URL、金额等，正则往往是最高效的解法。但正则也有很容易翻车的点——贪婪匹配会吃掉不该吃的内容，回溯过多可能导致性能爆炸。建议写完后多找几个边缘case测试，用re.compile预编译一次，不要每次都在循环里重新编译。

另外要提醒的是：清洗逻辑别和采集逻辑混在一起。我见过太多人把清洗写在解析函数里面，边解析边清洗。看起来省事，但一旦清洗规则需要调整，就得重新跑整个爬虫。我推荐的方式是清晰的阶段划分：爬虫只负责抓取和解析，把原始数据原样落盘或者先丢到临时表，清洗作为独立的一步读取临时数据再处理，处理完再写入正式表。这样既方便调试，也能在清洗出错时保留原始数据，不至于追溯困难。

4. 爬虫工程化：框架整合与实战联动

4.1 从学习到落地：第七阶段前的工程化思维

数据存储和清洗单独学完之后，下一个问题就是怎么把它们嵌入到真实的爬虫框架里。这个阶段不是让你把每个工具都玩得很深，而是让你具备一种工程化思维：代码不是写给自己跑的，而是写给团队维护的，数据不是抓下来就完事，而是要能持续稳定地产出高质量数据。

我在实际项目中的做法，是把采集、存储、清洗三条线分开。采集线由Scrapy的Item Pipeline负责把原始数据推到消息队列或者临时表；存储线由统一的ORM模型负责，避免在爬虫代码里直接拼SQL；清洗线则是独立脚本，定时触发或者由采集完成事件触发。这样设计之后，任何一条线挂了都能单独修复，不用把整个爬虫推倒重来。

4.2 用Scrapy管道实现统一存储

如果你是用Scrapy，官方推荐的数据入库位置是Item Pipeline。我之前专门整理过一版通用的MySQL Pipeline，核心思路是在process_item里做一次轻量校验，然后推给异步写库器：

class MySQLPipeline: def open_spider(self, spider): self.writer = AsyncDBWriter(batch_size=500) def process_item(self, item, spider): # 做一些基础校验，异常数据直接扔掉 if not item.get("title"): spider.logger.warning("missing title, drop item") return item self.writer.submit(dict(item)) return item def close_spider(self, spider): self.writer.stop()

这样做的好处是：Item的校验逻辑和存储逻辑都在Pipeline中集中管理，爬虫主体只负责采集和解析。而且因为用了前面说的异步写库器，Pipeline的process_item是瞬间返回的，不会成为整个爬虫的性能瓶颈。

说到Scrapy存储，有个很容易被新手搞混的概念：Item和字典的区别。Item本质上就是个字典的增强版，但它能在字段定义里声明字段名，拼写错误会在校验时暴露出来。如果你的爬虫字段特别多，强烈建议用Item定义完整字段结构，而不是直接返回dict。我在项目中遇到过几十次因为字段名拼写不一致导致入库列错的坑，用Item之后这类问题基本消失了。

4.3 分布式爬虫下的存储架构

爬虫再往后发展，必然会遇到分布式。分布式爬虫和单机爬虫在存储上的最大区别是：多个节点并行写同一个数据库，冲突和压力会被放大。如果每个节点都直接往MySQL写，数据库连接数很快会被打满，重复数据也会成倍增加。

一个可行的方案是引入消息队列中转。Scrapy节点抓到的数据先推给Kafka或者RabbitMQ，由独立的消费者集群统一落库和清洗。这样数据库只面对有限数量的消费者连接，压力可控；同时多个节点产生的数据得以集中处理，去重、清洗也就有了天然的集中点。对于新手学习阶段，不一定需要马上上Kafka，但至少要有“把写库和采集解耦”的意识。哪怕只是加一个Redis列表做简单的缓冲队列，也比所有节点直接怼数据库要稳健得多。

我自己踩过的一个大坑是：分布式场景下如果还用本地SQLite存储，数据会分散在各节点上，最后根本没法汇总。所以如果目标是分布式，存储选型基本就是MySQL、MongoDB加消息队列的组合。这一点想清楚之后再动手做分布式，能少走很多弯路。

4.4 增量采集：入库、清洗之后真正要修的那道课题

增量采集是数据存储和清洗环节最常碰到的课题。采集系统不能每次全量抓一遍，成本太高，而且会给目标站点造成很大压力。增量采集的核心是“怎么确定哪些数据是新的、哪些是已存在的”。方案就落到了存储设计上。

最简单的方案是刚才提到的唯一索引加ON DUPLICATE KEY UPDATE，也就是“存在就更新，不存在才插入”。再进阶一点，可以根据数据的updated_at或者publish_time做增量判断：只取最近24小时内有更新的数据。更精细的方案是记录目标站点列表页的数据指纹（比如对URL列表做HashSet比对），新增的才去爬详情页。

这里我想强调的其实是清洗的另一个重要任务：增量数据入库前的去重。如果只靠数据库唯一索引兜底，每次更新都会额外执行多次重复写操作，浪费资源。更合理的做法是采集端就维护一个已处理ID的布隆过滤器，抓取前先判断这个ID是不是处理过，处理过就直接跳过。布隆过滤器会有一定的误判率（判断“处理过”但实际没有），但用少量的漏采来换取效率提升，在绝大多数场景下是划算的。误判过滤下掉的数据，后续可以通过定期全量补采来修正。

5. 常见问题速查与进阶建议

5.1 我在实际项目里遇到的高频问题

下面这几个问题是这几个月里被问得最多的，我把排查思路整理成一张速查表：

5.2 合规红线：爬虫数据存下来，不等于可以随便用

这一步必须单独拿出来说，因为太重要了。爬虫工程师处理存储和清洗的时候，看似只是在和数据库打交道，但实际上你保存下来的数据已经进入了“使用”范畴。数据保存不当、使用越界，风险比爬虫本身还大。

我在项目里会坚持几条原则：只爬公开数据，不碰需要登录后才能获取的非公开内容；遵守目标网站的robots.txt协议，至少了解对方是否允许抓取；控制请求频率，不对目标站点造成压力；保存的数据不包含用户的个人隐私信息，如果业务确实需要，必须做脱敏处理。还有一个经常被忽略的点：爬下来的数据用于个人学习研究和用于商业盈利，是完全不同的性质。个人学习练手可以放开一点，但一旦涉及商用，就必须评估数据来源、数据授权和合规风险。

我见过太多人因为贪图某类数据，使用自动化工具突破对方的访问控制，最后导致账号被封、公司被起诉，甚至个人背上刑事责任。爬虫技术本身是中性的，但它触碰的边界需要每个工程师自己把握。学技术没有错，但前提是合法合规，这是红线中的红线。作为工程师，我在项目启动前一定会确认数据的来源和使用方式没有问题，这一点也希望你在阶段五开始就建立起来。技术和法律的红线，必须刻在意识里。

5.3 每个C端项目都要经历的日志与监控

除了上面那些问题，存储和清洗阶段的日志与监控也是一大课题。你可能觉得这是运维的事，但爬虫项目里最有效的监控往往是工程师自己写的。我至少会为每个爬虫项目配置几个维度的监控：采集量（每小时/每天入库条数）、失败率（请求失败/解析失败/入库失败的记录数）、去重率（重复数据触发的次数）以及清洗异常数（某字段转换失败的数量）。

这些监控数据本身也是一种数据，也需要存储。我通常的做法是单独建一张监控日志表，把任务的开始时间、结束时间、成功数、失败数、耗时都记录下来。跑到后面你会感激这些日志，因为当数据出问题时，它们能帮你快速定位是采集环节挂了，还是清洗环节出了问题，还是存储被流量打爆了。我在实际项目中就靠这些日志定位过很多次问题，有一次就是靠“去重率突然升高”这个指标反推出目标网站调整了反爬策略，而且这个判断非常快，不需要去翻大量日志。

5.4 给阶段五之后的进阶方向

走完数据存储与清洗这一阶段，你的爬虫工程师学习路径就有了一个相对完整的基础盘。接下来可以往几个方向继续深入，每个方向都有各自的侧重：

一是数据仓库方向：学更复杂的ETL流程、数据建模、OLAP查询，把多来源的爬虫数据统一成一套可供BI分析的结构。二是数据分析方向：在清洗好的数据之上做统计分析、可视化、洞察发现，让爬虫数据变成可读的报表。三是平台化方向：结合调度系统做全自动的采集-存储-清洗-分析链路，做一个内部的数据采集平台。

不管选哪个方向，阶段五打下的存储与清洗功底都是地基。也可以说，真正的爬虫工程师和“只会写爬虫脚本的人”，分水岭就在这个阶段。前者能交付稳定可靠的数据，后者只能交付一堆跑完就扔的数据文件。

我个人在实际操作中的体会是：学到这里，你回头再看之前那些单机爬虫代码，会发现很多地方都值得重构——字段该用Item规范却用字典乱传、入库该走Pipeline却在spider里直接连数据库、清洗逻辑和解析逻辑混在一起没法维护。这些问题的解法，其实第五阶段全都涉及了。把这一步走扎实，后面不管往哪个方向发展，都会顺很多。