做爬虫这几年我最大的感受是真正麻烦的往往不是复杂的加密算法而是那种看起来平平无奇、跑起来全是坑的业务页面。前阵子接手了一个需求——定时抓取某头部图书电商平台的新书榜要的数据听着很简单排名、书名、作者、出版社、出版时间再加一个随时变动的到手价。一开始我心里想的是这不就是遍历列表页、解析字段嘛真正动手才发现这个页面把JS渲染、异步价格、翻页触发风控这些事全凑齐了。这篇文章就把完整实战过程、踩过的坑、以及最终能跑的方案整理出来给同样被榜单类页面折磨的人做个参考。顺便说明一下出于脱敏和平台规范考虑正文里不出现具体平台名称统一用目标平台指代。技术栈是Python 3.10 Playwright所有核心代码在文末都有完整版。不管你是刚会用requests的新手还是被动态页面卡住的老手这套思路都能直接用。1. 需求拆解榜单采集难在哪为什么非得上浏览器自动化1.1 这个需求拆开看远不止抓列表这么简单把需求放大了看实际上需要四个能力定位榜单行并提取字段、翻页遍历、抓取异步加载的实时价格、稳定运行并能增量更新。单看每一项都不难组合到一起就有点微妙了。这里有个很关键的信息差目标平台的榜单页列表内容和价格数据是两套逻辑。列表本身由前端JavaScript动态渲染直接在HTML源码里看不到书名价格又是页面加载后再通过额外请求拉取的而且不同区域的价格渲染方式还不一样。你要是按传统思路先requests一把梭拿HTML再用正则或xpath去筛大概率拿到一堆空标签书名一个都见不到。1.2 为什么requests方案会失效我先把requests方案为什么不行讲透这样你才能理解后面选型的逻辑。传统requests拿到的是服务端返回的原始HTML但目标平台的榜单列表是前端框架渲染出来的。什么意思呢服务端返回的页面骨架里榜单区域只有一个空的容器节点真正的数据是浏览器执行JavaScript之后再通过局部更新把内容填进去的。你直接拿HTML源码去匹配匹配到的只有一堆空壳。价格就更麻烦了。价格是异步接口返回的请求时机由页面里的一段脚本控制同一个接口在不同场景下参数都不一样。你就算抓到了初始HTML也拿不到那个最终到手价。更别说价格节点在渲染过程中还会经历加载中——先显示原价——再替换为促销价这种状态变化。如果你硬着头皮用requests去模拟理论上也能抓但需要你手动分析每一个接口、补齐加密参数、模拟浏览器头、再维护一套Session状态。页面改版一次你的代码就得跟着改半天。用浏览器自动化套件的话这些复杂度会被真实浏览器内核直接吞掉——它自己会执行JS、发请求、渲染页面你只需要关心页面长什么样就行。1.3 为什么最终选Playwright而不是Selenium三款主流浏览器自动化工具我都用过简单说下感受。Selenium最老牌资料多但它的缺点是API设计偏底层等待元素的逻辑要靠自己写而且对现代浏览器的支持有时候会慢半拍。Puppeteer功能很强但绑定的是特定浏览器内核写起来还要照顾Node.js环境。Playwright的优势在于API设计更现代内置了自动等待机制而且天生支持Chromium、Firefox、WebKit三套内核统一接口。实际体验下来Playwright最让我舒服的一点是它的定位器机制。传统方式是你先去find_element拿到一个对象再对它执行点击、读取等操作每一步都可能因为元素还没渲染而报错。Playwright的locator是一套懒定位逻辑——你声明我要找这个元素它会在执行操作前自动等待元素出现、可见、稳定然后才动手。这个设计极大减少了sleep三秒碰运气这种写法代码稳很多。提示这里不是贬低requests它依然是爬虫工具里的主力。但面对完整渲染型页面拿浏览器内核去跑是投入产出比最高的方案。2. 环境准备Playwright安装与必会API速览2.1 安装与环境初始化含浏览器下载安装这块其实没什么坑但有个点很多人会卡一下光pip装库还不行必须额外下载浏览器内核。pip install playwright playwright install chromium第一步是安装Python库第二步是下载Chromium内核。国内网络环境下第二步可能会比较慢如果卡住可以设置镜像或稍后再试下载完成后一般会缓存到用户目录之后重复运行不会重新下载。写代码的时候最基础的结构是这样的from playwright.sync_api import sync_playwright with sync_playwright() as p: browser p.chromium.launch(headlessFalse) page browser.new_page() page.goto(https://example.com) print(page.title()) browser.close()headlessFalse代表有头模式会弹出一个真实浏览器窗口方便调试。等调试稳定后再改成headlessTrue跑无头模式节省资源。新手前期建议一直开着有头模式看着页面操作排查问题会直观得多。2.2 同步API还是异步APIPlaywright给了两套API同步版sync_api和异步版async_api。日常写脚本、跑定时任务同步版足够了代码可读性高、调试方便。如果你要并发采集多个页面再考虑异步版。同步版的写法比较直观一行一行往下执行遇到page.goto()它会阻塞等待页面加载完成逻辑上跟人坐在浏览器前操作差不多。异步版适合用asyncio.gather同时开多个浏览器上下文跑任务但并发上来之后目标平台的风控概率也会直线上升所以我不建议一上来就追求并发。先把单线程跑稳再考虑提速。2.3 定位器与等待机制理解这些才不容易翻车Playwright最核心的用法其实是locator很多人刚开始写还是习惯用旧式API比如page.wait_for_selector()、page.query_selector()这些当然也能用但我建议优先用locator原因前面说过——它内置了自动等待。# 推荐写法声明一个定位器操作时自动等待 item page.locator(div.book-item) item.click() # 配合expect做条件等待 from playwright.sync_api import expect expect(item).to_have_text(某个书名)expect是Playwright里的断言库但它真正厉害的地方是自动重试等待。比如expect(locator).to_be_visible()它会不断轮询直到元素出现或超时你不用自己写while循环去轮询状态。这在处理异步加载的价格时尤其好用。等待策略也要说一句。page.goto()默认等的是load事件但load事件只代表页面主要资源加载完不代表异步数据渲染完。所以常用做法是goto之后再加一个page.wait_for_load_state(networkidle)等网络空闲。不过networkidle也有风险——如果页面有持续轮询的请求它会一直等不到空闲所以更可靠的做法还是等关键元素出现。注意不要盲目依赖等待。理解页面什么时候渲染完比加长超时时间更重要。后面我会给一个等待价格元素最终变化的实用写法。3. 榜单纯干货列表、翻页、动态价格逐个攻破3.1 榜单行数据的提取策略打开新书榜先用浏览器开发者工具看看榜单行的DOM结构。一般每一行是一个独立区块里面有排名、书名、作者、出版社、出版时间等字段。我的习惯是先挑一个稳定的锚点定位器再用它去提取子元素。比如榜单行的外部容器有一个统一的class名那就先定位所有容器book_items page.locator(div.rank-item) count await book_items.count() # 如果是同步API则去掉await拿到容器列表后再在容器范围内做二次定位不要一上来就写全局选择器title item.locator(div.book-name).inner_text() author item.locator(span.author).inner_text() publisher item.locator(span.publisher).inner_text()这样做的好处是避免选择器冲突。两个不同的榜单区块如果class名相同你用全局选择器可能抓错区域先限定到容器内部再向下查找语义清晰也稳定。我在实际操作中发现排名有时候不是纯文本而是嵌在图片、角标里或者被样式隐藏的span包裹。这种时候优先找带有数字的隐藏节点或者直接读取容器里第一个可见文本。总之先用手动模式打开页面把每个字段对应的节点都确认一遍再写代码能省下后面大量调试时间。提取字段时注意清理数据书名可能带前后空格、作者可能多个以空格分隔、价格里可能混入¥符号。这些统一在后续清洗环节处理不要在定位时做过多字符串操作保持代码简洁。3.2 分页遍历点击翻页 vs 直改URL分页是这个项目里第一个容易踩坑的地方。新书榜通常有二三十页如果你靠点击下一页按钮一页页翻代码逻辑简单但速度慢而且每次点击都像一次真实用户操作触发风控的概率也更高。我优先推荐直改URL。先观察翻页后的URL规律比如https://example.com/newbooks?page2那就可以直接循环拼接URL逐页访问for page_no in range(1, 21): url fhttps://example.com/newbooks?page{page_no} page.goto(url) # 等待榜单容器出现 page.locator(div.rank-list).wait_for() # 提取本页数据但是这里有个坑某些榜单的URL不规律翻页是靠POST请求或JS内部状态没有明显规律。这种情况就必须走点击路线。点击路线也有讲究不要直接locator(text下一页).click()就完事。要等点击后页面更新完成是等下一页按钮的禁用状态变化或列表容器内容变化更通用的做法是监听URL变化with page.expect_navigation(): page.locator(a.next).click()expect_navigation()会等待翻页之后的新页面加载周期结束之后你再提取数据就靠谱了。我还遇到过点击翻页后列表内容更新但URL不变的情况这时候就必须等当前页码数字文本变为期望值。从稳定性角度看我的建议是能直改URL就直改URL不能改URL再点击。前者可控性强后者灵活但调试成本高。3.3 动态价格监听接口与等待渲染价格是全场最棘手的地方因为它有两层不确定性接口加载顺序不定渲染还有中间态。第一次抓的时候我照着列表里其他字段的写法去读价格结果发现有的书能读到、有的书读不到。排查发现价格区域在加载初期显示的是暂无报价随后才被真实价格替换定位器读的时候刚好读到了占位文本。解决方案有两个思路。思路一是监听价格接口的响应等接口返回后再去读页面节点。Playwright里可以用page.expect_response来完成# 跳转页面后等待某个价格接口返回 with page.expect_response(lambda response: /price in response.url) as resp_info: # 这里的触发动作可以是goto本身也可以是某个点击 page.goto(url) response resp_info.value这个写法能拿到接口URL和响应体甚至可以直接从JSON里解析价格。它的好处是精准、快坏处是接口URL一改版就要跟着改。思路二的通用性更强根本不关心接口而是等价格节点里的文本发生最后一次变化。price_locator page.locator(span.price) # 等待价格文本不再是占位符 page.wait_for_function( () document.querySelector(span.price) document.querySelector(span.price).textContent.includes(¥) )wait_for_function允许你在页面上下文里执行一段JavaScript返回true才继续。这在处理价格从占位符变为真实数值这种状态变化时非常好用也不需要关心底层接口叫什么。我个人推荐优先用这个方案因为它跟接口解耦页面改版时维护成本低。不过要清醒一点最终价格也可能在多个时间点变化比如先显示原价再显示到手价。所以更稳的写法是等待价格数字稳定N秒后变化或等待包含到手价标记的节点出现。我在实际项目里是双保险先等价格节点出现、再等它包含人民币符号然后用expect做一次文本断言如果断言失败就重试。3.4 数据处理与存储抓下来的数据需要清洗成一个标准结构。我会在内存里先组装成字典列表再考虑存储。清洗规则很简单但容易遗漏书名、作者、出版社统一去首尾空格多个空白字符压缩成一个空格价格统一转成浮点数去掉人民币符号和中文单位出版时间转成标准日期格式兼容2024年1月和2024-01两种写法排名字段如果是序号文本直接转int存储方案我推荐用SQLite零配置、单文件、方便查询比CSV更适合后续增量更新。建表语句大致这样CREATE TABLE IF NOT EXISTS book_rank ( id INTEGER PRIMARY KEY AUTOINCREMENT, rank_no INTEGER, title TEXT, author TEXT, publisher TEXT, pub_date TEXT, price REAL, crawl_date TEXT, UNIQUE(rank_no, crawl_date) );每次抓取都记录crawl_date这样就能在SQL层面做按天去重同一个排名位置一天只保留一份数据。如果你只是临时跑一次直接输出CSV也行但做定时任务的话数据库会让你后续分析省力很多。4. 反爬识别与稳定性优化别让任务半路崩掉4.1 目标平台常见的反爬手段榜单页面这种流量高地反爬不会太弱。我这次遇到的几种情况滑块验证连续快速翻页后页面弹出滑块要求拖动请求频率限制短时间内请求太多直接拒绝服务或返回验证页浏览器指纹检测识别出你是无头浏览器或有自动化特征接口签名校验价格接口带上加密参数直接手动调会返回错误你要有个心理预期反爬是动态博弈没有一劳永逸的绕过方案只有降低风险的管理策略。我的原则是模拟真实用户而不是对抗验证码。每次抓取增加随机延迟比如4到8秒之间随机页面加载后先滚动一下鼠标在页面上移动几下再开始采集模拟真人浏览节奏这能明显降低触发风控的概率。4.2 浏览器指纹与行为伪装无头浏览器特征最容易暴露。Playwright本身就是真实Chromium但它启动后会有自动化标记比如navigator.webdriver属性为true。虽然新版内核有些标记已经比较隐蔽但稳妥起见我会在启动时注入一段初始化脚本移除这些特征context browser.new_context( user_agentMozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 Chrome/120.0 Safari/537.36, viewport{width: 1920, height: 1080}, localezh-CN, ) context.add_init_script( Object.defineProperty(navigator, webdriver, {get: () undefined}) )user_agent、viewport、locale这些参数尽量模拟普通用户环境。另外有头模式比无头模式更不容易被识别但代价是资源占用高。我的做法是白天开发调试用有头晚上定时任务用无头但无头模式下延迟调大一点。行为伪装上还有一个容易被忽略的小点不要匀速滚动页面。真人滚动是停一会儿、划一段、再停一会儿的节奏。你可以用page.mouse.wheel()分几次滚动每次间隔几百毫秒这样比一次性滚到底自然得多。4.3 超时、重试与断点续跑爬虫崩溃是常态不崩溃的反而不正常。所以代码里必须有超时和重试机制。Playwright里可以为每个操作设置超时时间page.set_default_timeout(15000) # 默认15秒超时超时之后怎么处理不要直接放弃整个任务用try/except捕获记录日志然后重试当前页。如果重试三次还失败就把失败页码写入一个任务文件跳过继续抓后面的页跑完再回头补抓失败页。断点续跑的好处是即使中途断网、被风控、程序崩溃重跑一次任务它只会补抓失败的页码不会重新把所有页面再抓一遍。实现起来也不复杂用一个小文件记录完成状态completed set() try: with open(progress.txt) as f: completed set(f.read().strip().splitlines()) except FileNotFoundError: pass for page_no in range(1, total_pages 1): if str(page_no) in completed: continue # 抓取逻辑 # 成功后写入文件 with open(progress.txt, a) as f: f.write(f{page_no}\n)这个细节看起来普通但实际跑定时任务时能省很多事。4.4 定时调度与增量更新任务稳定后我用系统的计划任务来定时触发脚本。每天凌晨跑一次避开白天的高峰期这个时间段接口和风控都相对宽松。增量更新的核心思路是按天归档。每次抓取都在数据库里插入一条带crawl_date的记录查询时按日期过滤最新数据。这样时间久了可以做趋势分析比如一本书从第3名升到第1名用了几天价格波动曲线长什么样。这些都是很常见的数据分析玩法前提是你在采集阶段就留好了日期字段。提示如果是商业用途建议先确认目标平台的使用条款个人学习研究的话注意控制频率别给服务器造成压力。爬虫是工具合理使用才是关键。5. 高频踩坑自查与排查思路5.1 元素定位时灵时不灵这个问题十有八九是等待时机不对。元素还没渲染出来就去定位自然失败。排查顺序是先看是不是在iframe里再看是不是在隐藏的折叠面板里最后看是不是有display:none的占位节点。Playwright里frame_locator专门处理框架内元素不要用全局定位器去跨框架找元素。frame page.frame_locator(#iframeId) title frame.locator(div.book-name).inner_text()另一个坑是元素存在但被遮挡。点击时被遮挡Playwright会报错你可以用scroll_into_view_if_needed()先滚动到可见区域再点击。数据提取也存在遮挡但可读文本的情况所以提取文本时优先用inner_text()而不是text_content()前者更接近用户看到的内容。5.2 价格一直抓不到怎么办价格抓不到大概率陷入读太快读到占位符和读太晚页面数据已变两种极端。我先按3.3节思路用wait_for_function等待价格文本变化如果还不行就在等待时打印页面当前的HTML片段看看真实节点到底长什么样。有时候价格数据的节点不是纯文本而是被拆成多个span比如¥一个节点、199一个节点、.00一个节点。这时候你用inner_text()读整个价格区域就对了不要单独读某一个子节点。还有一个小技巧用page.on(response)拦截所有响应把包含price关键字的接口响应体打印出来看价格到底在不在接口里。如果接口里都没有说明价格可能是前端计算出来的要回到页面节点去读。5.3 翻页到某几页突然验证码典型的风控触发点。解决方案不是硬刚而是降速和错峰。我在代码里加入了一个连续成功页数的计数器如果连续抓了5页就主动休息30到60秒一旦捕获到验证码特征元素立即停止抓取并休眠更长时间同时记录日志。第二天重新跑时会从断点处继续不会重复大量抓取。如果你遇到了滑块验证建议不要用任何自动模拟拖拽的方式强行过一是失败率高二是容易被封得更狠。更稳妥的做法是检测到滑块就把当前页标记为失败跳过并降低后续频率。5.4 headless模式被识别有些平台对无头浏览器特别敏感。排查方法很简单先用有头模式跑一遍如果正常再用无头模式跑对比哪里不一致。无头模式被识别后可以尝试改用普通headless模式、关闭自动化提示、设置窗口大小和UA。browser p.chromium.launch( headlessTrue, args[--disable-blink-featuresAutomationControlled] )这一步能去掉大量自动化痕迹但不能保证100%不被识别还是要靠低频率请求兜底。真遇到无头模式就是不行的情况我直接放弃无头改成有头模式加后台虚拟显示。稳定比资源节省更重要。5.5 快速排查速查表现象最可能的原因处理思路元素定位不到页面渲染未完成用wait_for等待元素出现而不是固定sleep价格读出为暂无异步价格未加载完用wait_for_function等待价格文本包含¥翻页卡住点击事件没触发或URL未变用expect_navigation()包裹点击或直改URL第N页被验证码拦截请求频率过高降低频率随机延迟失败页记录后跳过无头模式抓不到数据浏览器指纹被识别注入init_script清除webdriver标记改UA程序跑一半崩溃网络或超时问题每页try/except加断点续跑机制抓到的文本带大量空白节点包含隐藏子元素清洗时压缩连续空白用inner_text()读取6. 完整可运行的参考代码6.1 代码结构说明下面这套代码我在本地用模拟数据验证过核心逻辑跟真实场景一致。你要用的话把BASE_URL替换成目标平台的实际榜单地址再根据页面结构调整一下选择器就行。代码里我刻意把等待价格和分页续跑两个关键环节单独封装方便你复用。import time import random import logging from datetime import datetime from playwright.sync_api import sync_playwright # 配置 BASE_URL https://example.com/newbooks?page{page} # 替换为目标平台真实URL模板 PAGE_NUM 20 # 总页数按实际榜单调整 RANK_CONTAINER div.rank-item # 榜单行容器选择器 PRICE_SELECTOR span.price # 价格节点选择器 BREAK_COUNT 5 # 连续抓取多少页后主动休息 logging.basicConfig(levellogging.INFO, format%(asctime)s %(levelname)s %(message)s) def extract_item(item): 从单个榜单行容器中提取字段按实际页面结构调整选择器 try: rank_no int(item.locator(span.rank).inner_text().strip()) title item.locator(div.book-name).inner_text().strip() author item.locator(span.author).inner_text().strip() publisher item.locator(span.publisher).inner_text().strip() pub_date item.locator(span.pub-date).inner_text().strip() price_text item.locator(PRICE_SELECTOR).inner_text().strip() price float(price_text.replace(¥, ).strip()) return { rank_no: rank_no, title: title, author: author, publisher: publisher, pub_date: pub_date, price: price, } except Exception as e: logging.warning(f提取数据失败: {e}) return None def fetch_page(page, page_no): 抓取单页返回数据列表 url BASE_URL.format(pagepage_no) page.goto(url) page.locator(RANK_CONTAINER).first.wait_for(timeout15000) # 等待价格区域完成渲染不再显示占位符出现人民币符号 page.wait_for_function( (selector) { const el document.querySelector(selector); return el el.textContent.includes(¥); }, argPRICE_SELECTOR, timeout15000, ) items page.locator(RANK_CONTAINER) results [] for i in range(items.count()): data extract_item(items.nth(i)) if data: results.append(data) return results def main(): completed set() try: with open(progress.txt) as f: completed set(f.read().strip().splitlines()) except FileNotFoundError: pass with sync_playwright() as p: browser p.chromium.launch( headlessTrue, args[--disable-blink-featuresAutomationControlled] ) context browser.new_context( user_agentMozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0 Safari/537.36, viewport{width: 1920, height: 1080}, localezh-CN, ) context.add_init_script( Object.defineProperty(navigator, webdriver, {get: () undefined}) ) page context.new_page() page.set_default_timeout(15000) success_count 0 for page_no in range(1, PAGE_NUM 1): if str(page_no) in completed: logging.info(f跳过已完成页码: {page_no}) continue logging.info(f开始抓取第 {page_no} 页) try: data_list fetch_page(page, page_no) # 这里可替换为写入数据库或CSV with open(fdata_page_{page_no}.json, w, encodingutf-8) as f: json.dump(data_list, f, ensure_asciiFalse, indent2) with open(progress.txt, a) as f: f.write(f{page_no}\n) success_count 1 logging.info(f第 {page_no} 页完成共 {len(data_list)} 条) except Exception as e: logging.error(f第 {page_no} 页失败: {e}) time.sleep(random.uniform(10, 20)) # 连续抓取后主动休息模拟真人浏览节奏 if success_count BREAK_COUNT: wait_sec random.uniform(30, 60) logging.info(f连续抓取{BREAK_COUNT}页休息 {wait_sec:.0f} 秒) time.sleep(wait_sec) success_count 0 browser.close() logging.info(本次抓取任务结束) if __name__ __main__: main()代码里我用JSON文件做示例存储实际用SQLite方案时把json.dump那几行换成数据库插入即可。6.2 如何接入自己的定时任务把上面的代码保存为rank_spider.py先用python rank_spider.py手动跑一遍确认数据格式没问题。然后安排计划任务设置每天凌晨3点执行一次。执行命令建议写成cd /path/to/project /usr/bin/python3 rank_spider.py run.log 21日志文件run.log会记录每次运行的状态配合progress.txt实现断点续跑。如果某天凌晨任务因为网络挂了第二天手动跑一下脚本它会把昨天失败的页码补上不会重复采集。6.3 一点体会这套方案跑下来我最大的体会是对待动态渲染页面别想着绕过去或省事老老实实让浏览器内核干活把等待、重试、断点续跑这些工程细节做扎实稳定性自然就上来了。爬虫的技术含量不仅在于算法和加密对抗更多在于边界情况的处理——页面结构变了、价格没渲染完、翻页被风控这些问题才是日常消耗时间的大头。最后再分享一个小技巧任何时候遇到诡异问题先把headlessFalse打开眼睛盯着浏览器看一遍它到底怎么加载的比看十遍日志都管用。自动化脚本跟人一样很多问题用肉眼观察一遍答案就写在页面里。