做了几年爬虫开发我越来越觉得高级爬虫技巧里最容易被低估的一项就是处理JavaScript渲染页面。很多刚入门的朋友习惯用 requests 一把梭正则、XPath 都写好了结果换到一个前后端分离的站点HTML 源码里干干净净数据全得靠浏览器现场执行脚本才能出现。这时候懂不懂Selenium就成了能不能继续往下走的分水岭。这篇文章我不打算讲那些花里胡哨的框架就围绕 Selenium 这一个老牌工具把 JavaScript 渲染页面的处理思路、底层原理、完整实操和避坑经验一次说透。不管你是刚接触爬虫的新手还是已经被动态页面折磨过一阵子的开发者按这篇的思路去走应该能少踩七八成的坑。1. 为什么JavaScript渲染是爬虫路上的一堵墙1.1 浏览器里看到的数据HTML源码里却没有你打开一个页面看到商品列表、价格、评论、翻页数据都整整齐齐地显示在浏览器里。但如果你右键查看网页源代码会发现那堆 HTML 里只有空壳的div、script标签和一些初始化的配置项。数据在哪根本不在原始响应里。这是因为现在的 Web 开发早就从“服务端渲染”转向了“客户端渲染”。后端提供的只是一个静态骨架和一堆 JavaScript 脚本浏览器拿到这些脚本后再去请求若干个接口拿到 JSON 数据然后把数据动态地插入页面 DOM 里。这个过程发生在浏览器内部requests 这种只发 HTTP 请求的库自然拿不到渲染后的结果。这种情况在 Vue、React、Angular 这类框架的站点上特别常见。我处理过的某数据平台、某电商活动页几乎全都是这种模式。你直接抓接口有时候能拿到一部分数据但遇到参数加密、接口鉴权、数据结构不稳定的情况还不如老老实实模拟浏览器渲染。1.2 处理动态渲染的3条主流路线面对这种页面行业内通常有三条路线直接分析接口绕过渲染。用抓包工具看浏览器发了哪些 XHR 请求找到真正的数据接口直接调。这条路效率最高、性能最好也是我最推荐优先尝试的。使用无头浏览器自动化工具。代表就是 Selenium、Playwright、Puppeteer。让真实的浏览器引擎去加载页面、执行 JS、渲染 DOM脚本等数据出现后再抓取。这条路稳定、通用适合接口分析困难、有复杂交互的场景。使用渲染代理服务。把 URL 丢给云端渲染服务服务端用浏览器渲染完再返回 HTML。适合临时救急但一般要收费而且数据实时性不如自己本地控制。三条路线各有优劣我通常的建议是能走第一条绝不走第二条第二条主要用于破解“非走浏览器不可”的场景。1.3 Selenium适合哪些场景又不适合哪些场景Selenium 本质上是浏览器自动化测试工具后来被爬虫圈大量借用。它最大的优点是“所见即所得”你在浏览器里能做的操作它都能模拟而且不用关心目标页面到底用了什么前端框架。登录态、cookie、iframe、弹窗、滚动加载这些场景它天然就支持。但它也有明显的短板速度慢、资源占用高。每创建一个浏览器实例内存轻轻松松几百 MB。你要是拿它去抓几千万条纯列表数据别想了性能和成本都扛不住。所以我在项目里通常把它定位成“攻坚型工具”——页面交互复杂、接口拿不到、又必须要数据的时候用它顶上平时优先用接口方案。2. 搞懂Selenium的工作原理才能用得心里有底2.1 WebDriver协议自动化脚本和浏览器之间的翻译官先说一个很多人忽略的点Selenium 本身并不直接操作浏览器它是通过 WebDriver 协议来驱动的。你把脚本交给 SeleniumSelenium 把操作翻译成标准化的 HTTP 指令发给浏览器自带的驱动组件比如 ChromeDriver驱动组件再把这些指令转换成浏览器内部的原生操作。也就是说整个链路是你的 Python 代码 - Selenium 客户端 - WebDriver 协议指令 - 浏览器驱动 - 浏览器内核。这跟 requests 直接发 HTTP 请求是完全两码事。理解这一点很重要因为你会发现很多“奇怪的问题”都出在这一层通信上驱动版本不对浏览器压根打不开页面加载慢等待超时元素还没渲染出来指令就发下去了。WebDriver 协议最初是各个浏览器自己定义的后来统一成了 W3C 标准。所以现在用 Selenium 4 操作 Chrome、Firefox、EdgeAPI 基本上是一致的你只需要换不同的驱动组件就行。2.2 环境搭建容易被坑的3个细节Selenium 的安装本身不复杂pip install selenium就搞定了。真正容易出问题的是驱动。第一个坑是版本匹配。Chrome 和 ChromeDriver 的版本必须大版本号一致否则会报session not created或者压根连不上。我自己的习惯是先在浏览器地址栏输入chrome://version看版本号然后去对应的驱动下载页下载同版本驱动。Selenium 4.6 之后的版本有 Selenium Manager会自动帮你处理驱动下载和匹配省了很大功夫但还是建议手动确认一下。第二个坑是 PATH 环境变量。如果驱动没有放进系统 PATHSelenium 会直接报WebDriverException: chromedriver executable needs to be in PATH。最简单的办法是把驱动放到 Python 解释器同一个目录或者在初始化时用serviceService(/绝对/path/to/chromedriver)显式指定路径。第三个坑是浏览器沙箱权限。在 Linux 服务器上跑 Selenium经常遇到以 root 身份运行时需要加参数--no-sandbox的情况。这属于老生常谈但每次换环境都会碰到索性在这里提一嘴。2.3 初始化Driver时的推荐参数配置这里直接给一份我在项目中常用的初始化模板省得你从零摸索from selenium import webdriver from selenium.webdriver.chrome.service import Service options webdriver.ChromeOptions() # 无头模式不弹出浏览器窗口适合部署在服务器上 options.add_argument(--headlessnew) # 屏蔽“正在被自动化软件控制”的提示条 options.add_argument(--disable-blink-featuresAutomationControlled) # 去掉自动化相关标记 options.add_argument(--disable-infobars) # 指定窗口大小避免某些响应式布局把元素隐藏掉 options.add_argument(--window-size1920,1080) # 禁用 GPU服务器上一般没有独立显卡不加容易报错 options.add_argument(--disable-gpu) # 关闭沙箱容器环境里不生效 options.add_argument(--no-sandbox) # 禁用 /dev/shm 使用防止 Docker 容器里内存不够 options.add_argument(--disable-dev-shm-usage) # 自定义 User-Agent降低部分网站默认检测风险 options.add_argument(user-agentMozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 Chrome/120.0.0.0 Safari/537.36) service Service(/path/to/chromedriver) driver webdriver.Chrome(serviceservice, optionsoptions)这些参数不是凭空堆上去的每一个背后都有真实踩坑经历。比如不设置窗口大小有些页面默认手机视口元素布局完全不一样定位就全乱了不屏蔽自动化提示条截图的时候也会看到黄条。你在自己的环境里不一定全都要但先照抄一份出问题概率会小很多。3. 实战用Selenium啃下一个JavaScript渲染页面的完整流程3.1 等待策略让页面把数据“吐”出来再动手刚开始用 Selenium 的人最容易犯的一个错就是打开页面后立刻找元素然后报NoSuchElementException。为什么找不到因为页面渲染是异步的JS 还没跑完数据还没插进 DOM你的代码就已经去找了。解决这个问题的核心是“等待”而且要用对等待方式。常见的有三种强制等待time.sleep(5)。简单粗暴但时间短了不稳定时间长了浪费效率而且页面网络波动时特别容易打脸。隐式等待driver.implicitly_wait(10)。告诉浏览器在查找每个元素时最多等 10 秒。问题是它也等待页面加载完成而对 Ajax 动态插入的元素不一定有效。显式等待WebDriverWaitexpected_conditions。专门等某个条件成立比如某个元素可见、存在、可点击精确又高效。我个人的建议是主用显式等待放弃隐式等待。举个真实例子某信息查询类站点的搜索结果是通过 JS 异步刷新出来的用隐式等待经常 5 秒就报错改成显式等待后稳定了很多。from selenium.webdriver.support.ui import WebDriverWait from selenium.webdriver.support import expected_conditions as EC from selenium.webdriver.common.by import By # 等待某个 id 为 result_list 的元素变得可见 wait WebDriverWait(driver, 10) element wait.until( EC.visibility_of_element_located((By.ID, result_list)) )这里我特别想说明presence_of_element_located和visibility_of_element_located的差别。前者只要求元素存在于 DOM 里哪怕还藏在页面底部或者display: none状态后者要求元素真正可见。如果你后续要点击元素最好用element_to_be_clickable否则可能元素存在了但按钮还不可点依然会报错。这个细节是区分新手和老手的一个标志。3.2 元素定位的取舍从快准狠到兜底方案页面渲染出来后下一步是定位元素。Selenium 提供多种定位方式By.ID、By.CLASS_NAME、By.CSS_SELECTOR、By.XPATH、By.NAME等。性能和使用偏好差别很大。我的优先级习惯是ID 优先CSS 选择器次之XPath 兜底。ID 是页面里唯一标识定位最快最稳CSS 选择器语法简洁阅读性好适合按层级关系找XPath 功能最强能支持各种复杂逻辑比如“包含某个字符串”“找父节点后的兄弟节点”但性能和可读性一般。举个例子你要抓取列表里所有商品标题每个标题的 class 都叫list-title但外层容器不同。用 CSS 可以这样elements driver.find_elements(By.CSS_SELECTOR, div.goods-list a.item-title)如果目标这个 class 是动态生成的比如item-title-28173这种每次刷新都变的后缀CSS 就不好使了。这时候 XPath 的contains就派上了用场elements driver.find_elements(By.XPATH, //a[contains(class, item-title)])还有种情况也经常遇到同一个class名在页面里出现几十次但父节点不同。你可以通过 XPath 的following、preceding、ancestor等轴来精确定位不过这种写法复杂建议先用浏览器开发者工具里的“Copy XPath/Copy Selector”生成一份再改比自己凭空写快得多。3.3 高频交互场景iframe、弹窗、下拉加载处理 JavaScript 渲染页面你不光要“看”还要“操作”否则好多页面根本不会加载后续数据。先说 iframe。有些第三方组件比如登录框、支付面板、客服系统是通过 iframe 嵌入的里面的元素在 Selenium 里直接定位会报找不到元素。原因很简单DOM 树里 iframe 是独立文档你要先切换进去driver.switch_to.frame(driver.find_element(By.CSS_SELECTOR, iframe[src*login])) # 操作 iframe 内部元素 driver.find_element(By.ID, username).send_keys(xxx) # 操作完切回主文档 driver.switch_to.default_content()注意switch_to.frame之后所有定位都只针对 iframe 内部文档除非你切回主文档否则很容易遇到“明明在页面里看得见却找不到”的诡局。再说弹窗。很多页面会弹出遮罩广告、引导浮层直接挡住目标元素导致无法点击。常规做法是用 JavaScript 强制点击或者等弹窗消失。如果是原生的alert弹窗Selenium 里这样处理alert driver.switch_to.alert print(alert.text) alert.accept() # 确定 # alert.dismiss() # 取消下拉加载更常见。这类页面初始只给 20 条数据你滚动到页面底部它才去请求下一页数据。实现方式通常是执行 JS 滚动driver.execute_script(window.scrollTo(0, document.body.scrollHeight);) # 等待数据加载 wait.until(EC.presence_of_element_located((By.CSS_SELECTOR, div.list-item)))如果页面不是整页滚动而是某个容器内部滚动就要把滚动目标从document.body换成对应容器元素。这个细节不重但实际项目里十个有八个是卡在这。3.4 登录态保持手动登录一次后面全自动很多动态页面的数据接口需要登录后才能请求。Selenium 处理登录的方式比 requests 舒服得多你手动打开浏览器自己输入账号密码遇到验证码也能手动过登录成功后再把 cookie 存下来后面程序启动时直接注入 cookie不用每次都走登录流程。import json # 第一次手动登录后保存 cookies cookies driver.get_cookies() with open(cookies.json, w) as f: json.dump(cookies, f) # 下次启动时加载 cookies driver.get(https://example.com/login) # 先访问首页建立会话 for cookie in cookies: driver.add_cookie(cookie) driver.refresh()这里有个常见的坑add_cookie之前必须先访问一次目标域名的主页否则浏览器不知道该 cookie 属于哪个域名。另外 cookie 里如果有expiry字段直接传给add_cookie有时会报错读取时最好过滤掉。如果能拿到登录态的 cookie你甚至可以把它导出给 requests 使用这样既能有登录权限又能走接口方案抓数据速度和稳定性都比纯 Selenium 好不少。cookie 导出成字典格式放进 requests 的headers或直接作为cookies参数传入即可。4. 我踩过的坑常见问题与排查清单4.1 元素明明存在却一直报NoSuchElementException这是我被问得最多的问题省流版排查顺序是否在 iframe 里先switch_to.frame再定位。是否在 shadow DOM 里部分前端组件会用 shadow DOM 封装内部结构普通定位找不到。需要先拿到 shadow host再用 JS 穿透。是否在窗口外面元素可能在页面底部需要先滚动到可视区域。是否有多个同名 classfind_element只返回第一个可能第一个是隐藏的真正的元素在后面改成find_elements取索引。是否页面还在加载等待时间不够换成显式等待至少等 10 秒。是否在新标签页点击链接后会开新页旧页面里当然找不到。需要driver.switch_to.window(driver.window_handles[-1])。浏览器是否弹出了异常页面先看driver.current_url和driver.page_source要么被验证拦截要么跳到了 404。排查时最有用的命令是print(driver.page_source) # 把当前页面 HTML 打出来分析 print(driver.current_url) # 看看页面是不是已经跳走别嫌麻烦这些命令能解决九成以上的“找不到元素”。4.2 Selenium特征被识别怎么办有些网站会检测当前浏览器是否被自动化工具控制。如果你发现页面能正常打开但数据一直加载不出来或者直接被弹验证码可能就是特征暴露了。Selenium 常见的特征有navigator.webdriver属性为true、浏览器窗口里有“Chrome 正在受到自动测试软件的控制”提示条、一些特定 API 被替换等。前面初始化代码里我加的--disable-blink-featuresAutomationControlled就是针对其中一个特征做的处理。更稳妥的办法是用专门的驱动分支版本社区里有针对自动化检测做过改写的工具能隐藏大部分特征。另外设置一个正常的 User-Agent、Window-size、语言环境也能降低异常概率。不过这里我想多说一句学这些技术是为了处理合规的数据采集需求不是鼓励突破别人的安全防线。在实际项目里最好先确认目标网站的服务协议允许自动化采集不要对在线业务系统做超出必要范围的请求。技术能力用在对的方向才能真正创造价值。4.3 运行越来越慢怎么优化Selenium 慢是通病但很多“慢”是自己写的代码造成的。我优化过的几个方向效果都挺明显减少无谓等待把time.sleep全部替换成显式等待能省一半时间。关了不必要的动画、图片加载在 Chrome options 里禁用图片通过--blink-settingsimagesEnabledfalse参数数据抓取完全不受影响。尽量用接口请求替代页面渲染能用 requests 直接拿的数据就不要开浏览器。复用浏览器实例不要每个 URL 都新建一个driver长时间批量采集时保持一个实例反复get()效率远高于频繁启动销毁。及时清理无用元素如果页面 DOM 越来越大操作越来越卡可以考虑定期刷新页面而不是在同一个页面里无限滚动。性能优化的终极原则是Selenium 只解决“必须用浏览器”的那部分其他事情都交给 requests 和接口。4.4 高频异常速查表最后整理一份速查表方便你遇到问题时快速对照。这些错误信息是我在实际项目中高频遇到的每一项后面都给出了可直接操作的解决路径。异常信息可能原因解决思路session not createdChromeDriver 与浏览器版本不匹配下载同版本驱动或升级 Selenium 使用 Selenium ManagerWebDriverException: chrome not reachable浏览器崩溃、路径错误或权限不足检查浏览器安装路径确认无头模式参数必要时加--no-sandboxNoSuchElementException元素未渲染、在 iframe/shadow DOM 中、等待不足按 4.1 的七步排查依次确认StaleElementReferenceException页面结构变化之前拿到的元素引用已失效重新定位元素不要复用旧引用ElementClickInterceptedException元素被遮罩、弹窗挡住先关闭弹窗或 JS 强制点击driver.execute_script(arguments[0].click(), element)TimeoutException等待条件未满足页面加载过慢适当调长超时时间同时检查网络和代理设置InvalidCookieDomainExceptioncookie 域名与当前页面不匹配先访问目标站点再加对应 cookieMessage: no such element: Unable to locate element定位表达式写错或页面是动态渲染先用 page_source 确认元素真实存在再修正定位方式这张表不建议背建议收藏等踩到对应坑的时候回来对照。4.5 长期项目中的取舍经验这篇文章写到这核心内容基本都讲透了。最后再分享一点我在长期项目里的体会。用 Selenium 处理 JavaScript 渲染最大的价值不是“能爬到数据”而是“能帮你确认数据到底从哪里来”。很多情况下我开一次 Selenium看着它加载页面、发请求、渲染数据配合抓包工具看看它到底请求了哪些接口、带了哪些参数然后就把 Selenium 关了改用 requests 直接调接口。Selenium 在这里更像是侦察兵而不是主力部队。如果你真的需要长期跑 Selenium 采集一定要在脚本里加上异常重试、日志记录和资源清理逻辑。driver.quit()一定要用不然后台留一堆僵尸进程内存迟早被吃光。日志方面至少记录每次请求的 URL、状态、耗时方便定位问题。处理 JavaScript 渲染这条路工具会一直变今天流行 Selenium明天可能就换 Playwright 了但底层的思路是不变的先搞清楚数据从哪来再决定用哪一层工具去拿。把这一点想通了不管你以后换什么工具都不会慌。 
长河君 · 2026/10/22 23:46:05 · 阅读 1.2k Selenium实战：从零破解JavaScript渲染页面的爬虫核心思路
做了几年爬虫开发我越来越觉得高级爬虫技巧里最容易被低估的一项就是处理JavaScript渲染页面。很多刚入门的朋友习惯用 requests 一把梭正则、XPath 都写好了结果换到一个前后端分离的站点HTML 源码里干干净净数据全得靠浏览器现场执行脚本才能出现。这时候懂不懂Selenium就成了能不能继续往下走的分水岭。这篇文章我不打算讲那些花里胡哨的框架就围绕 Selenium 这一个老牌工具把 JavaScript 渲染页面的处理思路、底层原理、完整实操和避坑经验一次说透。不管你是刚接触爬虫的新手还是已经被动态页面折磨过一阵子的开发者按这篇的思路去走应该能少踩七八成的坑。1. 为什么JavaScript渲染是爬虫路上的一堵墙1.1 浏览器里看到的数据HTML源码里却没有你打开一个页面看到商品列表、价格、评论、翻页数据都整整齐齐地显示在浏览器里。但如果你右键查看网页源代码会发现那堆 HTML 里只有空壳的div、script标签和一些初始化的配置项。数据在哪根本不在原始响应里。这是因为现在的 Web 开发早就从“服务端渲染”转向了“客户端渲染”。后端提供的只是一个静态骨架和一堆 JavaScript 脚本浏览器拿到这些脚本后再去请求若干个接口拿到 JSON 数据然后把数据动态地插入页面 DOM 里。这个过程发生在浏览器内部requests 这种只发 HTTP 请求的库自然拿不到渲染后的结果。这种情况在 Vue、React、Angular 这类框架的站点上特别常见。我处理过的某数据平台、某电商活动页几乎全都是这种模式。你直接抓接口有时候能拿到一部分数据但遇到参数加密、接口鉴权、数据结构不稳定的情况还不如老老实实模拟浏览器渲染。1.2 处理动态渲染的3条主流路线面对这种页面行业内通常有三条路线直接分析接口绕过渲染。用抓包工具看浏览器发了哪些 XHR 请求找到真正的数据接口直接调。这条路效率最高、性能最好也是我最推荐优先尝试的。使用无头浏览器自动化工具。代表就是 Selenium、Playwright、Puppeteer。让真实的浏览器引擎去加载页面、执行 JS、渲染 DOM脚本等数据出现后再抓取。这条路稳定、通用适合接口分析困难、有复杂交互的场景。使用渲染代理服务。把 URL 丢给云端渲染服务服务端用浏览器渲染完再返回 HTML。适合临时救急但一般要收费而且数据实时性不如自己本地控制。三条路线各有优劣我通常的建议是能走第一条绝不走第二条第二条主要用于破解“非走浏览器不可”的场景。1.3 Selenium适合哪些场景又不适合哪些场景Selenium 本质上是浏览器自动化测试工具后来被爬虫圈大量借用。它最大的优点是“所见即所得”你在浏览器里能做的操作它都能模拟而且不用关心目标页面到底用了什么前端框架。登录态、cookie、iframe、弹窗、滚动加载这些场景它天然就支持。但它也有明显的短板速度慢、资源占用高。每创建一个浏览器实例内存轻轻松松几百 MB。你要是拿它去抓几千万条纯列表数据别想了性能和成本都扛不住。所以我在项目里通常把它定位成“攻坚型工具”——页面交互复杂、接口拿不到、又必须要数据的时候用它顶上平时优先用接口方案。2. 搞懂Selenium的工作原理才能用得心里有底2.1 WebDriver协议自动化脚本和浏览器之间的翻译官先说一个很多人忽略的点Selenium 本身并不直接操作浏览器它是通过 WebDriver 协议来驱动的。你把脚本交给 SeleniumSelenium 把操作翻译成标准化的 HTTP 指令发给浏览器自带的驱动组件比如 ChromeDriver驱动组件再把这些指令转换成浏览器内部的原生操作。也就是说整个链路是你的 Python 代码 - Selenium 客户端 - WebDriver 协议指令 - 浏览器驱动 - 浏览器内核。这跟 requests 直接发 HTTP 请求是完全两码事。理解这一点很重要因为你会发现很多“奇怪的问题”都出在这一层通信上驱动版本不对浏览器压根打不开页面加载慢等待超时元素还没渲染出来指令就发下去了。WebDriver 协议最初是各个浏览器自己定义的后来统一成了 W3C 标准。所以现在用 Selenium 4 操作 Chrome、Firefox、EdgeAPI 基本上是一致的你只需要换不同的驱动组件就行。2.2 环境搭建容易被坑的3个细节Selenium 的安装本身不复杂pip install selenium就搞定了。真正容易出问题的是驱动。第一个坑是版本匹配。Chrome 和 ChromeDriver 的版本必须大版本号一致否则会报session not created或者压根连不上。我自己的习惯是先在浏览器地址栏输入chrome://version看版本号然后去对应的驱动下载页下载同版本驱动。Selenium 4.6 之后的版本有 Selenium Manager会自动帮你处理驱动下载和匹配省了很大功夫但还是建议手动确认一下。第二个坑是 PATH 环境变量。如果驱动没有放进系统 PATHSelenium 会直接报WebDriverException: chromedriver executable needs to be in PATH。最简单的办法是把驱动放到 Python 解释器同一个目录或者在初始化时用serviceService(/绝对/path/to/chromedriver)显式指定路径。第三个坑是浏览器沙箱权限。在 Linux 服务器上跑 Selenium经常遇到以 root 身份运行时需要加参数--no-sandbox的情况。这属于老生常谈但每次换环境都会碰到索性在这里提一嘴。2.3 初始化Driver时的推荐参数配置这里直接给一份我在项目中常用的初始化模板省得你从零摸索from selenium import webdriver from selenium.webdriver.chrome.service import Service options webdriver.ChromeOptions() # 无头模式不弹出浏览器窗口适合部署在服务器上 options.add_argument(--headlessnew) # 屏蔽“正在被自动化软件控制”的提示条 options.add_argument(--disable-blink-featuresAutomationControlled) # 去掉自动化相关标记 options.add_argument(--disable-infobars) # 指定窗口大小避免某些响应式布局把元素隐藏掉 options.add_argument(--window-size1920,1080) # 禁用 GPU服务器上一般没有独立显卡不加容易报错 options.add_argument(--disable-gpu) # 关闭沙箱容器环境里不生效 options.add_argument(--no-sandbox) # 禁用 /dev/shm 使用防止 Docker 容器里内存不够 options.add_argument(--disable-dev-shm-usage) # 自定义 User-Agent降低部分网站默认检测风险 options.add_argument(user-agentMozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 Chrome/120.0.0.0 Safari/537.36) service Service(/path/to/chromedriver) driver webdriver.Chrome(serviceservice, optionsoptions)这些参数不是凭空堆上去的每一个背后都有真实踩坑经历。比如不设置窗口大小有些页面默认手机视口元素布局完全不一样定位就全乱了不屏蔽自动化提示条截图的时候也会看到黄条。你在自己的环境里不一定全都要但先照抄一份出问题概率会小很多。3. 实战用Selenium啃下一个JavaScript渲染页面的完整流程3.1 等待策略让页面把数据“吐”出来再动手刚开始用 Selenium 的人最容易犯的一个错就是打开页面后立刻找元素然后报NoSuchElementException。为什么找不到因为页面渲染是异步的JS 还没跑完数据还没插进 DOM你的代码就已经去找了。解决这个问题的核心是“等待”而且要用对等待方式。常见的有三种强制等待time.sleep(5)。简单粗暴但时间短了不稳定时间长了浪费效率而且页面网络波动时特别容易打脸。隐式等待driver.implicitly_wait(10)。告诉浏览器在查找每个元素时最多等 10 秒。问题是它也等待页面加载完成而对 Ajax 动态插入的元素不一定有效。显式等待WebDriverWaitexpected_conditions。专门等某个条件成立比如某个元素可见、存在、可点击精确又高效。我个人的建议是主用显式等待放弃隐式等待。举个真实例子某信息查询类站点的搜索结果是通过 JS 异步刷新出来的用隐式等待经常 5 秒就报错改成显式等待后稳定了很多。from selenium.webdriver.support.ui import WebDriverWait from selenium.webdriver.support import expected_conditions as EC from selenium.webdriver.common.by import By # 等待某个 id 为 result_list 的元素变得可见 wait WebDriverWait(driver, 10) element wait.until( EC.visibility_of_element_located((By.ID, result_list)) )这里我特别想说明presence_of_element_located和visibility_of_element_located的差别。前者只要求元素存在于 DOM 里哪怕还藏在页面底部或者display: none状态后者要求元素真正可见。如果你后续要点击元素最好用element_to_be_clickable否则可能元素存在了但按钮还不可点依然会报错。这个细节是区分新手和老手的一个标志。3.2 元素定位的取舍从快准狠到兜底方案页面渲染出来后下一步是定位元素。Selenium 提供多种定位方式By.ID、By.CLASS_NAME、By.CSS_SELECTOR、By.XPATH、By.NAME等。性能和使用偏好差别很大。我的优先级习惯是ID 优先CSS 选择器次之XPath 兜底。ID 是页面里唯一标识定位最快最稳CSS 选择器语法简洁阅读性好适合按层级关系找XPath 功能最强能支持各种复杂逻辑比如“包含某个字符串”“找父节点后的兄弟节点”但性能和可读性一般。举个例子你要抓取列表里所有商品标题每个标题的 class 都叫list-title但外层容器不同。用 CSS 可以这样elements driver.find_elements(By.CSS_SELECTOR, div.goods-list a.item-title)如果目标这个 class 是动态生成的比如item-title-28173这种每次刷新都变的后缀CSS 就不好使了。这时候 XPath 的contains就派上了用场elements driver.find_elements(By.XPATH, //a[contains(class, item-title)])还有种情况也经常遇到同一个class名在页面里出现几十次但父节点不同。你可以通过 XPath 的following、preceding、ancestor等轴来精确定位不过这种写法复杂建议先用浏览器开发者工具里的“Copy XPath/Copy Selector”生成一份再改比自己凭空写快得多。3.3 高频交互场景iframe、弹窗、下拉加载处理 JavaScript 渲染页面你不光要“看”还要“操作”否则好多页面根本不会加载后续数据。先说 iframe。有些第三方组件比如登录框、支付面板、客服系统是通过 iframe 嵌入的里面的元素在 Selenium 里直接定位会报找不到元素。原因很简单DOM 树里 iframe 是独立文档你要先切换进去driver.switch_to.frame(driver.find_element(By.CSS_SELECTOR, iframe[src*login])) # 操作 iframe 内部元素 driver.find_element(By.ID, username).send_keys(xxx) # 操作完切回主文档 driver.switch_to.default_content()注意switch_to.frame之后所有定位都只针对 iframe 内部文档除非你切回主文档否则很容易遇到“明明在页面里看得见却找不到”的诡局。再说弹窗。很多页面会弹出遮罩广告、引导浮层直接挡住目标元素导致无法点击。常规做法是用 JavaScript 强制点击或者等弹窗消失。如果是原生的alert弹窗Selenium 里这样处理alert driver.switch_to.alert print(alert.text) alert.accept() # 确定 # alert.dismiss() # 取消下拉加载更常见。这类页面初始只给 20 条数据你滚动到页面底部它才去请求下一页数据。实现方式通常是执行 JS 滚动driver.execute_script(window.scrollTo(0, document.body.scrollHeight);) # 等待数据加载 wait.until(EC.presence_of_element_located((By.CSS_SELECTOR, div.list-item)))如果页面不是整页滚动而是某个容器内部滚动就要把滚动目标从document.body换成对应容器元素。这个细节不重但实际项目里十个有八个是卡在这。3.4 登录态保持手动登录一次后面全自动很多动态页面的数据接口需要登录后才能请求。Selenium 处理登录的方式比 requests 舒服得多你手动打开浏览器自己输入账号密码遇到验证码也能手动过登录成功后再把 cookie 存下来后面程序启动时直接注入 cookie不用每次都走登录流程。import json # 第一次手动登录后保存 cookies cookies driver.get_cookies() with open(cookies.json, w) as f: json.dump(cookies, f) # 下次启动时加载 cookies driver.get(https://example.com/login) # 先访问首页建立会话 for cookie in cookies: driver.add_cookie(cookie) driver.refresh()这里有个常见的坑add_cookie之前必须先访问一次目标域名的主页否则浏览器不知道该 cookie 属于哪个域名。另外 cookie 里如果有expiry字段直接传给add_cookie有时会报错读取时最好过滤掉。如果能拿到登录态的 cookie你甚至可以把它导出给 requests 使用这样既能有登录权限又能走接口方案抓数据速度和稳定性都比纯 Selenium 好不少。cookie 导出成字典格式放进 requests 的headers或直接作为cookies参数传入即可。4. 我踩过的坑常见问题与排查清单4.1 元素明明存在却一直报NoSuchElementException这是我被问得最多的问题省流版排查顺序是否在 iframe 里先switch_to.frame再定位。是否在 shadow DOM 里部分前端组件会用 shadow DOM 封装内部结构普通定位找不到。需要先拿到 shadow host再用 JS 穿透。是否在窗口外面元素可能在页面底部需要先滚动到可视区域。是否有多个同名 classfind_element只返回第一个可能第一个是隐藏的真正的元素在后面改成find_elements取索引。是否页面还在加载等待时间不够换成显式等待至少等 10 秒。是否在新标签页点击链接后会开新页旧页面里当然找不到。需要driver.switch_to.window(driver.window_handles[-1])。浏览器是否弹出了异常页面先看driver.current_url和driver.page_source要么被验证拦截要么跳到了 404。排查时最有用的命令是print(driver.page_source) # 把当前页面 HTML 打出来分析 print(driver.current_url) # 看看页面是不是已经跳走别嫌麻烦这些命令能解决九成以上的“找不到元素”。4.2 Selenium特征被识别怎么办有些网站会检测当前浏览器是否被自动化工具控制。如果你发现页面能正常打开但数据一直加载不出来或者直接被弹验证码可能就是特征暴露了。Selenium 常见的特征有navigator.webdriver属性为true、浏览器窗口里有“Chrome 正在受到自动测试软件的控制”提示条、一些特定 API 被替换等。前面初始化代码里我加的--disable-blink-featuresAutomationControlled就是针对其中一个特征做的处理。更稳妥的办法是用专门的驱动分支版本社区里有针对自动化检测做过改写的工具能隐藏大部分特征。另外设置一个正常的 User-Agent、Window-size、语言环境也能降低异常概率。不过这里我想多说一句学这些技术是为了处理合规的数据采集需求不是鼓励突破别人的安全防线。在实际项目里最好先确认目标网站的服务协议允许自动化采集不要对在线业务系统做超出必要范围的请求。技术能力用在对的方向才能真正创造价值。4.3 运行越来越慢怎么优化Selenium 慢是通病但很多“慢”是自己写的代码造成的。我优化过的几个方向效果都挺明显减少无谓等待把time.sleep全部替换成显式等待能省一半时间。关了不必要的动画、图片加载在 Chrome options 里禁用图片通过--blink-settingsimagesEnabledfalse参数数据抓取完全不受影响。尽量用接口请求替代页面渲染能用 requests 直接拿的数据就不要开浏览器。复用浏览器实例不要每个 URL 都新建一个driver长时间批量采集时保持一个实例反复get()效率远高于频繁启动销毁。及时清理无用元素如果页面 DOM 越来越大操作越来越卡可以考虑定期刷新页面而不是在同一个页面里无限滚动。性能优化的终极原则是Selenium 只解决“必须用浏览器”的那部分其他事情都交给 requests 和接口。4.4 高频异常速查表最后整理一份速查表方便你遇到问题时快速对照。这些错误信息是我在实际项目中高频遇到的每一项后面都给出了可直接操作的解决路径。异常信息可能原因解决思路session not createdChromeDriver 与浏览器版本不匹配下载同版本驱动或升级 Selenium 使用 Selenium ManagerWebDriverException: chrome not reachable浏览器崩溃、路径错误或权限不足检查浏览器安装路径确认无头模式参数必要时加--no-sandboxNoSuchElementException元素未渲染、在 iframe/shadow DOM 中、等待不足按 4.1 的七步排查依次确认StaleElementReferenceException页面结构变化之前拿到的元素引用已失效重新定位元素不要复用旧引用ElementClickInterceptedException元素被遮罩、弹窗挡住先关闭弹窗或 JS 强制点击driver.execute_script(arguments[0].click(), element)TimeoutException等待条件未满足页面加载过慢适当调长超时时间同时检查网络和代理设置InvalidCookieDomainExceptioncookie 域名与当前页面不匹配先访问目标站点再加对应 cookieMessage: no such element: Unable to locate element定位表达式写错或页面是动态渲染先用 page_source 确认元素真实存在再修正定位方式这张表不建议背建议收藏等踩到对应坑的时候回来对照。4.5 长期项目中的取舍经验这篇文章写到这核心内容基本都讲透了。最后再分享一点我在长期项目里的体会。用 Selenium 处理 JavaScript 渲染最大的价值不是“能爬到数据”而是“能帮你确认数据到底从哪里来”。很多情况下我开一次 Selenium看着它加载页面、发请求、渲染数据配合抓包工具看看它到底请求了哪些接口、带了哪些参数然后就把 Selenium 关了改用 requests 直接调接口。Selenium 在这里更像是侦察兵而不是主力部队。如果你真的需要长期跑 Selenium 采集一定要在脚本里加上异常重试、日志记录和资源清理逻辑。driver.quit()一定要用不然后台留一堆僵尸进程内存迟早被吃光。日志方面至少记录每次请求的 URL、状态、耗时方便定位问题。处理 JavaScript 渲染这条路工具会一直变今天流行 Selenium明天可能就换 Playwright 了但底层的思路是不变的先搞清楚数据从哪来再决定用哪一层工具去拿。把这一点想通了不管你以后换什么工具都不会慌。