scrapy-redis分布式爬虫实战：从单机到多节点部署与避坑指南

简介：这是一套面向Python爬虫开发者的Scrapy-Redis分布式爬虫案例包，适合已掌握Scrapy基础、希望系统学习分布式抓取的初中级读者，用于解决跨机器任务调度、请求队列共享、结果集中存储与反爬应对等核心问题。压缩包共15个文件，以8个py源码文件为主，辅以6个pyc编译文件和scrapy.cfg工程配置，覆盖爬虫入口脚本、settings配置、中间件、管道、items数据模型及spiders目录，pyc文件可辅助验证运行结果，cfg则定义项目基础参数，结构清晰紧凑，可直接对照运行与修改。已有1449人学习浏览。案例从环境版本对齐、Redis启动与队列设定讲起，完整演示如何将Scrapy改造为分布式任务模式，把请求调度从本地内存移到Redis，并通过不同启动参数让各节点消费同一URL队列；同时明确中间件启用、REDIS_URL等关键配置项，给出MySQL结果存储Pipeline的实现思路，针对IP封禁、重复抓取、节点同步等实战难点，提出代理IP池、去重机制、分布式锁等应对方案。整体来看，这是一份能帮助快速理解分布式爬虫原理、搭建可运行原型的实用参考，便于按需裁剪和二次开发。

1. 单机爬虫的瓶颈：我为什么会转向scrapy-redis这套方案

先说一个我自己踩过的坑。去年接了一个公开数据采集的需求，数据量大概在百万级，目标网站的页面结构不复杂，但翻页特别深。我一开始用单机Scrapy写了个爬虫，跑在本地一台服务器上，前三天一切正常，日志干干净净，下载速度稳定在每秒几十个页面。结果第四天早上起来一看，任务挂了，而且不是被封IP那种挂——是我手动重启服务器之后，整个队列全部丢了。

Scrapy默认的调度器是跑在内存里的，去重集合也是内存里的，任务一停，所有状态归零。我当时的爬虫没有加断点续跑，于是只能从头再来。那种"明明已经爬了60%却要全部重来"的感觉，我相信做过爬虫的人都懂。

后来我花了几天时间把项目改造成scrapy-redis，也就是用Redis来统一管理调度队列和去重集合，把单个Scrapy实例变成可以横向扩展的分布式爬虫。改造完之后，我可以在任意多台机器上同时启动爬虫进程，它们消费同一个Redis队列，互不重复地抓取任务，任何一台机器挂了，其他节点会接着把任务跑完，重启之后也不需要重新爬一遍。

这篇文章就把完整的实现过程拆开讲讲，包括scrapy-redis的调度原理、代码改造步骤、多节点部署方案，以及我实测过程中遇到的各种问题和对应的排查思路。如果你正在做的项目满足两个条件——任务量大到单机跑不完，或者你对任务的稳定性有要求，那这套方案大概率能帮到你。

1.1 先认清：分布式不是"多开几个进程"这么简单

很多人一听说分布式，第一反应是"那我多开几个Scrapy进程不就行了"。这个想法我一开始也有，实际操作之后才发现根本不成立。

你在一台机器上开三个scrapy crawl进程，它们只是各自独立地在跑，每个进程都有自己的队列和去重集合，任务并不会自动分到三个进程上，反而是同一个URL可能被三个进程各爬一遍。你真正需要的是一个共享的任务队列和一套全集群统一的去重机制，让每个请求只被消费一次，不重复也不遗漏。

Redis在这里扮演的就是"中央调度器"的角色。scrapy-redis这个库做的事情非常清晰：把Scrapy默认的Scheduler（调度器）和DupeFilter（去重过滤器）替换成基于Redis的实现。这样所有爬虫节点——不管它们在哪台机器上——看到的都是同一个队列、同一个去重集合，配合自然就产生了。

1.2 scrapy-redis帮我解决的核心问题

把问题拆开来看，scrapy-redis主要干了四件事：

• 统一调度：所有待爬取的Request不再存在本地内存，而是push到Redis的List结构中，任何节点都能从这个List里pop任务。
• 统一去重：Request指纹存放在Redis的Set结构中，所有节点共享同一份去重数据，不会重复抓取。
• 状态持久化：队列和解重数据都落在Redis里，爬虫进程挂了、服务器重启了，任务状态还在，重启后能继续消费。
• 数据汇总：爬取结果可以通过Item Pipeline写入Redis，也可以直接把item交给数据库层统一落库，相当于给多节点找了一个共同的数据出口。

这套组合拳打下来，单机爬虫的三大痛点——不可横向扩展、任务易丢失、去重不共享——全部解决了。当然它也有自己的局限性，后文我会单独讲它不适合什么样的场景。

2. 分布式调度的执行原理：先弄懂两个Redis数据结构

在用scrapy-redis之前，我建议你先花二十分钟把它的源码翻一下。这个库整体代码量不大，核心就几个文件，核心逻辑比我预想的简单得多。我把它拆成两个部分来理解：队列和去重。

2.1 调度队列：为什么是Redis的List而不是消息队列

scrapy-redis默认的调度队列是基于Redis的List实现的。爬虫请求从左边push进去，节点从右边pop出来，一个标准的FIFO队列，对应Redis的lpush和rpop两个操作，时间复杂度都是O(1)。

有人会问：既然要处理大量异步任务，为什么不用Kafka或者RabbitMQ这种成熟的消息队列？我的理解是，爬虫任务的调度和通用消息队列的诉求不太一样。爬虫更看重的是去重、优先级控制、断点续爬这些能力，而不是吞吐量和广播模式。而且单独为了爬虫去维护一套Kafka集群，运维成本直接拉高一个量级。Redis部署简单、天然支持持久化、操作命令直观，对爬虫这种"任务重、消息量中等、要求去重精准"的场景来说，是性价比最高的选择。

2.2 去重集合：基于Redis Set的指纹去重机制

Scrapy内置的去重逻辑是把每一个Request对象生成一个指纹，然后丢到一个集合里，新来的Request指纹如果在集合里已经存在，就直接丢弃。这个指纹由scrapy.utils.request.request_fingerprint函数生成，对Request的url、method、body、headers等信息做一次SHA1加密，得到一个40位的十六进制字符串。

单机版本里这个集合存在内存中，scrapy-redis把它搬到了Redis的Set结构里。每次请求到达调度器的第一步，是先检查指纹是否存在于Set中，如果存在就跳过，不存在就加入Set并进入队列。

这里有一个设计上的细节值得注意：入队的时机是在指纹检查之后。也就是说，去重发生在请求进入队列之前，而不是消费时候才检测。这样保证同一个URL即使被多个节点同时推送，也只有一个能进队列，后面的都会被Set拦截。多节点环境下，"同时推送同一个URL"这种情况很常见，靠这个机制天然规避了重复抓取。

2.3 多节点之间靠什么保持"共同认知"

分布式系统里最怕的就是各个节点各干各的，相互不知道对方做了什么。scrapy-redis解决这个问题的方式很朴素——所有关键状态都只存在Redis里，节点本身不保留状态。

举个例子，当两个节点同时执行scrapy crawl myspider，它们的Spider名字一样，从Scrapy的角度看是两个完全独立的爬虫实例。但它们都连同一个Redis，用的是同一个队列key（默认是spidername:requests）和同一个去重集合key（默认是spidername:dupefilter），所以在调度的视角里，它们就是同一个任务的两个worker，只是分别从队列两侧取活干而已。

理解了这个机制，"分布式"三个字在你心里就不会那么神秘了——本质上就是多个无状态进程共享一组有状态的外部存储。

3. 动手改造：从单机Scrapy到分布式可扩展的完整过程

理论部分差不多了，下面进入实操环节。我用一个具体的改造过程来说明，假设你现在有一个单机版的Scrapy爬虫，要把它改成scrapy-redis分布式版本。

3.1 环境准备与依赖安装

前提是你已经装好了Scrapy并且爬虫能在单机跑通。在此基础上只需要额外安装一个库：

pip install scrapy-redis

装完之后检查一下版本。scrapy-redis停更比较早，现在常用的版本是0.7.2，它和较新版本的Scrapy之间偶尔会有兼容性小问题，我用的是Scrapy 2.5.1配scrapy-redis 0.7.2，没有遇到问题，但你如果用的是Scrapy 2.8以上，建议先装完跑一个最小demo验证一下再动正式代码。

同时确保你的机器能连上Redis，本地开发就先不用密码，生产环境务必设置密码和限制IP访问。

3.2 settings.py里的配置项，逐个说清楚

改造的核心配置都在settings.py里，我贴一份完整配置然后逐项解释：

# 调度器改为scrapy-redis的实现 SCHEDULER = "scrapy_redis.scheduler.Scheduler" # 使用scrapy-redis的去重组件 DUPEFILTER_CLASS = "scrapy_redis.dupefilter.RFPDupeFilter" # 是否在爬虫结束时保留Redis中的调度队列和去重指纹 SCHEDULER_PERSIST = True # 队列类型，FifoQueue即先进先出的普通队列 SCHEDULER_QUEUE_CLASS = "scrapy_redis.queue.FifoQueue" # Redis连接配置 REDIS_URL = "redis://:yourpassword@127.0.0.1:6379/0"

SCHEDULER这一行是最关键的，它告诉Scrapy不要用默认的调度器，改用scrapy-redis提供的调度器。DUPEFILTER_CLASS同理，把默认的内存去重换成了Redis版本的RFPDupeFilter。

SCHEDULER_PERSIST设置为True的意义在于：爬虫结束之后，Redis队列和去重集合不自动清空。如果设置成False，爬虫关闭时调度器会把队列和去重数据都flush掉，断点续跑就会失效，所以这个选项要想清楚再改。

SCHEDULER_QUEUE_CLASS可以选三种队列类型：

一般先用FifoQueue，后面要优化了再考虑PriorityQueue。

3.3 Spider代码的改造套路

Spider方面的改动很小，但有一个关键点。原来的写法是：

import scrapy class MySpider(scrapy.Spider): name = "myspider" start_urls = ["http://example.com/page/1"]

改成scrapy-redis的写法：

from scrapy_redis.spiders import RedisSpider class MySpider(RedisSpider): name = "myspider" redis_key = "myspider:start_urls" def parse(self, response): # 这里的内容保持不变 pass

继承的类从scrapy.Spider换成了RedisSpider，start_urls不用写了，改成了一个redis_key字符串。

这个改动意味着什么？请求的入口从"代码里写死的URL列表"变成了"Redis里的一个队列"。你需要单独往Redis里推送初始URL，方式很简单：

redis-cli lpush myspider:start_urls "http://example.com/page/1" redis-cli lpush myspider:start_urls "http://example.com/page/2"

一旦RedisSpider启动后检测到myspider:start_urls队列里有URL，就会马上消费这些URL，之后在parse方法里yield scrapy.Request()出来的新请求，就会自动进入调度队列等待分配。

这里我遇到过一个有意思的坑：如果你什么URL都不往Redis里推，爬虫进程启动后会一直处于等待状态，日志停在"Spider opened"那一行，看起来像卡住了。不要慌，这只是它在等任务——往Redis里push URL进去它就会开始跑。

3.4 初始化URL的三种写入方式对比

start_urls的写入方式直接影响你整个流程的效率。我试过三种方法，对比一下：

• 手动用redis-cli敲命令：适合调试阶段，快速验证爬虫能不能跑通，缺点是URL多的时候不现实。
• 写一个独立的Python脚本：从数据库或者文件里读出URL列表，批量lpush到Redis。这是我最常用的方式，适合启动任务前一次性灌入大量入口URL。
• 爬虫内部自触发：在parse里定期往redis_key所在的队列push新的URL，实现类似"持续发现新入口"的效果。适合那种入口列表本身会不断增长的场景，比如根据数据库里的新记录去抓取。

实际项目里我通常是第二种和第三种混用：启动前批量灌入一批初始URL，运行过程中根据解析结果动态补充。

4. 多节点部署的正确姿势：Master-Worker架构怎么搭

分布式爬虫的部署方式和前面代码改造同样重要。如果你把所有爬虫节点都跑在同一台机器上，那Redis也在这台机器上，一旦宕机，所有节点都失去调度中心，照样全部停摆。所以部署架构要清晰。

4.1 部署架构与节点分工

我的推荐做法是经典的Master-Worker架构：

• Master节点：只跑Redis服务，不跑爬虫进程。它的职责是接收所有节点写入的Request、存储去重指纹、输出爬取结果。
• Worker节点：可以是一台机器，也可以是几十台。每台上只安装Scrapy环境，运行相同的爬虫代码，启动scrapy crawl myspider。

Worker节点之间完全平级，没有主从之分，任何一个节点宕机都不影响整体任务，剩下的节点会继续从Redis队列里消费任务。等宕机的节点恢复之后，重新启动爬虫进程，它会继续从断点接着干，不会重复爬取。

如果只有一台服务器，也可以在这台机器上同时跑Redis和多进程爬虫，但要做好内存规划。Redis本身占用内存不大，主要是爬虫进程和请求缓存占资源。

4.2 Worker节点的并发参数控制

分布式环境下并发参数的设置有讲究。每个Worker节点上的CONCURRENT_REQUESTS不能设置得太高，否则所有节点叠加在一起，对目标网站的压力会成倍放大，导致被封IP。

以我的经验，单节点建议初始设置为16到32之间，根据目标网站的响应速度和自身机器性能逐步调。另外DOWNLOAD_DELAY一定要设置，哪怕只有0.5秒，能显著降低被封风险。多节点环境下更要注意这一点，因为很多反爬策略是按IP维度统计请求频率的，你10个节点如果每个都1秒并发几十个请求，同一个IP每秒几百个请求过去，不封你封谁。

如果目标网站要求高并发，可以考虑让不同Worker节点走不同的代理出口IP，或者用代理池轮换。

4.3 数据落库的收敛策略

分布式环境下，多个节点同时跑，每个节点都会单独执行自己的Item Pipeline。如果Pipeline是直接写MySQL或者写文件的，每个节点都会打开自己的数据库连接、写自己的文件，数据就是分散的。

我之前遇到的一个问题是：10个节点同时写同一个MySQL表，连接数暴增，数据库负载飙高。改进的方式是让所有节点把Item写到Redis里一个单独的队列，然后由一个独立的落库进程负责消费这个队列，统一写入数据库。

scrapy-redis本身就提供了一个RedisPipeline，作用就是把Item序列化后扔进Redis队列。你要做的就是在ITEM_PIPELINES里加上它：

ITEM_PIPELINES = { "scrapy_redis.pipelines.RedisPipeline": 300, }

然后自己写一个消费者脚本，从Redis里取出Item，批量写入数据库。这样既减少了数据库连接压力，又可以做批量插入优化，整体吞吐量反而更高。

5. 实测中的几个深坑与完整排查链路

scrapy-redis整个框架本身不复杂，但把它放到生产环境跑起来，各种问题就冒出来了。下面这几个坑是我真实踩过的，每个都附上我的排查过程，希望能帮你节省排查时间。

5.1 爬虫节点"假死"：日志停滞但Redis队列还有大量任务

现象：某个Worker节点运行了几个小时后，日志停止输出新请求，既不报错也不崩溃，Redis队列的剩余长度却在持续下降——说明其他节点在正常消费，只有这一个节点在摸鱼。

排查过程：我先看这个节点的CPU和内存，发现CPU很低，内存正常，排除资源耗尽。然后看Redis连接数，发现这个节点占用的连接比预期多很多。接着查看scrapy-redis的日志，发现它一直在重试同一个请求。

最后定位到原因：这个节点上有一个请求因为目标网站返回了超时，Scrapy会根据RETRY_TIMES设置重试，而重试操作需要把Request重新放回调度队列。问题出在重试频率太高，节点的大部分时间都花在处理重试上，新请求的消费反而被阻塞了。

解决方案：把RETRY_TIMES从默认的2次降为1次，同时设置RETRY_HTTP_CODECS只针对特定状态码重试，避免所有超时都进入重试循环。另外把DOWNLOAD_TIMEOUT从默认的180秒降到了30秒，无效请求快速失败，不再长时间占用线程。

5.2 Redis内存暴涨：去重集合撑爆了内存

现象：爬虫跑了两天后，检查Redis内存使用量，发现已经占用了好几个GB，而且还在持续增长。用redis-cli info memory查看，used_memory高得吓人。

排查过程：先查看key的分布情况，redis-cli --bigkeys扫了一遍，发现最大的key就是去重集合，里面有上亿个指纹。每个SHA1指纹是40字节，加上Redis Set的存储开销，上亿条数据占几个GB完全不奇怪。

解决方案：如果你的URL量级预估在千万以下，直接用Set去重没问题。但如果超过亿级，就要考虑用Bloom Filter替换精确去重。Bloom Filter用很小的内存代价换取了极低概率的误判，能在一个亿级URL场景下把内存占用降到几百MB。scrapy-redis生态里有现成的scrapy-redis-bloomfilter项目，改一个配置就能切换。

还有一个优化手段是定期清理过期指纹。如果你的爬虫是周期性抓取，每次任务结束后把旧的去重集合重命名，保留最近几次的指纹做增量去重，能有效控制集合增长。

5.3 任务消费完毕但数据对不上：Redis队列已空，数据库却少了记录

现象：爬虫跑完后，检查Redis队列，llen已经是0，所有请求都被消费了。但核对数据库里的记录数，发现比预期少了10%左右。

排查过程：最开始怀疑是解析逻辑漏了，抓了部分页面重新分析，发现页面内容正常，解析代码也没有疏漏。接着怀疑是Item Pipeline丢弃了数据，查看日志发现确实有若干条警告，提示某些Item写入失败。

进一步查原因，发现失败的Item都卡在同一个字段上：网络波动导致某些请求返回了空页面或错误页面，这部分页面被Parser正常解析但字段缺失，Pipeline在写入数据库时因为非空约束直接把整条数据丢弃了。

解决方案：这种"静默丢弃"比报错更可怕，因为你不看日志完全发现不了。我的做法是在Pipeline里加了一层校验和告警：解析结果为空或者关键字段缺失时，不仅不丢弃，还把原始页面快照和请求信息写入一个专门的异常表。后续可以针对这些异常URL重新发起抓取，形成一条"补爬"链路。

5.4 节点重启后重复爬取：断点续爬失效了

现象：一个节点挂了，重启之后我发现它又重新爬了一部分之前已经爬过的URL，去重好像没生效。

排查过程：先检查SCHEDULER_PERSIST配置，确认是True。然后看Redis里的去重集合，发现集合确实还在。最后看了下重启时的启动日志，发现报了一个警告：Duplicate request的过滤日志消失了，某些Request没经过去重直接放进了队列。

最终原因很微妙：节点重启后，爬虫内部有些Request是在parse过程中临时生成的，这些Request的指纹在生成时依赖了当时的内存状态。如果爬虫代码里用了不稳定的数据（比如时间戳、随机数）拼接URL参数，同一个逻辑URL每次生成的指纹都会不一样，去重自然失效。

解决方案：检查所有scrapy.Request的构造参数，确保URL中的参数顺序固定，不能使用每次运行都会变化的动态值。对于确实需要动态参数的请求，考虑重写request_fingerprint函数，只针对URL的核心部分计算指纹。

5.5 Redis连接池撑爆：爬虫数量一多就报连接错误

现象：把Worker节点从3个扩展到10个之后，Redis频繁报连接错误，日志显示ConnectionError: Error while reading from socket。

排查过程：先看Redis的maxclients配置，默认是10000，按理说10个节点不会超过。再看Redis的CPU，发现已经接近100%，单实例Redis处理不过来了。

解决方案：第一步，调大Redis的timeout和tcp-keepalive配置，让空闲连接尽快释放。第二步，给每台Worker节点设置合理的REDIS_CONNECTION_POOL_SIZE（scrapy-redis用的是Redis-py的默认连接池），不要在每毫秒级操作里都新建连接。第三步，如果节点数超过20个，单Redis实例确实是瓶颈，需要考虑改用Redis Cluster或者给不同爬虫任务分开Redis实例。

6. 进一步的进阶玩法：增量爬取、优先级调度与大规模去重优化

基础的分布式爬虫跑通之后，你会发现这套框架还有很大的延伸空间。这几个方向是我在实际项目中陆续摸索出来的，可以帮你把scrapy-redis用得更顺手。

6.1 基于Redis的增量爬取方案

周期性任务（比如每天早上抓一次竞品价格）如果用朴素的方式跑，每次都会从start_urls重新开始，之前抓过的页面会全部重新抓一遍。虽然去重能保证不重复入库，但浪费了大量的请求和带宽。

和去重指纹配合的增量思路是：每次任务结束后，把这次请求过的URL指纹临时保存到另一个集合（比如myspider:seen_today），下次任务启动时，在middleware里检查当前请求的指纹是否在这个临时集合里，如果在就直接跳过。这样周期性任务只抓新增或变化的页面，大幅度缩短耗时。

对于入口URL本身就动态增长的站点，更推荐在启动时只push新增的URL进redis_key，然后配合SPIDER_MIDDLEWARES做增量逻辑判断，避免把整个历史URL列表重新灌进去。

6.2 用PriorityQueue实现任务优先级调度

默认的FifoQueue对所有请求一视同仁，但实际业务中往往有优先级差异。比如你现在既要抓商详页，又要抓列表页，商详页的新鲜度直接影响用户体验，那应该让商详页请求插队。

scrapy-redis提供了基于Redis ZSet的PriorityQueue，使用方式很简单：

SCHEDULER_QUEUE_CLASS = "scrapy_redis.queue.PriorityQueue"

然后在生成Request时用priority参数控制优先级：

yield scrapy.Request(url, callback=self.parse_detail, priority=10)

priority值越大，出队越早。我一般约定：默认请求priority=0，重要页面priority=10，低优先级数据补量请求priority=-5。

使用PriorityQueue后有个明显变化：Redis里存储的不再是简单的List，而是一个ZSet，分数就是priority值。这样你可以直接在redis-cli里查看当前队列里各个优先级的任务分布，方便观察任务进度。

6.3 大规模场景下的去重优化：Bloom Filter实战

前面提过Bloom Filter应对亿级URL去重的方案，这里展开说说具体怎么做。传统Set精确去重在URL数量超过一亿之后，内存占用轻松超过10GB，很多服务器根本扛不住。

Bloom Filter的核心原理是：把每个URL通过多个哈希函数映射到bit数组的多个位置，把这些位置置为1。判断某个URL是否存在时，看它映射的t个位置是否都为1，只要有一个为0就确定不存在。它的代价是存在一定的误判率——可能把没访问过的URL误判为已访问，造成少量漏爬，但换来的内存节省非常可观。

有一个开源项目scrapy-redis-bloomfilter，用法和scrapy-redis几乎一样，只需要改一行配置：

DUPEFILTER_CLASS = "scrapy_redis_bloomfilter.dupefilter.RFPDupeFilter"

配置完再设置一个误判率参数即可。我实测在千万级URL的场景下，Bloom Filter版本的内存占用是精确去重版本的十分之一左右，漏爬率控制在千分之一以内，对于大多数爬虫场景完全可接受。

6.4 其他值得尝试的优化方向

除了上面几个方向，还有一些小技巧性价比很高：

• 请求指纹自定义：如果你的URL参数顺序不固定（比如?a=1&b=2和?b=2&a=1是同一个页面），默认的指纹会把它们当成两个不同请求。重写request_fingerprint方法，把URL参数排序后再生成指纹，可以让去重更精准。
• 动态配置Redis地址：区分开发和生产环境的Redis实例，用一个环境变量控制REDIS_URL，避免本地调试时误连生产Redis把任务队列搞乱。
• 监控和告警：写一个简单的巡检脚本，定时检查Redis队列长度、去重集合大小、各Worker节点的在线状态和各自的消费速率，异常时发告警通知。分布式环境下的排障效率，很大程度上取决于你对线上状态的可见性。

最后说几句实在话

scrapy-redis这套方案我从第一次接触到现在用了很久，最大的感受是它把"分布式"这个词从概念层面落到了工程层面，没有引入太多复杂概念，一个Redis就搞定了调度、去重、持久化三件大事。

但我也要说清楚它的适用边界。如果你的任务量级只有几万条URL，一台机器跑单机Scrapy完全够用，引入Redis反而多了一个维护点，没必要为了"分布式"而分布式。如果你要抓取的是实时性要求极高、需要毫秒级调度的场景，scrapy-redis这种基于队列的批量消费模型可能不是最佳选择，更应该去看看真正的任务调度系统。

我个人的经验是：判断一个项目要不要用scrapy-redis，就看两点——第一，任务量是否大到单机跑不完；第二，你的业务是否能容忍"少量任务可能被延迟处理，但不会丢失"。这两个条件都满足，那scrapy-redis就是非常靠谱的选择。如果你的情况介于边界之间，我建议你从最小配置开始跑，先把单节点调通、队列落好，再逐步加节点，不要一上来就铺开10台机器，那样一旦出了问题，排查成本比省下的时间还高。

本文还有配套的精品资源，点击获取