1. 为什么你需要Selenium来处理JavaScript渲染做爬虫时间长了你一定会遇到这种情况用requests或httpx把页面抓下来打开一看HTML结构倒是完整可你要的数据却一个都没有全是一堆script标签和空荡荡的div。这时候你会发现真正的内容根本不是服务器直接返回的而是页面加载完以后JavaScript再去调接口、拼DOM、动态渲染出来的。遇到这种页面纯HTTP请求那套玩法就彻底失效了。Selenium能解决这个问题是因为它不是一个简单的请求库而是一个自动化测试框架。它做了一件非常笨但非常好用的事真的去启动一个浏览器让浏览器像真人用户一样打开页面、执行JavaScript、渲染DOM等页面稳定了再把最后的结果给你。这个过程不是模拟而是真实发生的所以JS渲染得再花哨在它面前都跟脱了衣服一样全部暴露在HTML里。这套方案特别适合几类人一类是刚接触爬虫不久、还没学会逆向分析XHR接口的新手可以用Selenium先跑通流程再说另一类是目标页面逻辑极其复杂比如有各种事件绑定、图表渲染、WebSocket推送更新逆向成本远高于自动化成本的场景还有一类是做数据采集但不想花太多精力维护接口逆向方案的工程师Selenium上手快、见效快遇到验证码和风控也有一定对抗空间。当然Selenium不是银弹它慢、资源占用高、容易被检测这些缺点后面我会逐一展开讲。但如果你需要处理JavaScript渲染的页面它依然是目前最稳妥、最低门槛的选择之一。这篇文章我会从环境搭建讲到反检测再讲到实际案例和性能优化把我这几年的实测经验全部写出来。2. 环境准备与基础配置版本匹配是第一道坑2.1 安装Selenium库和浏览器DriverSelenium从4.0版本开始官方推荐使用webdriver-manager来自动管理驱动这比之前手动去找ChromeDriver要省心得多。安装方式很简单pip install selenium webdriver-managerChrome浏览器建议用稳定版因为Beta版和Dev版的CDP协议变化太快今天能用的驱动明天可能就报错了。驱动管理的核心代码长这样from selenium import webdriver from selenium.webdriver.chrome.service import Service from webdriver_manager.chrome import ChromeDriverManager options webdriver.ChromeOptions() service Service(ChromeDriverManager().install()) driver webdriver.Chrome(serviceservice, optionsoptions)这里有个非常关键的点Driver的版本必须和浏览器版本严格匹配。很多人报SessionNotCreatedException十有八九都是版本对不上。ChromeDriver的版本号前三位必须和Chrome浏览器一致比如浏览器是Chrome 120.0.6099.109Driver就得是120.0.6099.xx系列。用webdriver-manager会自动检测当前电脑里的Chrome版本并下载对应驱动但如果是服务器环境有时候会自动装错建议装完以后打印一下driver.capabilities[browserVersion]和driver.capabilities[chrome][chromedriverVersion]做二次确认。2.2 常用启动参数的取舍Selenium启动浏览器时参数的合理配置决定了你后面是省心还是天天踩坑。我平时常用的参数组合如下options.add_argument(--headlessnew) # 无头模式新版Chrome的写法 options.add_argument(--disable-gpu) # 禁用GPU加速防止显存不足报错 options.add_argument(--no-sandbox) # Linux服务器必须加普通Windows可不加 options.add_argument(--disable-dev-shm-usage) # Docker环境必须加 options.add_argument(--window-size1920,1080) # 设置窗口大小很多页面依赖视口大小做适配 options.add_argument(--user-agentMozilla/5.0 ...) # 自定义UA后面反检测会细说 options.add_experimental_option(excludeSwitches, [enable-automation]) # 去掉Chrome的自动化提示条 options.add_experimental_option(useAutomationExtension, False)参数配置的取舍逻辑其实很简单能少了让目标网站感知到自动化痕迹的就去掉能减少资源消耗的尽量加上。--disable-gpu在无头模式下可以减少很多奇怪的渲染问题--window-size一定要设置否则有些懒加载组件会认为你没滚动到那部分区域数据渲染不出来。这里我先埋个伏笔excludeSwitches和useAutomationExtension这两个参数是后面反检测的基础很多人在这块吃过亏。2.3 加载策略什么时候用eager而不是normalChromeDriver支持三种页面加载策略分别是normal、eager和none。默认是normal要等页面所有资源包括图片、样式表全部加载完才返回。但这在爬虫场景里太浪费了一个页面上可能挂了一堆我们不关心的统计脚本和广告图片。options.page_load_strategy eager # 等DOM树加载完就返回不等CSS和图片eager模式下只要HTML解析完、DOM树构建好了就立即返回控制权页面里的异步JS可能还在跑但这并不影响我们后续的操作因为Selenium执行元素查找时如果找不到还会结合等待机制再来处理。这个策略对内部系统、后台管理系统这类页面效果尤其明显实测能减少30%-50%的等待时间。none模式则完全不等待适合自己手动控制加载节奏的场景但对新手来说容易被各种元素找不到的异常折磨不建议一开始就用。3. 定位、等待与交互Selenium的三大核心操作3.1 元素定位策略不是只有XPath很多人用Selenium一上来就是find_element(By.XPATH, //*[idapp]/div[2]/div[1]/div[3]/span)这种写法效率低且脆得一碰就碎。项目后期只要前端改动一个dom节点整条路径就废了。我给团队定的规范是能用ID不用XPath能用CSS Selector不用绝对路径XPathXPath只用来处理复杂兄弟节点和父子关系。from selenium.webdriver.common.by import By # 优先级别从高到低 driver.find_element(By.ID, app) # ID最稳定 driver.find_element(By.CSS_SELECTOR, div.card h3) # CSS选择器简洁 driver.find_element(By.XPATH, //button[contains(text(),确定)]) # 文本匹配 driver.find_element(By.CLASS_NAME, card-title) # 类名注意有些页面类名是动态的 driver.find_element(By.LINK_TEXT, 下一页) # 超链接文本这里特别提醒一点现在很多前端项目尤其是Vue和React写的单页应用类名和DOM结构会带hash后缀比如classcard_bs7x。这种动态类名千万不要写死在代码里要用部分属性匹配driver.find_element(By.CSS_SELECTOR, [class*card_] h3)3.2 隐式等待和显式等待该怎么选这是一个老生常谈但很多人还是搞混的问题。隐式等待是设置一个全局超时时间每次查找元素时如果没找到就继续轮询查找直到超出这个时间。显式等待则是针对某个特定条件进行轮询等待灵活度和精准度都更高。我的建议很简单能用显式等待就不要用隐式等待。隐式等待的问题在于它只处理元素是否存在而实际爬虫场景中元素存在但不可见、不可点击、还没渲染完都是经常出现的情况。我见过很多人设置了隐式等待10秒以后点击一个异步加载出来的按钮还是报错原因就是元素被挂在DOM上但还没绑定事件。正确的打开方式是这样from selenium.webdriver.support.ui import WebDriverWait from selenium.webdriver.support import expected_conditions as EC wait WebDriverWait(driver, 10) button wait.until( EC.element_to_be_clickable((By.CSS_SELECTOR, button.submit)) ) button.click()expected_conditions里常用的还有visibility_of_element_located对可见性敏感、presence_of_element_located只要求存在对display:none的元素会套路、text_to_be_present_in_element等待某个文本出现在元素里。我跟团队里的小朋友说的一句话是隐式等待是你给浏览器的总预算显式等待才是你给每个业务步骤的GPS导航。两者能配合但绝不能替代。3.3 execute_script绕过点击和滚动的万能钥匙Selenium模拟用户操作有些场景点击会被遮挡、会被风控怀疑这时候直接执行JS往往更痛快。比如有些页面在用户滚动到某个区域时才触发数据加载如果用ActionChains去模拟滚动操作繁琐且容易失败直接一句JS搞定driver.execute_script(window.scrollTo(0, document.body.scrollHeight);) time.sleep(1) # 分步滚动模拟人类阅读节奏 for i in range(1, 10): driver.execute_script(fwindow.scrollTo(0, {i * document.body.scrollHeight / 10});) time.sleep(0.5)还有一类场景是按钮被遮罩层挡住了click()会报ElementClickInterceptedException用JS执行点击可以直接绕过driver.execute_script(arguments[0].click();, element)但我要提醒一点JS点击虽然好用但它会留下比较明显的自动化痕迹很多风控系统对isTrusted为false的事件是有特殊标记的。所以能用低成本的交互方式就尽量用别一上来就上JS强撸。3.4 文件上传和iframe切换这类特殊操作JS渲染页面经常把上传组件封装得很漂亮比如把input[typefile]隐藏掉让你点击自定义的div。这种组件的处理思路是找到真实的input标签直接用send_keys传文件路径不需要真的去点击那个div触发文件选择框。file_input driver.find_element(By.CSS_SELECTOR, input[typefile]) file_input.send_keys(/path/to/file.xlsx)iframe的处理更是新手重灾区。如果一个作业系统或报表系统用了iframe嵌入其他页面你直接find_element是找不到内部元素的必须先切换进去driver.switch_to.frame(driver.find_element(By.CSS_SELECTOR, iframe#content)) # 操作iframe内的元素 driver.find_element(By.ID, inner-button).click() # 切换回主文档 driver.switch_to.default_content()4. 从requests到Selenium的完整案例抓取一个JS渲染的列表页4.1 场景分析先看数据接口还是先上Selenium很多教程会直接告诉你去写Selenium代码但在我自己的项目流程里第一步永远是打开开发者工具的Network面板看看数据到底是哪来的。这不是说Selenium不行而是能省则省如果数据来自一个返回JSON的XHR接口那用requests直接调接口是最高效的方案速度是Selenium的10倍以上还不容易被识别。但这里有个前提如果接口参数经过了复杂的加密签名比如你看了热词里的jd爬虫风控对抗和大模型逆向爬虫这些话题或者请求头里有动态token短时间内逆向不出来那Selenium就是合理的选择。我的判断标准很简单给Selenium预留30分钟能跑通比自己逆向JS花6小时以上要划算得多那就直接上Selenium。4.2 项目实操完整代码示例下面我以一个典型的招聘列表页为例这类页面几乎所有数据都是JS渲染的非常适合演示。我们要做的事有打开页面、处理可能出现的登录弹窗、滚动加载更多数据、提取列表内容、翻页。import csv import time from selenium import webdriver from selenium.webdriver.common.by import By from selenium.webdriver.chrome.service import Service from selenium.webdriver.support.ui import WebDriverWait from selenium.webdriver.support import expected_conditions as EC from webdriver_manager.chrome import ChromeDriverManager options webdriver.ChromeOptions() options.page_load_strategy eager options.add_argument(--window-size1920,1080) options.add_argument(--disable-blink-featuresAutomationControlled) options.add_experimental_option(excludeSwitches, [enable-automation]) options.add_experimental_option(useAutomationExtension, False) driver webdriver.Chrome( serviceService(ChromeDriverManager().install()), optionsoptions ) wait WebDriverWait(driver, 10) def close_popup_if_present(): 关闭可能出现的登录弹窗/广告弹窗 try: close_btn driver.find_element( By.CSS_SELECTOR, .login-modal .close, .popup .close ) close_btn.click() time.sleep(1) except Exception: pass def scroll_to_bottom(): 模拟人类向下滚动加载更多数据 current_height 0 while True: driver.execute_script(window.scrollTo(0, document.body.scrollHeight);) time.sleep(2) new_height driver.execute_script(return document.body.scrollHeight;) if new_height current_height: break current_height new_height def parse_page(): 解析当前页面的招聘信息 items driver.find_elements(By.CSS_SELECTOR, .job-card) rows [] for item in items: try: title item.find_element(By.CSS_SELECTOR, .job-title).text company item.find_element(By.CSS_SELECTOR, .company-name).text salary item.find_element(By.CSS_SELECTOR, .salary).text rows.append([title, company, salary]) except Exception: continue return rows with open(jobs.csv, w, newline, encodingutf-8-sig) as f: writer csv.writer(f) writer.writerow([职位, 公司, 薪资]) for page in range(1, 4): url fhttps://example.com/jobs?page{page} driver.get(url) close_popup_if_present() wait.until(EC.presence_of_element_located((By.CSS_SELECTOR, .job-card))) scroll_to_bottom() rows parse_page() writer.writerows(rows) print(f第{page}页抓取到{len(rows)}条数据) driver.quit()这个代码里我特意加了几个细节close_popup_if_present用try/except包裹因为弹窗不是每次都出现元素不存在时会抛异常我们要让它静默通过scroll_to_bottom用高度不变作为结束条件防止死循环文件写入用utf-8-sig编码这样Excel打开不会乱码。4.3 等待条件选错导致的数据缺失排查这个案例里最容易踩的坑是wait.until(EC.presence_of_element_located(...))。presence只保证元素出现在DOM里但有些前端框架是先挂载一个空的卡片容器异步请求返回后再填充内容。这时候presence判断通过了但卡片里可能还没有数据解析出来全是空字符串。正确做法是改成等待数据文本出现wait.until( lambda d: d.find_element(By.CSS_SELECTOR, .job-title).text.strip() ! )或者用visibility_of_element_located至少保证元素是可见的。这个坑我在实际项目里遇到很多次每次都是数据条数对不上排查数据源才发现每一页都有一部分数据是空壳。这里分享一个判空技巧解析时用if not title: continue跳过空数据但如果连续多条数据都为空就说明等待条件写错了该去检查等待逻辑。5. 反检测与风控对抗别让网站一眼认出你是机器人5.1 Selenium为什么容易被识别网上关于Selenium被检测的讨论很多但大部分人只知其然不知其所以然。Selenium被识别本质上是因为它驱动的浏览器有太多非人类特征。第一个特征是navigator.webdriver这个属性为true正常用户浏览器里这个值是undefined而Selenium默认会让它变成true。第二个特征是Chrome启动时出现的Chrome正在受到自动软件的控制提示条这个提示条本身就会改变页面布局和DOM结构。第三个特征是Timing和事件行为比如鼠标移动轨迹太线性、点击间隔太均匀这些都是自动化程序的特征。5.2 基础伪装三步走针对上面说的特征有一整套相对成熟的伪装方案。第一步是禁用自动化标记options.add_experimental_option(excludeSwitches, [enable-automation]) options.add_experimental_option(useAutomationExtension, False)第二步是通过execute_cdp_cmd在浏览器每次加载新页面前清除webdriver标记driver.execute_cdp_cmd(Page.addScriptToEvaluateOnNewDocument, { source: Object.defineProperty(navigator, webdriver, { get: () undefined }); })第三步是覆盖常见指纹属性比如navigator.languages、navigator.plugins、navigator.permissions等让JS检测脚本找不到破绽。这一步可以写成一个独立的初始化函数在driver.get()之前执行。注意这三步只是对抗最基础的检测。现在一线风控系统早就不只看webdriver这一个属性了它们会用行为分析、鼠标轨迹、设备指纹、TLS指纹等多维度综合判断。爬虫和风控是一场永无止境的攻防战不存在一劳永逸的解决方案。5.3 高级话题窗口尺寸、UA、时区与语言的联动很多人在设置UA时只改了浏览器标识忽略了时区、语言、字体等联动属性这就导致一个非常滑稽的结果浏览器的UA是Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36但navigator.language却是zh-CN以外的语言设置或者浏览器时区跟UA的地理位置不匹配。风控系统会综合比对这些信息发现冲突直接标记为异常。要完全解决这个联动问题最简单可靠的方式是给整个浏览器设置统一的运行时环境。比如# 设置时区注意这里用的是浏览器的时区格式 options.add_argument(--timezoneAsia/Shanghai)UA、时区、语言这三者必须是一套组合拳。如果你把UA改成美国的Chrome那--langen-US、时区改成America/New_York才算是一个逻辑自洽的浏览器环境。否则宁可保持原版的Chrome UA和zh-CN配置至少不自相矛盾。5.4 验证码和滑块处理思路比代码更关键热词里出现了不少关于滑块验证、拼图验证的搜索说明大家对Selenium能不能过验证码很感兴趣。我的观点是能用验证码识别服务解决的就尽量不要让自己陷入滑块轨迹模拟的无底洞。但如果你确实需要自己处理可以先从思路层面理清再去看代码实现。滑块验证的核心不在滑而在轨迹。人类拖动滑块到缺口位置速度曲线是一条快-慢-回调-精准的曲线而程序控制通常是匀速直线一眼就能识别。简单的手写轨迹模拟可以采用物理加速度模型先加速后减速最后微调修正。代码逻辑类似from selenium.webdriver.common.action_chains import ActionChains # 假设已经定位到了滑块元素 slider 和缺口偏移量 offset actions ActionChains(driver) actions.click_and_hold(slider) # 分段移动每段移动距离不同、停顿时间不同 moves [30, 60, 40, 20, 5, 2] for move in moves: actions.move_by_offset(move, random.uniform(0, 3)) actions.pause(random.uniform(0.1, 0.3)) actions.release() actions.perform()但说实话这种基础轨迹在稍微上档次的验证码平台面前已经不够看了它们会用机器学习模型分析轨迹的分布特征。所以我的建议是除非你是专门研究这个方向的否则优先考虑商业打码平台或者降低采集频次来绕过验证码触发条件。很多情况下验证码根本不是因为你用了Selenium才出现的而是你的请求频率太高了让风控系统觉得你不是人类。这时候把采集频率从每秒1次降到每10秒1次问题可能就不存在了。6. 性能优化与资源管理Selenium爬虫的工业化落地6.1 无头模式、加载策略和请求拦截的极致性能调优用Selenium写爬虫最怕两件事一是采集慢二是内存泄漏导致服务器挂掉。性能优化其实可以精细到每一个环节。在无头模式上新版Chrome的--headlessnew已经非常接近有头模式的行为兼容性比老版本好很多基本可以放心的在生产环境使用。加载策略这里再补充一个重要参数那就是启用--blink-settingsimagesEnabledfalse这个参数可以直接禁止浏览器加载图片。对于绝大多数以文本数据为主的站点图片加载完全是浪费带宽禁用后不仅页面加载速度快了内存占用也会明显下降。请求拦截也是一个好技巧。Selenium 4里可以用CDP命令拦截并丢弃那些我们不关心的请求比如广告域名、埋点脚本、统计上报等。下面这个代码片段可以屏蔽常见的统计服务import json from selenium.webdriver.common.devtools.v120.network import set_blocked_urls driver.execute_cdp_cmd(Network.enable, {}) driver.execute_cdp_cmd(Network.setBlockedURLs, { urls: [*google-analytics.com*, *gtm.js*, *baidu.com/hm*] })把统计脚本和广告脚本全部挡在外面页面渲染速度能提升一截而且还能减少一些风控系统通过第三方脚本采集浏览器指纹的途径。6.2 并发方案多线程和多进程的正确打开方式Selenium的并发是很多人的知识盲区。有些人听说了要快就要并发就写一个多线程脚本每个线程里new一个Chrome实例很快就把服务器内存跑爆了。这里需要明确两点Selenium不是线程安全的同一个driver实例不能跨线程使用。每个Chrome进程吃内存非常夸张无头模式大约200-300MB起步开8个并发就是2.4GB。所以我的建议是采用多进程连接池的方式一个进程负责一个Chrome实例进程间用队列来分发任务。控制并发数在4-6个比较合适再多就要考虑分布式方案了。还有一种折中思路是使用同一个浏览器实例的多标签页。一个Chrome进程内可以开多个tab每个tab独立加载页面这样共享内存和代理配置资源占用比开多个进程要小很多。但缺点是标签页之间可能会互相影响稳定性差一些需要至少两个driver实例做哨兵来监控主标签页状态。6.3 资源释放driver.quit()比你想象的更重要Selenium脚本写久了就会遇到一个让人抓狂的现象明明程序跑完了服务器上还是有几十个chromedriver和chrome进程在跑每一个都在吃内存。这是因为很多人只写了driver.close()关闭当前标签页但没有调用driver.quit()释放整个浏览器会话。正确的退出方式是driver.quit()它会关闭所有标签页和整个Chrome进程同时清理chromedriver。为了确保异常情况下也能清理干净建议用try/finally包裹try: # 爬虫逻辑 pass finally: driver.quit()如果进程还是残留了可以用下面的命令行清理pkill -f chromedriver pkill -f chrome --headless但在写代码时千万别依赖这个生产环境里监控脚本要自己处理好进程的生命周期管理。6.4 分布式爬虫Selenium不是瓶颈代理才是当单机并发已经满足不了需求时你会考虑分布式。但分布式Selenium爬虫的第一道坎不是Selenium本身而是IP资源。同一个IP同时跑4个浏览器实例风控系统秒秒钟就会发现异常。所以分布式方案里给每个Chrome实例分配一个独立代理地址是标配options.add_argument(--proxy-serverhttp://127.0.0.1:8080)代理池的质量直接决定分布式爬虫的寿命。免费的代理IP池稳定性差经常出现连接超时Selenium的等待机制会因为这种超时变得极其迟钝。商业代理池又贵所以我的建议是如果你目标站点的数据量需求还没到日百万级别先别急着上分布式优先把单机的采集频率、数据解析效率和反检测策略优化到极致。7. 高频异常与排查方法速查|报错信息触发原因排查与解决思路SessionNotCreatedExceptionChrome和Driver版本不匹配检查浏览器版本号和chromedriver版本号前三位必须一致ElementClickInterceptedException目标元素被弹窗或遮罩层遮挡先用driver.close()关闭弹窗或用execute_script执行JS点击TimeoutException显式等待超时打开页面检查元素选择器是否正确可能是iframe或Shadow DOM嵌套StaleElementReferenceException页面DOM刷新后之前找到的元素引用失效重新查找元素不要复用旧的WebElement对象WebDriverException连接中断浏览器进程崩溃或chrome驱动被杀查看系统内存是否不足用res监控进程必要时分段跑数据NoSuchElementException初期偶发页面加载过慢元素还没渲染出来检查等待策略换成WebDriverWait并等待可见性条件这个表里的每一项都是实际项目里反复踩过的问题。我特别要再强调一下StaleElementReferenceException很多新手以为是代码写错了其实是因为页面有一个异步刷新机制你第一次找到的元素已经过期了需要回到find_element那一步重新拿一次引用。还有一个排查经验当爬虫运行一段时间后莫名变慢先不要怀疑是目标网站加了检测多数情况是你的驱动目标页面积累了大量的DOM节点和异步请求没有释放浏览器内存涨上去了。这时候最有效的办法是定期重启driver实例比如每抓2000个页面或每40分钟强制退出重开一次虽然看起来低效但比在一个半死不活的长寿进程里死磕要稳定得多。在我处理过的大量JS渲染采集任务里最让我感慨的一点是Selenium这套技术本身并不难难的是知道什么场景该用它什么场景不该用它以及一旦决定用了之后你对目标站点的运行机制、浏览器的底层行为、风控系统的检测逻辑有没有足够深入的理解。给新手的建议是不要一碰到JS渲染页面就无脑上Selenium先花15分钟看看接口、试试构造请求如果发现确实需要Selenium再严格按照本文讲的等待、定位、反检测、资源管理这套方法论去执行。这样既能保证项目跑得通也能让你在爬虫这条路上走得更远。最后再分享一个小技巧写Selenium爬虫时永远给每一步关键操作留好日志和截图。driver.save_screenshot(debug.png)在前几次运行时可能显得多余但一旦出了诡异问题这些截图就是你排查的救命线索。线上永远会跑出你本地复现不了的bug这是爬虫工程化的常态。