1. 爬虫为什么突然绕不开JavaScript渲染先说个最直观的现象你用requests把页面源码拉下来一眼看过去全是空壳。div idapp/div或者十几个script标签指向一堆打包好的js文件真正想要的商品价格、评论数据一个都找不到。早年爬虫确实舒服服务端把HTML渲染好requests带上headers就能直接解析出数据。现在前后端分离成了绝对主流页面主角变成了JavaScript渲染出来的DOM你拿到手的源码只是一张白纸什么都不告诉你。这背后的原理其实很朴素。传统的服务端渲染用户访问一个URL服务端查数据库、拼模板返回一段完整的HTML爬虫只需要把这段HTML当作静态文档来解析就能拿到全部内容。如今的主流方案是前端框架Vue、React这些负责动态渲染浏览器先请求一个裸壳文档再执行里面一堆JavaScript代码代码去调接口、拿数据、把数据写入DOM。这个过程中数据从一开始就不存在于HTML源码里它在接口响应里、在内存里、在某个异步回调里。那问题来了requests只能拿到那个裸壳文档它不执行JavaScript。你拿到的HTML和用户在浏览器里看到的内容根本是两个世界。这就是整个JavaScript渲染爬虫的核心痛点——你缺的不是解析能力而是让代码去执行JavaScript的能力。Selenium之所以成为这个场景下的经典选择是因为它不走“模拟请求”这条路而是直接“驾驶”一个真实的浏览器让浏览器替你把所有JavaScript跑完渲染出最终效果然后你再从浏览器里把渲染完毕的DOM取出来。从这个角度想问题很多原本复杂的事情一下就简单了你不用逆向分析接口、不用猜登录态怎么维持、不用纠结某个加密参数是怎么来的浏览器把一切都替你处理好了你只负责从结果里捞数据。但这个方案也不是没有代价。Selenium看着门面光鲜真正落地的时候你会碰到一堆苍蝇WebDriver版本对不上、等待时间设置不合理、元素定位偶尔失灵、频繁弹出的验证码、headless模式被识别、内存占用居高不下。这篇文章就把我用Selenium处理JavaScript渲染页面时的完整思路、实操代码、以及踩过的坑都整理出来写给那些被动态页面折磨过的人。无论你是刚入门想抓一个vue渲染的榜单还是在维护一套大型分布式爬虫这套方法论应该都能帮到你。2. 环境准备把Selenium这套马车正确套起来2.1 WebDriver版本匹配这一步最容易翻车很多新手折腾Selenium卡在环境上的时间比写爬虫逻辑还长。最常见的错误就是pip安装了selenium随便下了一个ChromeDriver兴冲冲跑去跑代码结果控制台直接抛出SessionNotCreatedException提示版本不匹配。原因是Chrome每隔几周就自动更新而ChromeDriver没跟着同步两边版本号对不上Selenium就指挥不动浏览器了。我建议直接采用一条简单粗暴的规则Chrome和ChromeDriver的主版本号必须完全一致。比如你本机Chrome是120.x那就去ChromeDriver的下载页面找120.x对应的版本。之后把下载的chromedriver文件放到指定目录macOS/Linux放/usr/local/binWindows放一个自定义目录并在代码里指定路径再确认是否给了可执行权限。这一步做完环境就算立住了。如果你连Chrome版本都懒得手动看也可以直接在代码里动态获取浏览器版本然后拼一个下载URL。但这种自动化方法偶尔会因为网络或命名规则变化而失效所以我更推荐在工程初始化时用一个脚本检查并锁定版本跑一遍就固定住别让环境漂移。环境漂移这个问题在爬虫项目里反而容易被忽视今天跑得好好的明天Chrome自动升级了整个采集任务一夜之间瘫痪你说气不气人。从工程角度讲我更建议对一个爬虫项目固定使用同一版本的Chrome并且关闭自动更新。团队协作时把WebDriver版本写在README里作为前置条件或者直接集成进Docker镜像。毕竟爬虫的稳定性是第一位一个连浏览器版本都无法复现的环境后面的所有调度、增量采集、异常重试都是空中楼阁。2.2 三种等待方式的取舍sleep、隐式等待、显式等待用真实浏览器做爬虫一个核心矛盾在于页面加载不是一蹴而就的而是分阶段完成的。DOM先就绪然后JavaScript异步请求接口然后数据回流到页面整个过程可能需要几百毫秒到几秒不等。如果代码急着去定位元素大概率扑个空。按粗暴程度排序第一档是time.sleep(5)写的时候爽跑起来血压高。设长了效率低设短了不稳定。你永远不知道某个时刻网络快不快、接口慢不慢写死一个固定时间就是在赌运气。第二档是隐式等待driver.implicitly_wait(10)它告诉WebDriver在查找元素时如果元素没出现最多轮询等待这么长时间。这个方案比sleep靠谱但它对所有元素定位生效如果某个元素确实不存在它一定会等满最长时限浪费大量时间。第三档是显式等待WebDriverWait只针对特定条件进行轮询你可以明确地说等这个元素可见、等某个按钮可点击、等某个文字出现。这才是动态页面爬虫应该写进代码里的标准姿势。我在实际项目里的习惯是全局设置一个隐式等待作为兜底但所有关键元素一律用显式等待来锁定时间窗口。需要注意隐式等待和显式等待不能混用得太随意有些旧版本浏览器会把两者的轮询冲突掉导致等待时长异常所以稳妥起见要么全局隐式等待要么全局显式等待。对于异步渲染的核心节点我用显式等待时还会加上poll_frequency0.5这样的参数把轮询间隔缩到半秒既不会太频繁消耗资源又能比较及时地捕捉到元素出现。这里再分享一个我常写的工具函数它接收一个定位器和一个超时时间内部用expected_conditions做可见性判断找不到元素就抛自定义异常方便上层捕获重试。实际使用时我几乎不为“页面加载好”这个模糊概念去等而是永远等待“我要抓的那个东西出现了”这个思维转变本身就是等待策略的核心。2.3 加载策略怎么一上来就提速默认的Selenium会等待整页完全加载包括所有图片、广告、字体、第三方脚本。但做爬虫的人压根不在乎那些图片资源我们要的是数据。Chrome的页面加载策略是可以配置的page_load_strategy有三个选项normal等所有资源、eager等DOMContentLoaded不一定要等样式表、图片等资源、none不等任何资源立刻返回。我实测过很多页面把加载策略从默认的normal改成eager页面初始访问的耗时能缩短30%-50%。原本很多页面要等第三方统计脚本、广告SDK全部就绪才算加载完成而爬虫根本不需要这些东西。改成eager之后DOM结构ready了就可以开始定位元素了只要配合好显式等待数据照样完整。还有一个常见的提速点是屏蔽不必要的请求。你可以通过Chrome DevTools ProtocolCDP在页面加载前屏蔽图片、字体、媒体这类静态资源。具体做法是在开启浏览器时加一个自定义的experimental_options或者在请求拦截层把资源类型为image、font、media的请求直接丢弃。这个操作对数据抓取的最终结果没有任何影响但能省下大量带宽和解析时间。有些页面加载上百张小图屏蔽之后整个生命周期都轻盈了这在批量采集时尤其明显。不过要提醒一句以上这些优化手段的前提是你确实只需要DOM里的文本数据。如果某个页面的数据是画在Canvas里的或者依赖WebGL渲染出来那你还得保留对应的渲染资源。对付这种特殊页面就别一刀切屏蔽资源了后面我会单独讲这个场景的应对思路。3. 核心实操从定位元素到拿全动态数据3.1 用XPath稳定命中动态节点动态页面一个显著特征是class名经常带随机后缀比如classproduct-item_3f9a2这种带hash的class每次发布都可能变。如果你用CSS选择器按class定位大概率隔几天就要改代码。相比之下XPath就灵活得多能用属性谓词就用属性谓词能用文本匹配就用文本匹配实在不行才退回到层级结构。比如要抓一个商品列表中所有的标题与其写死//div[classproduct-item]不如先看父级结构找到稳定的容器再通过相对路径往下走。很多前端框架在循环渲染列表时列表容器通常是稳定的比如ul)而每个列表项的class是自动生成的。这时候我一般用//ul[classproduct-list]/li这样去定位比依赖具体class更抗变更。还有一种场景是匹配文本内容。比如某个页面上有一堆标签你要精准定位“立即购买”按钮直接用//button[contains(text(),立即购买)]。这个写法能绕过那些内部结构每天变来变去的节点。另外normalize-space()这个函数很实用它可以去掉文本首尾空白、合并多个空白字符避免因为源码里换行缩进导致文本匹配不上。这里分享一个我常用的踩坑经验XPath写完后先别急着用爬虫跑直接在浏览器开发者工具里用$x()函数验证一遍。你会发现很多问题是路径表达式本身的问题而不是页面动态渲染的问题。验证通过之后再把XPath放到Selenium的find_element里去跑。这一步能帮你节省大量调试时间。另外万一碰到元素定位超时首先怀疑的不是定位器写错而是这个元素是不是在iframe或者shadow DOM里。如果是iframe先driver.switch_to.frame切进去如果是shadow DOMSelenium原生支持还不够好通常需要借助JavaScript执行器来穿透。3.2 模拟滚动与点击触发懒加载的完整写法懒加载现在是动态页面的标配。页面前几次滚动只渲染一小部分数据滚到底部再触发新的异步请求追加内容。对应的爬虫操作就是模拟滚动。很多教程会给一个execute_script(window.scrollTo(0, document.body.scrollHeight))的操作然后循环若干次。但如果你只执行这一句很快会发现有些页面根本不灵。原因在于很多设计的滚动检测是监听滚动事件的一次性跳到最高点它只会触发一次加载而且加载完之后你依然停留在底部可能还需要再触发一轮。更稳妥的方式是分步滚动每一轮滚动一小段距离然后等待一秒左右再继续往下滚同时每滚一段就检查一次页面高度是否更新了如果高度没变说明已经到底部了就结束循环。还有一种情况页面用的是“查看更多”按钮而不是无限滚动。这时候定位按钮并模拟点击即可。点击之后同样要等待新内容渲染出来可以用显式等待配合一个“新元素出现”的条件。这里有个细节点击按钮之前先记录当前页面上某一类元素的数量点击后再等待该类元素数量增加通过数量变化判断加载是否完成。这个思路比起固定sleep稳定得多因为网络响应时间不可控数量变化才是真实的完成信号。我自己在做这类滚动页面时通常还会把滚动和元素收集分开先滚动到底部等所有数据渲染出来然后一次性执行XPath去定位所有目标元素。不要把“边滚边取”和“滚完再取”混在一起因为边滚边取容易漏掉后面追加的元素。滚完再取虽然内存占用稍大但逻辑清晰、不易踩漏。万一目标页面数据量极大几十万条都堆在一个页面里那还是优先考虑直接抓接口别用浏览器滚到底的方案效率完全不是一个量级。3.3 页面里嵌JSON直接解析比模拟点击更香Selenium的价值是执行JavaScript但不代表所有数据都只能从DOM里捞。很多前端框架会把首屏数据直接以JSON形式塞进script标签里作为初始状态供应用使用。你在页面源码里搜一下window.__INITIAL_STATE__或window.__NUXT__这类关键字经常能搜索出半结构化的数据。这时候的常规操作太吃力了本来元素定位就繁琐还要一个个从DOM里抠文本、清洗、组装成结构化数据费时费力还容易错。更聪明的做法是直接用driver.execute_script(return window.__INITIAL_STATE__)把这坨数据从JavaScript执行环境里取出来然后扔给json.loads解析。一次请求什么都有了。这个思路尤其适合那些列表页嵌套了完整详情数据的场景比如一个商品列表的__INITIAL_STATE__里往往包含所有商品的标题、价格、库存、评价数甚至还有SKU信息。把这些数据一次性拿出来连详情页都不用进去。这类页面的数据往往比DOM显示得更全因为是给前端应用供数的字段一般都尽量完整。需要说明的是这种方法并非万能。有的页面把所有数据都藏在接口请求里内存里并没有一个完整的初始状态对象还有的页面数据动态从接口获取后直接写入DOM并不会全局暴露。因此我的策略是这样的拿到页面之后先花五分钟检查有没有全局JSON、有没有内置接口、有没有Shadow DOM里藏着数据最后再考虑用DOM解析。把数据源优先级排好爬虫效率会高出一个层次。4. 反爬机制与稳定性避坑4.1 常见反爬特征与应对思路用Selenium爬动态页面最怕的不是技术难而是目标站点在用各种手段识别你。常见的反爬手段包括检测浏览器环境中的自动化特征、检测访问频率、验证码、WebDriver痕迹等。这里一个个说。先说访问频率。这是最容易中招的往往表现为连续跑了几分钟突然所有请求返回验证码或者直接被封IP。缓解方式不外乎控制请求速度、随机化延时、设置代理池。随机延时这一点很多人忽略了一个细节不只是两个请求之间随机一个页面内部滚动、点击的节奏也要模拟人类行为。如果每0.5秒就执行一次滚动而且还滚动得极其规律这种操作特征本身就非常可疑。再说明确的自动化检测。现在主流站点会通过JavaScript在页面环境里做探针检查navigator.webdriver属性是否为true、检查窗口是否有类似window.cdc_这样的遗留对象、检查是否启用了--enable-automation标记。如果你直接在代码里用默认选项启动Chrome这些检测点很容易暴露。Selenium官方其实推出了undetected-chromedriver这类补充方案它通过修改运行时参数、隐藏自动化特征让浏览器看起来更接近普通用户操作。在纯技术层面一个有效的做法是启动Chrome时加上--disable-blink-featuresAutomationControlled参数同时通过CDP执行Page.addScriptToEvaluateOnNewDocument在页面加载前把webdriver属性置为undefined。这个操作能绕过一些初级的检测。不过也别指望一套参数就能通吃所有站点反爬和爬虫永远是一场猫鼠游戏更多时候你要学会的是“碰到验证码就跳过、触发风控就降速、数据实在拿不到就换数据源”保持灵活性远比一条路走到黑重要。4.2 JavaScript执行环境的精细化配置顺着自动检测的话题延伸我建议在使用Selenium爬知名网站时不要直接用默认浏览器环境运行。这里面可以做很多细粒度配置目的只有一个让浏览器环境更接近于真人操作。第一是去掉自动化标记。通过options.add_experimental_option(excludeSwitches, [enable-automation])和useAutomationExtension的False配置能减少一部分暴露。第二是设置真实合理的user-agent因为Selenium默认的user-agent中通常暗示是Chrome on Windows或Mac并不会特别暴露自动化但很多站点会校验UA与操作系统的一致性所以手动指定一个真实的UA列表并按权重轮换挺有必要的。第三是时区和语言设置。比如你的网络出口在北京浏览器时区却是UTC这种不一致就可能被风控系统标记。通过options.add_argument(--langzh-CN)、--timezoneAsia/Shanghai等参数能把环境伪装得更自然。这些配置本质上都不是高深的黑科技但它们组成的叠加效应非常明显。我见过一个项目只增加了excludeSwitches参数和合理UA之后同一个站点的验证码出现率从40%降到了5%左右。在爬虫工程里小参数的累积优化往往比单点的大改动更能决定成败。4.3 延时、重试与会话保持除了反爬机制稳定性是另一个大敌。Selenium跑十几个页面之后浏览器内存占用经常飙到1GB以上紧接着就是崩溃、找不到元素、等待超时。很多问题其实不是代码逻辑错了而是浏览器这个有状态进程变得越来越脏。我推荐的稳定性策略是给每一个任务设定明确的超时上限超时就把当前浏览器进程杀掉重启一个新的。这比在同一个会话里反复重试健壮得多。你可以把“打开浏览器-访问页面-提取数据-关闭浏览器”作为一个原子任务单元无论这个单元成功还是失败结束后都必须彻底回收资源。注意是用driver.quit()而不是driver.close()close()只关闭当前窗口进程还在跑资源依然被占用。另外虽然题目是Selenium但我还是想说一句对单个URL的抓取你也可以考虑把requests和Selenium混合用。比如用requests去请求那个挂在页面背后的接口用Selenium来应对登录或者加密参数的生成。两者各有擅长工具配合得当工程运行效率和稳定性都能上一个大台阶。而为了防止会话失效你可以把登录后的Cookie持久化保存在下次启动时直接加载。Cookie这一招在遇到同一个站点反复初始化浏览器时能省掉大量的登录耗时和验证码风险。眼尖的读者应该已经发现了我的核心思路就是把Selenium当作可控的浏览器而非常规意义上的万能抓取器。它的使用范围应该被框得很明确只负责那些必须由它完成的事情。这样整个爬虫工程才不会被浏览器的性能劣势拖垮。5. 性能与工程化把Selenium爬虫跑得像一条生产线5.1 Headless与通知权限、GPU的取舍在生产环境里多数人会直接使用--headless参数开启无头模式让浏览器在后台运行而不显示窗口。无头模式能节省一部分图形渲染的资源但它也带来一些新问题某些网站会检测到headless并限制访问某些Canvas绘制相关的反爬特征在无头环境下更容易暴露。针对这一点新版Chrome提供了一个更加伪装的选择--headlessnew。这个新模式跟有头模式共用同一套渲染路径比老的无头模式在指纹一致性上要好不少。实测中很多老headless下被识别的页面换成新headless后能正常访问。如果你还在使用--headless的旧参数强烈建议升级。还有一个常被忽略的参数组合是GPU和沙箱。在Windows或Linux环境下不加--disable-gpu有时候会导致渲染问题而在容器环境里不加--no-sandbox又会直接启动失败。这些参数看起来琐碎但每一个都是生产环境稳定运行的基石。配置的时候我不建议照抄别人博客里的全套参数正确的姿势是先看看自己的运行环境缺什么再加什么不要为了求全而盲目堆参数。5.2 分布式与并发别让Selenium成为性能瓶颈Selenium的设计目标是浏览器自动化测试它的并发模型天然不擅长处理大数据量的爬取任务。每一个WebDriver实例都对应一个独立的浏览器进程内存开销大、启动销毁成本高。想在单机上面堆上百个并发实例内存直接爆掉。所以做工程化的时候思路必须转变。第一种思路是单浏览器多页面复用。如果你有多个页面需要抓取尽量不要为每个页面都启动一次浏览器而是启动一个浏览器用多个tab分别加载不同URL。Selenium支持通过窗口句柄切换到不同的tab。这种方式能缓解反复初始化浏览器的开销但也有隐患页面之间会互相抢占资源一个页面卡死可能拖慢其他页面。所以说到底这种复用更适合少量页面、单批任务不适合大规模调度。第二种思路是进程级别的分布式。把采集任务按照域名、URL列表分片分发到多台机器上的多个WebDriver节点每个节点各自只负责一个较小的任务片。配合消息队列做任务的调度和结果回收这在规模上来以后几乎是必经之路。你也可以考虑使用Selenium Grid来管理多个远程节点但Grid更偏向测试场景在数据采集场景下我个人更倾向于直接用消息队列控制任务分片写起来更灵活也更容易和现有的业务代码打通。还有一点如果数据源对时效性要求不高把所有请求的并发强制压在个位数也是可以的。Selenium爬虫吃的是低并发、高可靠性的路线一万条数据跑得慢一点无所谓但每一条都要稳。真正的高并发任务长期来看还是得走requests去调接口。很多时候你会发现用浏览器在页面上翻来翻去还不如花一天时间分析出参数加密逻辑然后用requests直接调接口性能和稳定性都能完胜。5.3 监控与告警怎么知道任务挂了爬虫工程最忌讳的就是半夜挂了早上才发现。Selenium爬虫的故障模式多种多样但很多故障是有征兆的。我强烈建议在工程里埋好监控点最基本的是这三类指标任务成功率、平均抓取耗时、每个环节的超时次数。把这几个指标实时反馈到控制台或者告警系统里一旦成功率下降或者某个URL的超时次数激增马上就能感知到站点的变化。抓取到的数据结构也要做校验。很多爬虫任务看似运行成功页面没报错但拿回来的字段全是空的这就意味着页面结构改版了或者数据被吞了。我在核心数据提取逻辑里面都会加一层字段完整性校验比如必须同时包含标题、发布时间、正文内容缺任何一个就判为抓取失败。这个校验逻辑能防止“空跑一晚上”这种最磨人的事故。另外一个实用的监控手段是记录每个页面的渲染时长和DOM数量。如果某天突然发现页面渲染时间翻倍、DOM节点数暴增往往意味着目标站点换了新的前端框架或者加了新的埋点脚本这时候就该去人工复查一下页面结构了。把这些监控和告警做好Selenium爬虫的生产力才能真正释放出来。6. 常见问题与排查技巧实录这份速查表是根据我自己实操中反复踩坑的经验整理出来的不一定覆盖所有场景但应对Selenium爬虫的高频故障绰绰有余。现象可能原因排查与解决启动就报SessionNotCreatedExceptionChrome与ChromeDriver版本不匹配用chrome://version查版本去下载对应ChromeDriver替换能打开页面但找不到元素页面还没渲染完就定位了改用显式等待等待目标元素可见再操作元素在页面源码里看不到数据来自异步接口且还未回流先滚动到底确认数据渲染完成再解析定位到的元素点击无反应可能是被遮挡或需要触发事件用execute_script直接执行click()方法绕过遮挡页面出现大量验证码访问频率过高或环境被标记降速、加随机延时、隐藏webdriver特征、轮换UA跑了几个页面后浏览器越来越慢浏览器进程未回收或缓存堆积定期driver.quit()必要时重启浏览器实例headless模式拿不到数据站点检测到无头环境改用--headlessnew或关闭headless跑一次看差异scrollTo滚不到底滚动逻辑依赖事件监听改为小步多次滚动并等待高度增量后再继续iframe里的元素定位不到iframe未切换进去先switch_to.frame再定位子元素XPath昨天能用今天失效前端class名动态变化改稳定的层级结构用contains文本匹配兜底再补充两个容易被忽略的细节。第一find_element返回的WebElement对象不要跨页面保留一旦页面刷新或跳转这个对象会立刻失效。如果你存了一批元素想等页面跳转后再用那必然会抛StaleElementReferenceException。正确做法是用好判断条件先等待元素出现立刻取值取完即走。第二日志比断点更好用。Selenium项目调试时很多问题表现为偶发性的持续几秒的延迟断点很难复现。我通常会在关键节点打印结构化日志比如“页面已加载耗时2.3s”、“定位商品标题成功耗时0.8s”日志里带时间戳和URL一旦某个环节变慢从日志里一眼就能定位。排查问题讲究的是先看日志变化规律再决定要不要改代码。关于这个主题我想再分享一个个人看法。Selenium解决的是“浏览器里能看到的数据怎么抓下来”的问题但它绝不是效率最高的工具。它的优势在于把复杂的渲染流程封装成了一个简单的“最终DOM”让爬虫逻辑变得直观它的劣势在于重、慢、占资源。所以我对Selenium的定位一直很明确用在该用的地方但不要把它当作唯一武器。拿到一个动态页面先花时间想清楚数据到底从哪里来能解析接口就尽量解析接口解析不了再上浏览器自动化。这种思路从上位视角决定了工程的下限和上限。我自己的实践里Selenium高级技巧的核心根本不是记住某个API怎么用而是建立起“浏览器渲染链路”的全局认知。当你理解了DOM的生成过程、理解了资源加载的时机、理解了反爬检测的着眼点你就能在任何页面上快速找到破局点。这也是我写这篇文章的最终目的。希望这些经验能帮你少踩几个坑少熬几个夜把时间花在真正有价值的数据分析上。 
长河君 · 2026/10/8 20:04:44 · 阅读 1.2k Selenium爬虫实战：突破JavaScript渲染与反爬的抓取攻略
1. 爬虫为什么突然绕不开JavaScript渲染先说个最直观的现象你用requests把页面源码拉下来一眼看过去全是空壳。div idapp/div或者十几个script标签指向一堆打包好的js文件真正想要的商品价格、评论数据一个都找不到。早年爬虫确实舒服服务端把HTML渲染好requests带上headers就能直接解析出数据。现在前后端分离成了绝对主流页面主角变成了JavaScript渲染出来的DOM你拿到手的源码只是一张白纸什么都不告诉你。这背后的原理其实很朴素。传统的服务端渲染用户访问一个URL服务端查数据库、拼模板返回一段完整的HTML爬虫只需要把这段HTML当作静态文档来解析就能拿到全部内容。如今的主流方案是前端框架Vue、React这些负责动态渲染浏览器先请求一个裸壳文档再执行里面一堆JavaScript代码代码去调接口、拿数据、把数据写入DOM。这个过程中数据从一开始就不存在于HTML源码里它在接口响应里、在内存里、在某个异步回调里。那问题来了requests只能拿到那个裸壳文档它不执行JavaScript。你拿到的HTML和用户在浏览器里看到的内容根本是两个世界。这就是整个JavaScript渲染爬虫的核心痛点——你缺的不是解析能力而是让代码去执行JavaScript的能力。Selenium之所以成为这个场景下的经典选择是因为它不走“模拟请求”这条路而是直接“驾驶”一个真实的浏览器让浏览器替你把所有JavaScript跑完渲染出最终效果然后你再从浏览器里把渲染完毕的DOM取出来。从这个角度想问题很多原本复杂的事情一下就简单了你不用逆向分析接口、不用猜登录态怎么维持、不用纠结某个加密参数是怎么来的浏览器把一切都替你处理好了你只负责从结果里捞数据。但这个方案也不是没有代价。Selenium看着门面光鲜真正落地的时候你会碰到一堆苍蝇WebDriver版本对不上、等待时间设置不合理、元素定位偶尔失灵、频繁弹出的验证码、headless模式被识别、内存占用居高不下。这篇文章就把我用Selenium处理JavaScript渲染页面时的完整思路、实操代码、以及踩过的坑都整理出来写给那些被动态页面折磨过的人。无论你是刚入门想抓一个vue渲染的榜单还是在维护一套大型分布式爬虫这套方法论应该都能帮到你。2. 环境准备把Selenium这套马车正确套起来2.1 WebDriver版本匹配这一步最容易翻车很多新手折腾Selenium卡在环境上的时间比写爬虫逻辑还长。最常见的错误就是pip安装了selenium随便下了一个ChromeDriver兴冲冲跑去跑代码结果控制台直接抛出SessionNotCreatedException提示版本不匹配。原因是Chrome每隔几周就自动更新而ChromeDriver没跟着同步两边版本号对不上Selenium就指挥不动浏览器了。我建议直接采用一条简单粗暴的规则Chrome和ChromeDriver的主版本号必须完全一致。比如你本机Chrome是120.x那就去ChromeDriver的下载页面找120.x对应的版本。之后把下载的chromedriver文件放到指定目录macOS/Linux放/usr/local/binWindows放一个自定义目录并在代码里指定路径再确认是否给了可执行权限。这一步做完环境就算立住了。如果你连Chrome版本都懒得手动看也可以直接在代码里动态获取浏览器版本然后拼一个下载URL。但这种自动化方法偶尔会因为网络或命名规则变化而失效所以我更推荐在工程初始化时用一个脚本检查并锁定版本跑一遍就固定住别让环境漂移。环境漂移这个问题在爬虫项目里反而容易被忽视今天跑得好好的明天Chrome自动升级了整个采集任务一夜之间瘫痪你说气不气人。从工程角度讲我更建议对一个爬虫项目固定使用同一版本的Chrome并且关闭自动更新。团队协作时把WebDriver版本写在README里作为前置条件或者直接集成进Docker镜像。毕竟爬虫的稳定性是第一位一个连浏览器版本都无法复现的环境后面的所有调度、增量采集、异常重试都是空中楼阁。2.2 三种等待方式的取舍sleep、隐式等待、显式等待用真实浏览器做爬虫一个核心矛盾在于页面加载不是一蹴而就的而是分阶段完成的。DOM先就绪然后JavaScript异步请求接口然后数据回流到页面整个过程可能需要几百毫秒到几秒不等。如果代码急着去定位元素大概率扑个空。按粗暴程度排序第一档是time.sleep(5)写的时候爽跑起来血压高。设长了效率低设短了不稳定。你永远不知道某个时刻网络快不快、接口慢不慢写死一个固定时间就是在赌运气。第二档是隐式等待driver.implicitly_wait(10)它告诉WebDriver在查找元素时如果元素没出现最多轮询等待这么长时间。这个方案比sleep靠谱但它对所有元素定位生效如果某个元素确实不存在它一定会等满最长时限浪费大量时间。第三档是显式等待WebDriverWait只针对特定条件进行轮询你可以明确地说等这个元素可见、等某个按钮可点击、等某个文字出现。这才是动态页面爬虫应该写进代码里的标准姿势。我在实际项目里的习惯是全局设置一个隐式等待作为兜底但所有关键元素一律用显式等待来锁定时间窗口。需要注意隐式等待和显式等待不能混用得太随意有些旧版本浏览器会把两者的轮询冲突掉导致等待时长异常所以稳妥起见要么全局隐式等待要么全局显式等待。对于异步渲染的核心节点我用显式等待时还会加上poll_frequency0.5这样的参数把轮询间隔缩到半秒既不会太频繁消耗资源又能比较及时地捕捉到元素出现。这里再分享一个我常写的工具函数它接收一个定位器和一个超时时间内部用expected_conditions做可见性判断找不到元素就抛自定义异常方便上层捕获重试。实际使用时我几乎不为“页面加载好”这个模糊概念去等而是永远等待“我要抓的那个东西出现了”这个思维转变本身就是等待策略的核心。2.3 加载策略怎么一上来就提速默认的Selenium会等待整页完全加载包括所有图片、广告、字体、第三方脚本。但做爬虫的人压根不在乎那些图片资源我们要的是数据。Chrome的页面加载策略是可以配置的page_load_strategy有三个选项normal等所有资源、eager等DOMContentLoaded不一定要等样式表、图片等资源、none不等任何资源立刻返回。我实测过很多页面把加载策略从默认的normal改成eager页面初始访问的耗时能缩短30%-50%。原本很多页面要等第三方统计脚本、广告SDK全部就绪才算加载完成而爬虫根本不需要这些东西。改成eager之后DOM结构ready了就可以开始定位元素了只要配合好显式等待数据照样完整。还有一个常见的提速点是屏蔽不必要的请求。你可以通过Chrome DevTools ProtocolCDP在页面加载前屏蔽图片、字体、媒体这类静态资源。具体做法是在开启浏览器时加一个自定义的experimental_options或者在请求拦截层把资源类型为image、font、media的请求直接丢弃。这个操作对数据抓取的最终结果没有任何影响但能省下大量带宽和解析时间。有些页面加载上百张小图屏蔽之后整个生命周期都轻盈了这在批量采集时尤其明显。不过要提醒一句以上这些优化手段的前提是你确实只需要DOM里的文本数据。如果某个页面的数据是画在Canvas里的或者依赖WebGL渲染出来那你还得保留对应的渲染资源。对付这种特殊页面就别一刀切屏蔽资源了后面我会单独讲这个场景的应对思路。3. 核心实操从定位元素到拿全动态数据3.1 用XPath稳定命中动态节点动态页面一个显著特征是class名经常带随机后缀比如classproduct-item_3f9a2这种带hash的class每次发布都可能变。如果你用CSS选择器按class定位大概率隔几天就要改代码。相比之下XPath就灵活得多能用属性谓词就用属性谓词能用文本匹配就用文本匹配实在不行才退回到层级结构。比如要抓一个商品列表中所有的标题与其写死//div[classproduct-item]不如先看父级结构找到稳定的容器再通过相对路径往下走。很多前端框架在循环渲染列表时列表容器通常是稳定的比如ul)而每个列表项的class是自动生成的。这时候我一般用//ul[classproduct-list]/li这样去定位比依赖具体class更抗变更。还有一种场景是匹配文本内容。比如某个页面上有一堆标签你要精准定位“立即购买”按钮直接用//button[contains(text(),立即购买)]。这个写法能绕过那些内部结构每天变来变去的节点。另外normalize-space()这个函数很实用它可以去掉文本首尾空白、合并多个空白字符避免因为源码里换行缩进导致文本匹配不上。这里分享一个我常用的踩坑经验XPath写完后先别急着用爬虫跑直接在浏览器开发者工具里用$x()函数验证一遍。你会发现很多问题是路径表达式本身的问题而不是页面动态渲染的问题。验证通过之后再把XPath放到Selenium的find_element里去跑。这一步能帮你节省大量调试时间。另外万一碰到元素定位超时首先怀疑的不是定位器写错而是这个元素是不是在iframe或者shadow DOM里。如果是iframe先driver.switch_to.frame切进去如果是shadow DOMSelenium原生支持还不够好通常需要借助JavaScript执行器来穿透。3.2 模拟滚动与点击触发懒加载的完整写法懒加载现在是动态页面的标配。页面前几次滚动只渲染一小部分数据滚到底部再触发新的异步请求追加内容。对应的爬虫操作就是模拟滚动。很多教程会给一个execute_script(window.scrollTo(0, document.body.scrollHeight))的操作然后循环若干次。但如果你只执行这一句很快会发现有些页面根本不灵。原因在于很多设计的滚动检测是监听滚动事件的一次性跳到最高点它只会触发一次加载而且加载完之后你依然停留在底部可能还需要再触发一轮。更稳妥的方式是分步滚动每一轮滚动一小段距离然后等待一秒左右再继续往下滚同时每滚一段就检查一次页面高度是否更新了如果高度没变说明已经到底部了就结束循环。还有一种情况页面用的是“查看更多”按钮而不是无限滚动。这时候定位按钮并模拟点击即可。点击之后同样要等待新内容渲染出来可以用显式等待配合一个“新元素出现”的条件。这里有个细节点击按钮之前先记录当前页面上某一类元素的数量点击后再等待该类元素数量增加通过数量变化判断加载是否完成。这个思路比起固定sleep稳定得多因为网络响应时间不可控数量变化才是真实的完成信号。我自己在做这类滚动页面时通常还会把滚动和元素收集分开先滚动到底部等所有数据渲染出来然后一次性执行XPath去定位所有目标元素。不要把“边滚边取”和“滚完再取”混在一起因为边滚边取容易漏掉后面追加的元素。滚完再取虽然内存占用稍大但逻辑清晰、不易踩漏。万一目标页面数据量极大几十万条都堆在一个页面里那还是优先考虑直接抓接口别用浏览器滚到底的方案效率完全不是一个量级。3.3 页面里嵌JSON直接解析比模拟点击更香Selenium的价值是执行JavaScript但不代表所有数据都只能从DOM里捞。很多前端框架会把首屏数据直接以JSON形式塞进script标签里作为初始状态供应用使用。你在页面源码里搜一下window.__INITIAL_STATE__或window.__NUXT__这类关键字经常能搜索出半结构化的数据。这时候的常规操作太吃力了本来元素定位就繁琐还要一个个从DOM里抠文本、清洗、组装成结构化数据费时费力还容易错。更聪明的做法是直接用driver.execute_script(return window.__INITIAL_STATE__)把这坨数据从JavaScript执行环境里取出来然后扔给json.loads解析。一次请求什么都有了。这个思路尤其适合那些列表页嵌套了完整详情数据的场景比如一个商品列表的__INITIAL_STATE__里往往包含所有商品的标题、价格、库存、评价数甚至还有SKU信息。把这些数据一次性拿出来连详情页都不用进去。这类页面的数据往往比DOM显示得更全因为是给前端应用供数的字段一般都尽量完整。需要说明的是这种方法并非万能。有的页面把所有数据都藏在接口请求里内存里并没有一个完整的初始状态对象还有的页面数据动态从接口获取后直接写入DOM并不会全局暴露。因此我的策略是这样的拿到页面之后先花五分钟检查有没有全局JSON、有没有内置接口、有没有Shadow DOM里藏着数据最后再考虑用DOM解析。把数据源优先级排好爬虫效率会高出一个层次。4. 反爬机制与稳定性避坑4.1 常见反爬特征与应对思路用Selenium爬动态页面最怕的不是技术难而是目标站点在用各种手段识别你。常见的反爬手段包括检测浏览器环境中的自动化特征、检测访问频率、验证码、WebDriver痕迹等。这里一个个说。先说访问频率。这是最容易中招的往往表现为连续跑了几分钟突然所有请求返回验证码或者直接被封IP。缓解方式不外乎控制请求速度、随机化延时、设置代理池。随机延时这一点很多人忽略了一个细节不只是两个请求之间随机一个页面内部滚动、点击的节奏也要模拟人类行为。如果每0.5秒就执行一次滚动而且还滚动得极其规律这种操作特征本身就非常可疑。再说明确的自动化检测。现在主流站点会通过JavaScript在页面环境里做探针检查navigator.webdriver属性是否为true、检查窗口是否有类似window.cdc_这样的遗留对象、检查是否启用了--enable-automation标记。如果你直接在代码里用默认选项启动Chrome这些检测点很容易暴露。Selenium官方其实推出了undetected-chromedriver这类补充方案它通过修改运行时参数、隐藏自动化特征让浏览器看起来更接近普通用户操作。在纯技术层面一个有效的做法是启动Chrome时加上--disable-blink-featuresAutomationControlled参数同时通过CDP执行Page.addScriptToEvaluateOnNewDocument在页面加载前把webdriver属性置为undefined。这个操作能绕过一些初级的检测。不过也别指望一套参数就能通吃所有站点反爬和爬虫永远是一场猫鼠游戏更多时候你要学会的是“碰到验证码就跳过、触发风控就降速、数据实在拿不到就换数据源”保持灵活性远比一条路走到黑重要。4.2 JavaScript执行环境的精细化配置顺着自动检测的话题延伸我建议在使用Selenium爬知名网站时不要直接用默认浏览器环境运行。这里面可以做很多细粒度配置目的只有一个让浏览器环境更接近于真人操作。第一是去掉自动化标记。通过options.add_experimental_option(excludeSwitches, [enable-automation])和useAutomationExtension的False配置能减少一部分暴露。第二是设置真实合理的user-agent因为Selenium默认的user-agent中通常暗示是Chrome on Windows或Mac并不会特别暴露自动化但很多站点会校验UA与操作系统的一致性所以手动指定一个真实的UA列表并按权重轮换挺有必要的。第三是时区和语言设置。比如你的网络出口在北京浏览器时区却是UTC这种不一致就可能被风控系统标记。通过options.add_argument(--langzh-CN)、--timezoneAsia/Shanghai等参数能把环境伪装得更自然。这些配置本质上都不是高深的黑科技但它们组成的叠加效应非常明显。我见过一个项目只增加了excludeSwitches参数和合理UA之后同一个站点的验证码出现率从40%降到了5%左右。在爬虫工程里小参数的累积优化往往比单点的大改动更能决定成败。4.3 延时、重试与会话保持除了反爬机制稳定性是另一个大敌。Selenium跑十几个页面之后浏览器内存占用经常飙到1GB以上紧接着就是崩溃、找不到元素、等待超时。很多问题其实不是代码逻辑错了而是浏览器这个有状态进程变得越来越脏。我推荐的稳定性策略是给每一个任务设定明确的超时上限超时就把当前浏览器进程杀掉重启一个新的。这比在同一个会话里反复重试健壮得多。你可以把“打开浏览器-访问页面-提取数据-关闭浏览器”作为一个原子任务单元无论这个单元成功还是失败结束后都必须彻底回收资源。注意是用driver.quit()而不是driver.close()close()只关闭当前窗口进程还在跑资源依然被占用。另外虽然题目是Selenium但我还是想说一句对单个URL的抓取你也可以考虑把requests和Selenium混合用。比如用requests去请求那个挂在页面背后的接口用Selenium来应对登录或者加密参数的生成。两者各有擅长工具配合得当工程运行效率和稳定性都能上一个大台阶。而为了防止会话失效你可以把登录后的Cookie持久化保存在下次启动时直接加载。Cookie这一招在遇到同一个站点反复初始化浏览器时能省掉大量的登录耗时和验证码风险。眼尖的读者应该已经发现了我的核心思路就是把Selenium当作可控的浏览器而非常规意义上的万能抓取器。它的使用范围应该被框得很明确只负责那些必须由它完成的事情。这样整个爬虫工程才不会被浏览器的性能劣势拖垮。5. 性能与工程化把Selenium爬虫跑得像一条生产线5.1 Headless与通知权限、GPU的取舍在生产环境里多数人会直接使用--headless参数开启无头模式让浏览器在后台运行而不显示窗口。无头模式能节省一部分图形渲染的资源但它也带来一些新问题某些网站会检测到headless并限制访问某些Canvas绘制相关的反爬特征在无头环境下更容易暴露。针对这一点新版Chrome提供了一个更加伪装的选择--headlessnew。这个新模式跟有头模式共用同一套渲染路径比老的无头模式在指纹一致性上要好不少。实测中很多老headless下被识别的页面换成新headless后能正常访问。如果你还在使用--headless的旧参数强烈建议升级。还有一个常被忽略的参数组合是GPU和沙箱。在Windows或Linux环境下不加--disable-gpu有时候会导致渲染问题而在容器环境里不加--no-sandbox又会直接启动失败。这些参数看起来琐碎但每一个都是生产环境稳定运行的基石。配置的时候我不建议照抄别人博客里的全套参数正确的姿势是先看看自己的运行环境缺什么再加什么不要为了求全而盲目堆参数。5.2 分布式与并发别让Selenium成为性能瓶颈Selenium的设计目标是浏览器自动化测试它的并发模型天然不擅长处理大数据量的爬取任务。每一个WebDriver实例都对应一个独立的浏览器进程内存开销大、启动销毁成本高。想在单机上面堆上百个并发实例内存直接爆掉。所以做工程化的时候思路必须转变。第一种思路是单浏览器多页面复用。如果你有多个页面需要抓取尽量不要为每个页面都启动一次浏览器而是启动一个浏览器用多个tab分别加载不同URL。Selenium支持通过窗口句柄切换到不同的tab。这种方式能缓解反复初始化浏览器的开销但也有隐患页面之间会互相抢占资源一个页面卡死可能拖慢其他页面。所以说到底这种复用更适合少量页面、单批任务不适合大规模调度。第二种思路是进程级别的分布式。把采集任务按照域名、URL列表分片分发到多台机器上的多个WebDriver节点每个节点各自只负责一个较小的任务片。配合消息队列做任务的调度和结果回收这在规模上来以后几乎是必经之路。你也可以考虑使用Selenium Grid来管理多个远程节点但Grid更偏向测试场景在数据采集场景下我个人更倾向于直接用消息队列控制任务分片写起来更灵活也更容易和现有的业务代码打通。还有一点如果数据源对时效性要求不高把所有请求的并发强制压在个位数也是可以的。Selenium爬虫吃的是低并发、高可靠性的路线一万条数据跑得慢一点无所谓但每一条都要稳。真正的高并发任务长期来看还是得走requests去调接口。很多时候你会发现用浏览器在页面上翻来翻去还不如花一天时间分析出参数加密逻辑然后用requests直接调接口性能和稳定性都能完胜。5.3 监控与告警怎么知道任务挂了爬虫工程最忌讳的就是半夜挂了早上才发现。Selenium爬虫的故障模式多种多样但很多故障是有征兆的。我强烈建议在工程里埋好监控点最基本的是这三类指标任务成功率、平均抓取耗时、每个环节的超时次数。把这几个指标实时反馈到控制台或者告警系统里一旦成功率下降或者某个URL的超时次数激增马上就能感知到站点的变化。抓取到的数据结构也要做校验。很多爬虫任务看似运行成功页面没报错但拿回来的字段全是空的这就意味着页面结构改版了或者数据被吞了。我在核心数据提取逻辑里面都会加一层字段完整性校验比如必须同时包含标题、发布时间、正文内容缺任何一个就判为抓取失败。这个校验逻辑能防止“空跑一晚上”这种最磨人的事故。另外一个实用的监控手段是记录每个页面的渲染时长和DOM数量。如果某天突然发现页面渲染时间翻倍、DOM节点数暴增往往意味着目标站点换了新的前端框架或者加了新的埋点脚本这时候就该去人工复查一下页面结构了。把这些监控和告警做好Selenium爬虫的生产力才能真正释放出来。6. 常见问题与排查技巧实录这份速查表是根据我自己实操中反复踩坑的经验整理出来的不一定覆盖所有场景但应对Selenium爬虫的高频故障绰绰有余。现象可能原因排查与解决启动就报SessionNotCreatedExceptionChrome与ChromeDriver版本不匹配用chrome://version查版本去下载对应ChromeDriver替换能打开页面但找不到元素页面还没渲染完就定位了改用显式等待等待目标元素可见再操作元素在页面源码里看不到数据来自异步接口且还未回流先滚动到底确认数据渲染完成再解析定位到的元素点击无反应可能是被遮挡或需要触发事件用execute_script直接执行click()方法绕过遮挡页面出现大量验证码访问频率过高或环境被标记降速、加随机延时、隐藏webdriver特征、轮换UA跑了几个页面后浏览器越来越慢浏览器进程未回收或缓存堆积定期driver.quit()必要时重启浏览器实例headless模式拿不到数据站点检测到无头环境改用--headlessnew或关闭headless跑一次看差异scrollTo滚不到底滚动逻辑依赖事件监听改为小步多次滚动并等待高度增量后再继续iframe里的元素定位不到iframe未切换进去先switch_to.frame再定位子元素XPath昨天能用今天失效前端class名动态变化改稳定的层级结构用contains文本匹配兜底再补充两个容易被忽略的细节。第一find_element返回的WebElement对象不要跨页面保留一旦页面刷新或跳转这个对象会立刻失效。如果你存了一批元素想等页面跳转后再用那必然会抛StaleElementReferenceException。正确做法是用好判断条件先等待元素出现立刻取值取完即走。第二日志比断点更好用。Selenium项目调试时很多问题表现为偶发性的持续几秒的延迟断点很难复现。我通常会在关键节点打印结构化日志比如“页面已加载耗时2.3s”、“定位商品标题成功耗时0.8s”日志里带时间戳和URL一旦某个环节变慢从日志里一眼就能定位。排查问题讲究的是先看日志变化规律再决定要不要改代码。关于这个主题我想再分享一个个人看法。Selenium解决的是“浏览器里能看到的数据怎么抓下来”的问题但它绝不是效率最高的工具。它的优势在于把复杂的渲染流程封装成了一个简单的“最终DOM”让爬虫逻辑变得直观它的劣势在于重、慢、占资源。所以我对Selenium的定位一直很明确用在该用的地方但不要把它当作唯一武器。拿到一个动态页面先花时间想清楚数据到底从哪里来能解析接口就尽量解析接口解析不了再上浏览器自动化。这种思路从上位视角决定了工程的下限和上限。我自己的实践里Selenium高级技巧的核心根本不是记住某个API怎么用而是建立起“浏览器渲染链路”的全局认知。当你理解了DOM的生成过程、理解了资源加载的时机、理解了反爬检测的着眼点你就能在任何页面上快速找到破局点。这也是我写这篇文章的最终目的。希望这些经验能帮你少踩几个坑少熬几个夜把时间花在真正有价值的数据分析上。