Scrapy爬取大众点评：破解字体反爬与动态数据的实战指南

简介基于Scrapy框架的大众点评爬虫源码适合有一定Python基础、希望学习Scrapy架构及反爬实战的爬虫开发人员。项目通过浏览器手动登录与验证规避了验证码识别难点同时内置代理设置与字体反爬处理可有效应对大众点评常见的反爬策略。爬取内容覆盖城市列表、分类列表与店铺详情包含名称、地址、评分、评价数、人均消费等字段字段结构清晰。资源共19个文件以13个Python源码为核心辅以requirements依赖清单、Scrapy配置与说明文档压缩包仅21KB轻量紧凑便于阅读与移植。代码目录按Scrapy标准结构组织包含items、pipelines、middlewares、spiders等模块并明确了“先城市分类、再店铺链接、后店铺信息”的爬取顺序数据自动落盘至data目录。截至目前已有596人学习适合用于研究Scrapy框架、代理池接入、字体反爬对抗等实战场景。1. 基于 Scrapy 框架的大众点评爬虫先拆透反爬再谈采集做爬虫的人早晚会接到一个需求把大众点评的店铺数据抓下来。别急着写代码这个站点的反爬强度在业内是出了名的——字体反爬、CSS 定位、滑块验证、IP 封禁层层叠加很多人第一版代码跑不到 200 条数据就被封了 IP。本文要讲的就是怎么用 Scrapy 框架把大众点评的店铺名称、地址、评分、人均消费、评论数这些核心字段稳定地抓下来。这套方案适合三类人想系统性学习 Scrapy 反爬技巧的中级开发者需要给本地生活项目积累样本数据的分析师以及被老板临时派活、需要快速评估可行性的一线工程师。文章会从反爬机制拆解、Scrapy 工程搭建、中间件设计、数据存储到最终的避坑排查全程按可复现的步骤走。2. Scrapy 与大众点评的反爬博弈先知道对手怎么出牌2.1 大众点评的字体反爬是怎么让数据变脸的大众点评最经典的反爬手段是字体反爬。你在浏览器里看到的店铺评分是「4.8」但爬虫直接拿到的 HTML 文本里可能是「x82」或者一串乱码。原理是站点自定义了一套字体文件把标准数字 0-9 映射到自定义的 Unicode 码位浏览器加载字体后显示正常而 requests 或 Scrapy 默认拿到的文本就是映射前的乱码。具体判断方法很直观用 Scrapy shell 抓一个店铺页面如果评分字段在响应体里是空白、乱码或者加密字符基本可以断定命中了字体反爬。解决思路分两步scrapy shell https://www.dianping.com/shop/xxx response.xpath(//span[classreview-score]/text()).get() \ue286 # 典型字体加密字符第一步是从响应里提取字体文件 URL比如//s3plus.meituan.net/v1/mss_0e1dxxx/...woff第二步是下载字体文件用fontTools解析出字符映射表再把乱码还原成真实数字。这里的关键是解析字体映射不能写死因为大众点评会定期更换字体文件写死映射表就是给自己埋定时炸弹。2.2 动态 iframe 与异步加载为什么 HTML 里看不到数据现在的大众点评页面大量使用动态 iframe 和异步请求。你打开一个店铺详情页直接查看网页源码看不到评论内容、看不到推荐菜这些数据是页面加载后由 JavaScript 发起 XHR 请求再渲染进去的。用 Scrapy 默认的scrapy.Request只能拿到静态 HTML取不到动态内容。这里有两个方案一是用 Scrapy 配合 Splash 渲染 JS二是抓取异步接口本身。我的经验是优先抓接口因为接口返回的是干净的 JSON 数据处理效率高而且大众点评的接口路径往往比页面 DOM 结构更稳定。scrapy shell https://www.dianping.com/shop/xxx response.xpath(//iframe/src).get() //m.dianping.com/xxx/modal遇到 iframe 嵌套时Scrapy 的response.follow可以继续跟进 iframe 的 src 地址但要注意 iframe 页面内部往往还有二次异步请求。排查技巧是先开浏览器开发者工具Network 面板里筛 XHR 请求看数据到底是从哪个 URL 返回的再把那个 URL 作为 Scrapy 的请求对象。2.3 常见反爬机制的触发条件与应对优先级大众点评的反爬是分层的不同层级触发条件完全不同。最外层是 IP 限流单位时间内请求次数超过阈值就返回验证码页面中间层是 UA 和 Cookie 检测非浏览器 UA 直接被拒最内层才是字体加密和参数签名。应对优先级应该反过来先解决参数签名再处理字体反爬最后才是 IP 池。原因很简单如果请求发不出去后面一切白搭。我自己常用的中间件组合是自定义 UA 轮换 Cookie 自动携带 IP 代理池 请求限速。这四件套能解决 90% 的常规问题剩下 10% 是大众点评更新反爬策略后的临场博弈。3. 搭建 Scrapy 工程并跑通首个店铺列表页3.1 从零创建 Scrapy 项目目录结构与基础配置创建工程之前先确认环境我用的 Python 3.9 和 Scrapy 2.x如果你还在用 Python 2 时代的老 Scrapy建议先升级否则后面很多中间件写法不兼容。python -m venv dianping-scrapy source dianping-scrapy/bin/activate pip install scrapy scrapy startproject dianping cd dianping scrapy genspider shop www.dianping.com生成的目录结构里spiders/shop.py是核心爬虫文件settings.py里要改几个关键配置。我一般先把ROBOTSTXT_OBEY设为 False因为大众点评的 robots 协议明确禁止爬虫但做数据采集时通常会绕过DOWNLOAD_DELAY设为 2-3 秒这是最低限度的礼貌DEFAULT_REQUEST_HEADERS里把 UA 换成完整的浏览器 UA。# settings.py 核心配置 ROBOTSTXT_OBEY False DOWNLOAD_DELAY 2.5 DEFAULT_REQUEST_HEADERS { User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36, Referer: https://www.dianping.com/, Accept-Language: zh-CN,zh;q0.9, }注意DOWNLOAD_DELAY只能限速单请求的间隔如果开了并发Scrapy 会乘以并发数。想要更精确的限速可以配合AUTOTHROTTLE_ENABLED True让 Scrapy 根据服务器响应时间动态调整请求频率这个后面细说。3.2 编写列表页爬虫从搜索页提取店铺 ID跑通列表页是整个项目的敲门砖。大众点评的列表页 URL 格式大约是https://www.dianping.com/shanghai/ch10/g110这种其中g110是店铺分类编号ch10是行政区编号。爬虫的任务就是遍历这些分类和区域的组合提取每张卡片里的店铺详情页链接。import scrapy class ShopSpider(scrapy.Spider): name shop start_urls [https://www.dianping.com/shanghai/ch10/g110] def parse(self, response): # 店铺卡片链接形如 /shop/12345678 for link in response.css(a[href*/shop/]::attr(href)).getall(): yield scrapy.Request( urlresponse.urljoin(link), callbackself.parse_detail, meta{source_url: response.url}, dont_filterTrue ) # 翻页大众点评列表页翻页参数是 ?p2 next_page response.css(a.next::attr(href)).get() if next_page: yield response.follow(next_page, callbackself.parse)这里有两个坑必须提醒。第一是dont_filterTrue店铺详情页 URL 可能在不同列表页重复出现默认去重会把后续请求过滤掉导致数据缺失第二是翻页参数大众点评的前几页是静态渲染但页码变大后可能变成动态加载所以翻页逻辑要写好条件判断页面没有a.next就说明翻到头了。3.3 用 Scrapy Shell 调试字段提取规则字段提取是爬虫最容易写歪的地方特别是大众点评这种 DOM 结构复杂、class 命名还会变的站点。我的习惯是先抓一个真实响应存成本地 HTML再用 Scrapy Shell 反复调试 XPath 或 CSS 选择器确认无误后再写进爬虫代码。scrapy shell https://www.dianping.com/shop/example response.css(h1.shop-name::text).get() response.xpath(//div[contains(class, shop-info)]//text()).getall()调试时重点关注店铺名称、评分、人均价格、地址、评论数这几项。每个字段都要写多个候选选择器因为大众点评改版的频率不低第一套选择器失效时备用选择器能让你少改几次代码。我见过有人硬编码 class 名站点一改版全盘崩掉这就是没有做选择器冗余的教训。4. 破解字体反爬与动态数据让数字回到真实值4.1 下载并解析 woff 字体文件字体反爬是大众点评最让人头疼的一层但拆解的套路是固定不变的。当 HTML 里出现乱码字符时先拿到font-face声明里的字体文件 URL用requests下载到本地再用fontTools解析字体的 cmap 表建立乱码字符到真实数字的映射。from fontTools.ttLib import TTFont def parse_font(font_path): font TTFont(font_path) cmap font.getBestCmap() mapping {} for code, glyph_name in cmap.items(): # 大众点评字体里 glyph 名通常形如 uniE286 if glyph_name.startswith(uni): # 关键字体文件里的坐标要与基准字体对比才能还原数字 pass return mapping这里有个容易遗漏的细节光靠字体文件本身还原不了数字必须拿加密字体和一份基准字体做坐标对比。大众点评的加密字体把数字的轮廓做了平移和变形每个字符的实际轮廓坐标和标准数字的轮廓坐标存在对应关系。所以更稳妥的做法是下载加密字体和一个已知的标准数字字体用字符的轮廓坐标做最近邻匹配才能得到正确的映射关系。4.2 字体缓存策略别每次都下载解析字体文件如果每次都下载再解析效率太低而且高频访问字体 URL 容易被重点关注。常见做法是把解析好的映射表缓存到 Redis 或本地 JSON 文件里键是字体文件的 MD5 值。import hashlib import json def get_font_mapping(font_content): font_hash hashlib.md5(font_content).hexdigest() cached cache.get(font_hash) if cached: return json.loads(cached) # 解析逻辑省略 cache.set(font_hash, json.dumps(mapping), ex86400)缓存过期时间我一般设 24 小时因为大众点评不是每天都换字体但也不排除大促期间临时更换。如果你的爬虫要求数据实时性高可以把过期时间缩短到 6 小时。另外一个细节是字体文件存储路径用hash md5(url)做文件名最方便既避免重复下载又能追溯来源。4.3 动态接口抓取从 XHR 响应里拿干净数据绕过动态渲染的方案是直接抓 XHR 接口。大众点评的评论接口、推荐菜接口都有固定的 URL 模式关键是分析参数签名。我见过最简单的接口只需要shopId和page两个参数但也见过带sign和token的这类参数通常是用 JavaScript 加密生成的逆向成本较高。def parse_comments(self, response): # 假设接口返回 JSON data json.loads(response.text) for item in data.get(commentList, []): yield { user: item.get(userName), rating: item.get(star), content: item.get(text), time: item.get(createTime), }没有 JS 逆向基础的人我建议先别碰签名参数。更实际的方案是列表页能拿到的字段先用列表页的数据评论内容可以用 Splash 渲染 iframe 页面来取虽然慢一点但胜在稳定。等业务量证明这个方向值得投入再去做接口逆向性价比会更高。5. 中间件与数据管道反爬配置和存储落地5.1 自定义 UA 轮换与 Cookie 中间件UA 轮换是反爬的基础配置但很多人做得太粗糙把浏览器 UA 列表随机切换就行。实际上大众点评对 UA 的检测不只是看 UA 字符串还看 UA 与浏览器特征指纹的匹配度。比如 Common Crawl 的 UA 是机器人标识就算换个浏览器版本号也一眼看穿。class RandomUserAgentMiddleware: def process_request(self, request, spider): ua random.choice(UA_LIST) request.headers[User-Agent] ua return NoneUA 列表可以从主流浏览器的真实访问记录里收集比如 Chrome 最新版、Edge、Safari 的 UA 字符串每种浏览器保持 3-5 个版本号。这里有个玄学经验UA 轮换和请求频率要联动如果你每 10 秒钟换一个全新 UA但请求频率是每秒 10 次一样会被识别为异常行为。Cookie 中间件的作用是把登录后的 Cookie 保存下来在每次请求时自动携带。大众点评的某些字段需要登录才能看到完整数据不登录只能拿到部分信息。实现方式有两种手动从浏览器复制 Cookie 到配置里或者用 Scrapy 的 cookie jar 自动保存 Set-Cookie。class CookieMiddleware: def process_request(self, request, spider): if spider.cookie: request.cookies spider.cookie return None手动复制 Cookie 的方式适合短期采集Cookie 失效后需要重新复制自动保存 Cookie 更适合长期运行但第一次请求之前需要在浏览器里完成登录流程。我一般会在爬虫启动时读取一个本地 Cookie 文件启动后自动加载。5.2 IP 代理池的接入方式与可用性检测IP 被封是整个爬虫项目最大的翻车点。大众点评的封禁策略是阶梯式的先返回验证码再临时封 IP最后直接拒绝访问。所以 IP 代理池的质量直接决定爬虫能跑多久。常见做法是维护一个代理池定时检测代理的可用性并把不可用的剔除。class ProxyMiddleware: def process_request(self, request, spider): proxy spider.proxy_manager.get_proxy() request.meta[proxy] fhttp://{proxy[ip]}:{proxy[port]} return None def process_response(self, request, response, spider): # 429 或验证码页面标记为坏代理 if response.status 429 or captcha in response.url: spider.proxy_manager.remove_proxy(request.meta[proxy]) return response代理质量检测是容易偷懒但必须做扎实的事。检测标准不只是代理能否连通还要看目标站点的可用性。有些代理 IP 在别的网站能用在大众点评就是被屏蔽的状态。所以要定时用测试请求访问大众点评的首页返回 200 才标记为可用。接入代理池有两个选择用现成的开源代理池项目或者自己用付费代理 API 搭建。如果你跑的数据量不大直接配置 3-5 个付费代理轮换就够了如果目标数据量是几十万条建议自建代理池管理几十上百个代理 IP。5.3 用 SQLAlchemy 把数据写入 MySQL管道设计Scrapy 的数据管道是从 Item 到数据库的最后一公里。直接用 pymysql 写 SQL 虽然简单但并发条件下容易出问题。用 SQLAlchemy 做 ORM 层既能管理连接池又能避免手工拼接 SQL 的注入风险。# pipelines.py from sqlalchemy import create_engine, Column, String, Float from sqlalchemy.ext.declarative import declarative_base from sqlalchemy.orm import sessionmaker Base declarative_base() class Shop(Base): __tablename__ dianping_shop shop_id Column(String(20), primary_keyTrue) name Column(String(200)) address Column(String(500)) rating Column(Float) avg_price Column(Float) engine create_engine(mysqlpymysql://user:passlocalhost/dianping) Session sessionmaker(bindengine) class MySQLPipeline: def open_spider(self, spider): self.session Session() def process_item(self, item, spider): shop Shop(**item) self.session.merge(shop) # 主键去重 self.session.commit() return item用merge而不是add是这里的细节merge会根据主键判断记录是否存在存在就更新不存在就插入。这样就算爬虫重复跑到同一个店铺也不会产生脏数据。另外SQLAlchemy 的 session 不是线程安全的Scrapy 的管道默认是单例运行但如果你启用了多个并发管道实例每个实例都要独立创建 session。5.4 请求限速策略DOWNLOAD_DELAY 和 AUTO THROTTLE 怎么配很多人在 Scrapy 里把DOWNLOAD_DELAY设成 1 秒就觉得万无一失实际上这个参数只是单个请求的间隔实际 QPS 是并发数除以延迟。如果你的CONCURRENT_REQUESTS是 16延迟 1 秒实际 QPS 就是 16这个频率大众点评绝对会封你。# settings.py CONCURRENT_REQUESTS 4 DOWNLOAD_DELAY 2.0 AUTOTHROTTLE_ENABLED True AUTOTHROTTLE_START_DELAY 2.0 AUTOTHROTTLE_MAX_DELAY 15.0AUTO THROTTLE 是 Scrapy 内置的自适应限速它会根据服务器响应时间来动态调整延迟。刚开始爬时可以保守一点AUTOTHROTTLE_START_DELAY设大一些让 Scrapy 慢慢试探服务器的容忍度。这里有个血泪经验不要迷信 AUTO THROTTLE它在普通站点好使在大众点评这种反爬机制复杂的站点上响应时间可能是 0.5 秒但也有可能直接就给你返回验证码页面这时候限速算法判断不出来还是得人工观察日志。6. 避坑指南大众点评爬虫的 5 个必踩的坑6.1 被重定向到验证码页面却不报错现象爬虫日志里请求状态全是 200但解析出来的数据全是空列表或者店铺名称全是乱码。原因大众点评把所有需要验证的请求重定向到验证码页面但重定向后的 URL 状态码是 200所以 Scrapy 的日志不会报错。这是最麻的翻车场景因为问题不出在你写的解析逻辑上。解决在中间件里显式检测验证码页面的特征。大众点评验证码页面的 URL 通常包含captcha或verify关键词HTML 里也有明显的验证码 canvas 结构。检测到了就把当前代理加入黑名单并让请求重新排队。6.2 字体映射表在运行中途失效现象前 2 个小时数据正常第 3 个小时开始评分字段变成乱码数字。原因大众点评在某个时间点更换了字体文件但你的映射表缓存的是旧字体解析结果。解决解析字体映射时不要只按 URL 缓存要按字体文件的 MD5 值缓存。每次解析前先下载字体内容计算 MD5如果 MD5 不在缓存里就重新解析。另一个思路是让映射表解析失败时主动清空缓存并重试不要返回空映射。6.3 列表页翻页到第 5 页后请求全部失败现象前 4 页采集正常第 5 页开始返回空响应或直接超时。原因大众点评的翻页机制在页码变大后从静态渲染切换成了动态加载a.next链接不再存在Scrapy 的翻页逻辑直接断掉。解决在 parse 方法里除了找a.next还要检查是否有「加载更多」按钮或异步接口的线索。常见做法是把前 5 页用静态翻页第 5 页之后改用 XHR 接口翻页接口 URL 里的 offset 参数从 0 开始每页递增。6.4 店铺详情页和列表页的 Cookie 不一致现象列表页提取到的数据正常跟进详情页后请求返回 403 或验证码。原因列表页是未登录状态访问的详情页的部分数据需要登录才能查看Cookie 状态不一致导致详情页请求被拒。解决在爬虫启动前确保使用登录后的 Cookie而且详情页的请求要显式携带这个 Cookie。不要依赖 Scrapy 默认的 cookie jar因为 jar 可能会在跳转过程中丢失部分字段。在每次请求前手动设置request.cookies是最可靠的方式。6.5 管道写入阻塞导致爬虫变慢现象爬虫前半段速度正常运行半小时后越来越慢最后几乎停滞。原因SQLAlchemy 的 session 在长时间运行后积累了大量未提交的事务数据库连接池被占满。解决process_item里每条数据都 commit 虽然安全但性能差可以改成每 50 条或 100 条批量 commit 一次。另一个技巧是bulk_save_objects批量插入但要注意它不会自动更新已存在的记录需要配合ON DUPLICATE KEY UPDATE或先查询再插入。7. 进阶用 Scrapy Playwright 集成处理更复杂的反爬场景当常规中间件全部用上还是被大众点评的某些页面卡住时就该上 Playwright 了。Scrapy 2.x 可以通过scrapy-playwright插件集成浏览器自动化能力专门处理那些必须模拟真实浏览器行为才能通过的场景。# settings.py DOWNLOAD_HANDLERS { http: scrapy_playwright.handler.ScrapyPlaywrightDownloadHandler, https: scrapy_playwright.handler.ScrapyPlaywrightDownloadHandler, } PLAYWRIGHT_LAUNCH_OPTIONS { headless: True, }集成之后可以在 Request 里指定meta{playwright: True}让 Scrapy 用真实的 Chromium 去请求页面。这个方案对滑块的滑块验证、动态 iframe 渲染、JS 加密参数都有奇效但代价是速度和资源消耗。一个 Playwright 浏览器实例占用的内存是普通请求的几十倍所以只对关键页面启用常规页面还是走原生的 Scrapy 请求。验证方法很简单跑一个 100 条数据的抽样任务对比 Playwright 模式和纯 Scrapy 模式的成功率与耗时。一般实测结果会是Playwright 模式成功率接近 100%但速度慢 5-10 倍。所以业务规模小、数据实时性要求不高时直接全量用 Playwright 反而省事数据量大时还是要混合调度。最后一个建议是记录每次反爬策略变更的时间点和触发条件。大众点评的反爬策略不是随机改的通常跟活动节点、数据泄露事件有关。当你遇到策略调整时先看自己是不是请求频率太高、代理质量下降再确认是不是站点改版。这个排查顺序能省掉大量猫抓老鼠的时间。做爬虫这么些年我的一个习惯是给每个项目建立一个「翻车日志」代码改动前先记录当前行为改动后对比差异。这种经验积累看起来慢但时间长了踩过坑变成条件反射新项目启动效率会快很多。希望帮到你。本文还有配套的精品资源点击获取