做爬虫做得久了你会发现一个分水岭静态页面的爬虫写起来再熟练一旦遇到JavaScript渲染的页面之前那套基于requests加正则的玩法瞬间失灵。你明明在浏览器里看到数据了用requests请求同一个地址却只能拿到一堆空壳标签关键内容全在script标签里或者干脆就是一个空div等JS往里面塞东西。这种情况在商品详情页、数据大屏、SPA单页应用里非常常见。Selenium这个从自动化测试起家的工具被爬虫圈捡起来当成处理JS渲染的常规方案核心原因就一条它能驱动一个真实浏览器让页面里的JS老老实实跑完然后再从渲染完成的DOM里取数据。这篇文章我会把Selenium处理JS渲染页面的完整套路拆开讲从环境搭建、等待策略、元素定位到反爬伪装和性能优化全程带代码和踩坑记录适合已经玩过requests但被JS页面卡住的人。1. 先搞清楚JS渲染页面到底在卡你什么很多新手第一反应是“我打开网页源码数据明明在啊为什么Python拿不到”这里有个基本前提需要先掰扯清楚你在浏览器里点“查看网页源代码”看到的是服务器返回的原始HTML但在Chrome的开发者工具Elements面板里看到的是JS执行完毕、DOM被改写过之后的最终状态。爬虫用requests拿到的永远是前者。1.1 静态爬虫的天然盲区静态爬虫的思路是请求URL拿到HTML然后用正则或XPath从HTML里提取内容。这个模式对服务端渲染的页面完全够用因为数据是服务器拼好之后一次性发给浏览器的。但JS渲染页面的逻辑完全不同服务器返回的HTML里可能只有一个空的div容器真正的内容是浏览器加载页面后由JavaScript发起异步请求AJAX/XHR拿到数据再动态创建DOM节点塞进容器里。举个例子我之前爬一个视频列表页静态HTML长这样div idvideo-list/div script src/static/js/app.js/script就这么一丁点东西所有视频标题、封面、播放量全是app.js执行后异步拉取的。requests拿到这个HTML正则根本无从下手。很多人卡在这一步就放弃了觉得是网站加密太牛其实只是用错了工具。1.2 动态页面的三种常见形态我总结了一下日常遇到的JS渲染页面基本就分三类第一类叫“首屏渲染型”数据在页面加载时就通过JS注入DOM加载完成即可见也是最好处理的。第二类是“滚动加载型”页面底部有一个“加载更多”按钮或者滚动到底自动触发请求典型的就是微博、小红书这类信息流。第三类是“SPA路由型”整个网站就是一个React/Vue应用切换页面根本不会重新请求HTML而是动态替换内容。这三种形态里Selenium都能处理但处理方式不一样。第三种如果只是取列表数据更建议去抓后端的JSON接口效率高几十倍但如果你需要的是渲染之后的完整页面状态比如截图、计算元素位置、模拟用户操作后的结果那就只能靠Selenium这种“真实浏览器”方案。这也是我在这篇文章里不讲通用接口逆向的原因——很多页面的JS交互逻辑太复杂逆向成本远高于直接开一个浏览器。2. 为什么是Selenium以及环境怎么一把梭既然要执行JS有人会问直接用无头浏览器不就行了吗技术上没错但Selenium最大的价值在于它把浏览器操作封装成了一整套标准化的API而且生态极其成熟。你随便搜一个爬虫面试题十个里有八个会问Selenium用法这本身就说明问题。2.1 Selenium在爬虫工具链里的定位Selenium本来就是浏览器自动化测试框架它可以模拟点击、输入、滚动、切换标签页等一切用户操作。爬虫社区把它捡起来用本质上是“拿大炮打蚊子”要的只是执行JS之后的结果但付出的代价是完整启动一个浏览器实例内存和CPU开销都不小。相比之下Playwright是后起之秀API设计更现代自动等待机制也做得更好。但Selenium依然有一批死忠用户原因也很现实第一它对老项目的兼容性好第二网上能搜到的爬虫案例和历史代码大多数是Selenium写法第三Chrome和Selenium的组合经过多年折腾各种坑基本都被踩平了。所以我建议如果你只是处理常规的JS渲染页面从Selenium入手完全够用上手成本最低。2.2 环境搭建与浏览器驱动环境搭建这块看着简单但坑全在驱动版本上。Selenium本质上不是自己去操作浏览器而是通过一个驱动driver来控制浏览器。Chrome对应的驱动叫ChromeDriverFirefox对应GeckoDriverEdge对应EdgeDriver。版本不对Selenium一启动就报session created失败。先安装Python库pip install selenium然后下载驱动。这里有个建议优先使用webdriver-manager它可以自动匹配浏览器版本省去手动下载的麻烦pip install webdriver-manager用起来是这样的from selenium import webdriver from selenium.webdriver.chrome.service import Service from webdriver_manager.chrome import ChromeDriverManager driver webdriver.Chrome( serviceService(ChromeDriverManager().install()) ) driver.get(https://example.com) print(driver.title) driver.quit()如果不想引入额外依赖也可以手动下载ChromeDriver并放到系统PATH里。但手动下载一定要看版本对应关系Chrome浏览器版本号是109你的ChromeDriver也得是109.x差一个小版本都可能导致启动失败。2.3 第一次启动几行代码验证环境环境配好之后先用一个最简单的例子验证整条链路能跑通。找一个你平时打开的网站直接获取页面标题和当前URLfrom selenium import webdriver from selenium.webdriver.chrome.options import Options options Options() # 有头模式方便观察页面加载过程 driver webdriver.Chrome(optionsoptions) driver.get(https://www.baidu.com) # 当前页面标题 print(页面标题:, driver.title) # 当前URL print(当前URL:, driver.current_url) # 页面源码长度对比requests抓到的长度 print(源码长度:, len(driver.page_source)) driver.quit()如果控制台能正常打印出标题和URL说明Selenium环境已经通了。这里我习惯打印一下页面源码长度——同样的URLrequests拿到的源码可能只有20KBSelenium渲染之后可能有300KB这个长度差异本身就是“JS已执行”的直接证据。3. 核心实操动态元素的定位与等待的艺术环境通了接下来才是正文。Selenium处理JS渲染页面的核心就两件事一是等元素出现二是找到元素。这两件事没做好其他都是白搭。3.1 等待机制隐式等待、显式等待、强制等待的区别页面里的JS是异步执行的数据什么时候加载完Selenium并不知道。如果你刚打开页面就去找元素大概率会扑空。所以等待策略是整个方案里最重要的部分。我见过不少新手一上来就time.sleep(5)把等待写死。这方式不是不能用但问题很严重如果页面500毫秒就加载完了你白等4.5秒如果网络差5秒还没加载完照样找不到元素。正确做法是用Selenium自带的等待机制。隐式等待implicitly_wait是设置一个全局超时时间之后每次find_element找不到元素时都会最多轮询这么久driver.implicitly_wait(10)显式等待WebDriverWait更精准你可以指定等待某个条件成立from selenium.webdriver.support.ui import WebDriverWait from selenium.webdriver.support import expected_conditions as EC from selenium.webdriver.common.by import By # 等待id为video-list的元素出现最长等10秒 element WebDriverWait(driver, 10).until( EC.presence_of_element_located((By.ID, video-list)) )这里我直接说结论爬虫场景优先用显式等待而且建议等“元素可点击”或“元素可见”而不是单纯等“出现”。因为很多列表接口返回数据后先会显示一个loading动画元素虽然已经渲染到DOM上了但内容还是空的。EC.visibility_of_element_located这个条件能过滤掉大部分这种情况。三种等待方式我这样记忆强制等待是“不管三七二十一先睡一觉”隐式等待是“找不到就等等最多等N秒”显式等待是“条件满足了立刻走条件不满足就等到超时”。效率上显式等待最高因为你不需要猜页面要多久才能加载完。3.2 元素定位的实战姿势元素定位是写爬虫时最耗时的一环。Selenium提供了ID、class、name、tag、CSS、XPath、链接文本等十几种定位方式但爬虫场景最常用的就两个CSS选择器和XPath。CSS选择器写法简洁、执行速度快适合有id或class标准的页面items driver.find_elements(By.CSS_SELECTOR, div.video-item a.title)XPath功能更强大比如“根据文本内容定位元素”这种场景只有XPath能优雅处理# 找到文本为“下一页”的按钮 next_btn driver.find_element(By.XPATH, //button[contains(text(), 下一页)])这里有个实打实的坑XPath的contains函数在匹配文本时中间不要加多余空格。你从开发者工具里“Copy XPath”拿到的表达式经常带上一大串无语的索引比如//div[3]/div[1]/div[2]/span这种表达式一旦页面结构稍有变动就会挂。我的经验是尽量用特征明显的属性id、class、data-*属性来自写定位表达式不要迷信开发者工具复制出来的结果。还有一个高频需求取列表里的每一项。这时候不要在外层循环里每次都find_element效率太低。应该先取到列表容器等价于拿到一个“范围”再在范围内继续定位container driver.find_element(By.CSS_SELECTOR, ul.video-list) items container.find_elements(By.CSS_SELECTOR, li) for item in items: title item.find_element(By.CSS_SELECTOR, span.title).text link item.find_element(By.CSS_SELECTOR, a).get_attribute(href) print(title, link)这种写法比每次都从根节点重新找要快得多代码也清晰很多。3.3 execute_script 解锁页面操作有时候页面里的元素被遮住了或者需要滚动才能触发加载这时候使用常规的click可能会失效。Selenium提供execute_script方法可以在当前页面上下文里直接执行任意JavaScript代码这招在处理动态页面时特别好用。滚动加载就是一个典型场景。很多页面必须滚动到底部才会触发接口请求而Selenium的scroll操作需要先定位到目标元素或指定坐标比较绕。直接执行JS更痛快# 滚动到底部触发“加载更多” driver.execute_script(window.scrollTo(0, document.body.scrollHeight);)再比如点击被遮挡的元素也可以直接用JS强制点击# 有些按钮被悬浮层挡住selenium的click会报ElementClickInterceptedException element driver.find_element(By.CSS_SELECTOR, #load-more-btn) driver.execute_script(arguments[0].click();, element)还有更骚的用法直接在浏览器里跑一小段JS把当前页面里所有video元素的style改了。我在处理一些视频网站时遇到过视频旋转90度的情况用这行代码就能解决var v document.querySelector(video); v.style.rotate -90deg;这在Selenium里就是一行execute_script的事。说白了你在浏览器控制台里能手动执行的任何JS都可以通过execute_script传给页面。execute_script还可以有返回值。比如你想快速拿到页面上所有图片的真实地址不必逐个find_element再get_attribute直接urls driver.execute_script( return Array.from(document.querySelectorAll(img)).map(img img.src); )这种方式比Selenium原生的查找循环快很多特别适合内容丰富的列表页。4. 反爬检测与性能优化几个硬核技巧Selenium最大的缺点是慢一顿操作下来可能要好几秒才能处理一个页面。但配合一些优化手段速度能提高到接近“数据够用”的水平。4.1 浏览器指纹伪装与启动参数很多网站做了自动化检测只要识别到webdriver标记就会拒绝访问。最经典的检测点是window.navigator.webdriver正常浏览器这个值是undefined但Selenium控制的浏览器这个值是true。只靠这个字段不少站点就能认出你是爬虫。最简单的处理方式是在浏览器启动时关闭自动化控制的标志位from selenium.webdriver.chrome.options import Options options Options() options.add_argument(--disable-blink-featuresAutomationControlled) options.add_argument(user-agentMozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36) options.add_experimental_option(excludeSwitches, [enable-automation]) options.add_experimental_option(useAutomationExtension, False)如果上面的参数还不够还可以在页面加载前注入一段JS来覆盖navigator.webdriver属性driver.execute_cdp_cmd(Page.addScriptToEvaluateOnNewDocument, { source: Object.defineProperty(navigator, webdriver, { get: () undefined }); })这段代码要放在driver.get()之前执行。它的原理是在页面任何脚本运行之前先修改navigator.webdriver这个属性的getter让检测代码读到的永远是undefined。实测下来配合启动参数一起用能绕过大部分检测。但也要说一句负责任的话爬虫不是法外之地做技术研究、数据采集的时候先看清楚对方网站的robots协议和用户协议只采集自己有权限访问的数据控制好请求频率别给目标服务器添麻烦。4.2 请求拦截与页面加载策略不知道你有没有遇到过这种情况页面主体内容早就加载完了但有个广告脚本一直在尝试连接第三方服务器导致整个页面一直处于“加载中”状态。Selenium默认会等页面完全加载完才执行下一行代码如果某个资源永远pending你的爬虫就卡死了。这时可以把加载策略改成“只等DOM就绪不等图片和子框架”options.page_load_strategy eager更激进的做法是设置“不等加载完成”然后自己手动控制页面加载完成时间options.page_load_strategy none用none策略时driver.get()会立刻返回页面可能还在后台加载。然后你通过WebDriverWait等待目标元素出现再继续操作。这种方式能省下大量等待时间尤其是目标网站塞了大量第三方统计脚本、广告脚本的时候收益非常明显。另外一个小技巧用Chrome DevTools协议CDP去监听网络请求直接拿接口响应。这在处理“滚动加载”的页面时特别好用——页面滚动到底引擎发出JSON请求我们不去解析DOM而是直接从网络层拿到JSON数据driver.execute_cdp_cmd(Network.enable, {}) # 滚动触发加载 driver.execute_script(window.scrollTo(0, document.body.scrollHeight);) time.sleep(1) # 获取页面加载期间所有资源 resources driver.execute_script( return performance.getEntriesByType(resource).map(r r.name); )拿到资源URL列表后过滤出包含api或者json字段的地址那就是数据接口。这个思路比硬啃DOM高效得多尤其当你只需要列表字段齐全的JSON而不是渲染后的HTML时。4.3 无头模式与并发采集的取舍无头浏览器headless就是在没有界面窗口的情况下运行浏览器适合在服务器上跑爬虫任务。Selenium从Chrome 109之后无头模式也支持了完整的新版本特性兼容性比早期好很多。options.add_argument(--headlessnew) options.add_argument(--no-sandbox) options.add_argument(--disable-dev-shm-usage)但要处理好两个问题。第一很多网站的反爬机制对无头模式的识别度更高因为正常用户不会在没有任何界面的环境里访问网站。如果遇到验证码或者滑块我的建议是放弃无头模式老老实实开着有头模式跑大不了在本地跑完再上传结果。第二无头模式下有些元素交互不稳定比如悬浮菜单、鼠标悬停后才出现的内容用普通方法可能拿不到。并发这块也容易踩坑。有人图快直接开十个线程各启动一个driver结果内存爆满网站也很快把IP封了。我的个人经验是一台机器同一时间最多跑三到四个driver实例超过这个数收益断崖式下降风险直线上升。更好的做法是复用同一个driver通过切换链接、滚动页面、模拟用户浏览的方式来抓取多个页面而不是每个URL都重新启动一个浏览器。5. 踩坑实录常见问题与排查思路我用Selenium这几年踩过不少坑有些坑光看文档是真想不到。这里挑典型的几个做成一个速查表你遇到问题的时候丢过来直接对号入座。5.1 元素明明在页面上就是定位不到这个问题的出现频率最高但原因通常就那么几个。第一个是iframe嵌套。页面里的内容在一个iframe里Selenium默认只认识外层DOM必须切换进去才能操作driver.switch_to.frame(iframe的id或name) # 操作完之后切回默认页面 driver.switch_to.default_content()第二个是窗口句柄切换。点击链接之后打开了一个新标签页你以为还在原页面操作结果怎么都找不到元素。这时需要先切换到新的窗口handles driver.window_handles driver.switch_to.window(handles[-1])第三个是元素在Shadow DOM内部。普通的find_element无法穿透Shadow DOM需要用execute_script先拿到shadowRoot再在shadowRoot内部继续查找。这个相对冷门但遇到一次能卡一整天。还有种情况是元素本身就是动态生成的页面滚动到某个位置才渲染出来。这时候先滚动再定位别一上来就啪啪啪find_element。5.2 页面一直转圈脚本卡死不退出页面加载超时或某个请求一直pending是Selenium爬虫最常见的卡死原因。解决办法有两个方向。第一设置超时时间driver.set_page_load_timeout(15)第二用“尝试捕获异常并继续”的方式兜底try: driver.get(url) except Exception: # 超时会抛异常但页面可能已加载出部分内容 pass这样即使加载超时代码也不会卡死后续通过WebDriverWait等目标元素出现再判断是否需要重试。还要养成一个好习惯driver.quit()一定要放进finally块里不然脚本崩了浏览器进程还留在内存里下次启动时就会互相打架。5.3 数据拿到了但跑得比requests慢一个数量级这是Selenium方案的宿命。开一个浏览器再加载一个页面再等JS执行怎么看都比直接发HTTP请求慢。如果抓取量很大我建议分两步走先用浏览器把页面上的数据接口地址找出来然后改成直接用requests请求这些接口最后再用Selenium处理那些必须渲染才能拿到的部分。另外解析数据时别用Selenium的text属性一条条取可以直接拿driver.page_source转成字符串然后交给lxml或BeautifulSoup去解析。Selenium的定位查找性能远不如lxml的XPath解析因为后者是纯C实现快得多。这个优化我在一个列表页项目上实测过页面解析时间直接从3秒降到了0.3秒左右效果立竿见影。下面是我经常用的一个简化后的等待与解析组合模板你可以直接套用from selenium import webdriver from selenium.webdriver.common.by import By from selenium.webdriver.support.ui import WebDriverWait from selenium.webdriver.support import expected_conditions as EC from lxml import html driver webdriver.Chrome() driver.get(https://example.com/list) # 等待内容渲染完成 WebDriverWait(driver, 10).until( EC.presence_of_element_located((By.CSS_SELECTOR, div.item)) ) # 一次性拿整个页面渲染后的HTML交给lxml解析 doc html.fromstring(driver.page_source) titles doc.xpath(//div[contains(class, item)]//h2/text())5.4 常见问题速查表问题现象常见原因解决方案找不到元素元素在iframe内driver.switch_to.frame()切换找不到元素元素在新窗口driver.switch_to.window()切换找不到元素页面未加载完成改用WebDriverWait显式等待点击按钮报错元素被遮挡execute_script强制点击页面卡住不动广告脚本一直pending设置page_load_strategyeager或none数据有但抓不全懒加载未触发先滚动页面触发加载启动浏览器报错驱动版本与浏览器不匹配用webdriver-manager自动匹配被人识别为爬虫navigator.webdriver为true启动参数CDP注入JS覆盖属性最后分享一个小技巧我实际用Selenium时最省时间的改进不是换了更快的解析库也不是加了并发而是把等待策略彻底调明白了。以前我总会写很多time.sleep生怕页面没加载完后来全部改成WebDriverWait配合expected_conditions脚本整体速度提升很明显也没有原来那么容易出错了。另一个建议是任务开始前先用一小段代码把目标页面的“最低等待时间”跑出来。跑个五六次统计一下从打开页面到目标元素出现的平均耗时然后在这个时间的基础上乘1.5倍作为你的超时上限。这个办法没有理论依据但我用了两年多实测非常稳。Selenium这套方案长远来看不算最优解碰到复杂的加密参数或极致的性能要求还是要考虑抓接口、逆向JS甚至换Playwright。但作为处理JS渲染页面最通用、最容易上手的方案它绝对值得你花一周时间吃透。等你能熟练驾驭浏览器自动化之后再回头处理动态页面会发现爬虫世界突然又开阔了一大截。