企业官网建设流程全解析

爬虫这东西，写到后面基本都会撞上一堵墙——发个请求过去，明明拿到了一堆HTML，但里面空空如也，你想抓的数据一个都不在；或者数据倒是有，但全都是些看不懂的JS变量、加密签名。很多初学爬虫的朋友到了这一步就卡住了，下意识以为是Header不够全、Cookie没带够，实际上问题往往出在另一个维度：你看到的页面，压根不是服务器直接给的，而是浏览器里JavaScript现场渲染出来的。

这篇文章就来聊聊怎么用Selenium这种“带浏览器”的方案解决JavaScript渲染问题。会从原理层面讲清楚为什么有的数据Requests拿不到、Selenium凭什么能拿到，再给出可直接抄作业的完整代码、等待策略、反爬应对方案，以及我实际踩过的坑和排查思路。如果你正卡在动态页面上，这篇应该能帮你省下不少折腾时间。

1. 内容整体设计与思路拆解

1.1 先搞清楚一个核心问题：页面到底是不是JS渲染的

在动手写Selenium之前，最好先花两分钟判断目标页面属于哪一类，这直接决定了技术选型。我的习惯是先用最简单的Requests拉一次HTML，然后看一眼里面有没有目标数据。如果HTML里直接能找到，那就是服务端渲染，老老实实用Requests + XPath或正则就行，没必要上Selenium，纯属杀鸡用牛刀。如果HTML里根本看不到目标数据，只有一堆<script>标签和window.__INITIAL_STATE__之类的变量，那基本可以断定是客户端渲染，也就是数据要等JavaScript跑起来之后才出现在DOM里。

判断方法很简单：

import requests resp = requests.get("https://example.com/some-page") html = resp.text if "你要抓的数据关键字" in html: print("服务端渲染，直接用Requests") else: print("JS渲染，需要考虑Selenium或接口逆向")

还有一种情况更隐蔽：页面HTML里确实有部分数据，但核心列表是异步加载的，也就是首屏HTML只给了个页面骨架，真正的数据是页面加载完后再通过XHR或Fetch请求拿到的。这种情况用Requests也不是完全不行，前提是你能在开发者工具的Network面板里找到那个真正的数据接口，然后直接模拟那个接口的请求。但这条路的门槛在于，很多站点的数据接口带着签名、时间戳、加密参数，逆向成本不低，这时候Selenium反而是性价比更高的选择。

1.2 为什么Selenium能拿到渲染后的页面

Selenium做的事情简单说就是：帮你真实地打开一个浏览器内核，让页面里的JavaScript在真实的浏览器环境里跑完，然后把渲染之后的最终DOM交给你。这和Requests请求拿到的原始HTML是两个完全不同的东西，一个是源代码，一个是“画完之后的成品”。

这里有个关键点值得展开说：JavaScript渲染依赖浏览器引擎，包括V8这类JS解释器、DOM解析器、CSS引擎，还要处理网络请求、事件循环、定时器等等。Requests只是个HTTP客户端，它只会把服务器返回的字节流拿回来，根本不会去执行里面的JavaScript。所以哪怕你在HTML里看到了document.getElementById("data").innerHTML = ...这段代码，Requests也无法让它跑起来。Selenium则是直接驱动一个完整的浏览器环境，JS得以上下文完整地执行，于是数据自然就出现在页面上了。

从架构上看，Selenium通过WebDriver协议和浏览器通信。WebDriver可以理解成一套标准化的“遥控器协议”，它定义了打开网址、找元素、点按钮、输入文字、读取DOM这些操作。Selenium把你要做的操作翻译成WebDriver命令，浏览器内核收到命令后执行，再把结果传回来。Chromedriver就是Chrome这边的翻译官，GeckoDriver是Firefox那边的，两边遵循同一个协议，所以代码写好了，换浏览器往往只需要换一个driver。

1.3 使用场景与适用边界

Selenium适合的场景很明确：数据依赖JS渲染、需要登录后见数据、有复杂交互才能触发加载、或者数据在DOM中但经过多层嵌套。典型如电商平台的价格库存、社交平台的信息流、数据可视化大屏、大量使用Vue和React的现代网站。

但Selenium也有明显的代价：慢。它跑的是完整浏览器，资源占用比纯HTTP请求高一个数量级，并且需要维护浏览器驱动版本匹配。所以技术选型上我一直强调一个原则：能用Requests解决，就不要上Selenium；能用接口直接拿下，就不要渲染页面；只有前面两条路都走不通了，Selenium才作为“最后的重型武器”登场。另外一个常见替代方案是Playwright，它在API设计和自动等待上比Selenium更现代，但Selenium胜在生态老、资料多、坑基本都被踩平了，新手学它起步会更稳妥。

2. 核心细节解析与实操要点

2.1 浏览器驱动的版本匹配与环境准备

用Selenium第一步不是写代码，而是把环境捣鼓好。这里最坑的就是版本匹配问题：Chromedriver版本必须和Chrome浏览器版本大体一致，否则启动时会直接报session not created或版本不匹配的错。

我踩过一次很典型的坑：Chrome自动更新到了新版本，但Chromedriver还是旧的，结果一跑就挂。后来学乖了，直接查版本号再下载对应驱动。版本号可以在浏览器地址栏输入chrome://version查看，然后去ChromeDriver的下载页面找对应版本即可。需要注意Chromedriver下载后不能直接运行，必须把它放在一个固定目录，并在代码里初始化webdriver.Chrome(executable_path="/path/to/chromedriver")。

现在Selenium 4.x对驱动的处理更友好了一些，很多情况下会自动匹配，但保险起见，还是建议手动指定路径，省得出幺蛾子。如果你用的是新版Chrome，也可以试试webdriver.Chrome()不加参数，它会自动去环境变量里找驱动，或者自动下载匹配版本。实测下来这个功能确实省事，但在某些网络受限的环境下依然可能失败，所以我还是保留了手动指定的习惯。

2.2 等待策略：隐式等待与显式等待的区别

Selenium最核心的一个问题就是“页面到底加载完没有”。网络请求有快有慢，JS执行有早有晚，如果代码执行到find_element的时候元素还没渲染出来，直接就是NoSuchElementException。所以等待策略是Selenium使用中的重中之重，很多人写出的代码时灵时不灵，十有八九都是等待策略写得有问题。

隐式等待的写法是：

driver.implicitly_wait(10)

它的意思是：每次查找元素时，如果元素没出现，就在规定时间内轮询等待，直到超时为止。这个策略的特点是“一次设置，全局生效”，简单粗暴，但它有个问题——它对所有元素查找都生效，包括那些根本不可能出现的元素，这会导致无谓的等待浪费时间。

显式等待则是针对某个特定条件的等待，更精准：

from selenium.webdriver.support.ui import WebDriverWait from selenium.webdriver.support import expected_conditions as EC from selenium.webdriver.common.by import By wait = WebDriverWait(driver, 10) element = wait.until( EC.presence_of_element_located((By.CSS_SELECTOR, ".item-title")) )

这句话的意思就是“最多等10秒，直到class为item-title的元素出现为止”。显式等待的逻辑更贴近真实使用场景，因为你只需要等你要的那个东西出现，而不是所有元素都加载完。

我的使用习惯是：干脆放弃隐式等待，全程用显式等待。原因很实际——隐式等待虽然写起来省事，但碰到复杂页面时很难控制等待粒度，比如一个很晚才会出现的元素和一个元素不存在两种情况，隐式等待无法区分，而显式等待可以精确控制。实践中我还会配合EC.element_to_be_clickable和EC.visibility_of_element_located，关注“可点击”和“可见”两个状态，因为很多组件虽然出现在DOM中，但尚未完成渲染或展示。

2.3 浏览器选项配置：要性能还是要稳定

创建Driver实例的时候，很多人直接webdriver.Chrome()就上了。但在实战中，我会习惯性把options配一遍，尤其注意--headless、--disable-gpu、--no-sandbox这几个参数。其中最重要的一个决定是：到底要不要无头模式。

无头模式（Headless）因为不显示浏览器窗口，速度快而且不打扰人，一开始我也特别喜欢用。但你得知道，无头模式与有头模式在行为特征上有微妙差异，某些网站会检测navigator.webdriver、window.chrome这些特征，很容易识别出你是自动化工具。而且有些页面在无头模式下WebGL渲染结果不同、动画表现不同，甚至某些JS功能不触发，导致元素加载不出来。所以我的经验是：先把代码跑通了，然后再换无头模式做效率优化。不要一开始就无头，否则出了问题连页面长什么样都不知道，排查起来非常痛苦。

我给出一份比较稳妥的配置模板，细节上都注释过：

from selenium import webdriver from selenium.webdriver.chrome.options import Options options = Options() options.add_argument("--headless=new") # 新版无头模式，旧版是 --headless options.add_argument("--disable-gpu") # GPU加速在无头模式下没有意义 options.add_argument("--no-sandbox") # Linux服务器上必需，普通电脑可以不加 options.add_argument("--disable-dev-shm-usage") # 容器环境内存受限时必备 options.add_argument("--window-size=1920,1080") # 设定窗口大小，有时影响懒加载判断 options.add_argument("--lang=zh-CN") # 避免出现英文界面，有些站点根据语言返回不同内容 options.add_experimental_option("excludeSwitches", ["enable-automation"]) # 弱化自动化标记 driver = webdriver.Chrome(options=options)

还有一个很多人都不知道的小技巧：如果你用--user-data-dir指定一个固定的浏览器用户目录，就能保留登录状态、Cookie等信息，省去每次扫码登录的麻烦。这个目录就是Chrome保存账号状态的地方，指定之后Selenium会使用这个“用户画像”，而不是每次启动一个全新用户，很多需要登录态的站点会好处理很多。

options.add_argument("--user-data-dir=/path/to/chrome-profile")

但需要注意，这个目录如果被其他Chrome进程占用，Selenium会启动失败，所以用的时候要让那条命令成为唯一占用它的进程。

3. 实操过程与核心环节实现

3.1 完整案例：抓取一个列表页的数据

这里我用一个通用思路来讲，拿一个典型的列表页作为例子。这个页面大概长这样：页面加载后先有个加载动画，大概一两秒后列表数据通过JS渲染到页面上，每个列表项包含标题和链接。直接Requests是拿不到的。

第一步，创建Driver并打开目标页面：

path_to_chromedriver = "/usr/local/bin/chromedriver" # 换成你本地路径 options.add_argument("--headless=new") driver = webdriver.Chrome(executable_path=path_to_chromedriver, options=options) driver.get("https://example.com/list")

第二步，用显式等待等列表项出现：

try: wait = WebDriverWait(driver, 15) items = wait.until( EC.presence_of_all_elements_located((By.CSS_SELECTOR, ".list-item")) ) print(f"列表加载成功，共 {len(items)} 项") except Exception as e: print("列表加载超时，页面结构可能变了或加载失败:", e) driver.quit() raise

这里用presence_of_all_elements_located等待多个元素同时出现，比逐个查单个元素高效得多。如果列表项很多，可能需要滚动页面才能触发懒加载，这我们后面单独讲。

第三步，遍历并提取数据：

data = [] for item in items: try: title = item.find_element(By.CSS_SELECTOR, ".title").text link = item.find_element(By.CSS_SELECTOR, "a").get_attribute("href") data.append({"title": title, "link": link}) except Exception: # 单个元素解析失败，跳过即可，不要影响整体 continue print(data)

这里有个小坑：item.find_element拿到的是当前列表项下的子元素，如果用了全局的driver.find_element，就会一直拿到第一项的标题，全漏掉。这种问题几乎不会报错，但结果就是数据全错，排查起来非常隐蔽。

第四步，收尾：

driver.quit()

3.2 滚动加载与点击加载更多

遇到过很多页面，数据不一次性全渲染出来，而是你滚到页面底部，它才通过Ajax去拿下一批数据。这种场景Selenium处理起来有几个思路，按效率从低到高排列。

最简单粗暴的方式：模拟滚动到底部，然后等新数据出现，循环这个过程直到数据不再增长。实现思路大致如下：

driver.get("https://example.com/infinite-list") prev_count = 0 for _ in range(10): # 最多滚动10次，防止死循环 # 模拟滚到底部 driver.execute_script("window.scrollTo(0, document.body.scrollHeight);") # 等新数据加载 time.sleep(2) items = driver.find_elements(By.CSS_SELECTOR, ".list-item") cur_count = len(items) if cur_count == prev_count: print("数据不再增长，滚动结束") break prev_count = cur_count print(f"最终获取 {prev_count} 条数据")

这里用了execute_script直接执行JavaScript代码，window.scrollTo(0, document.body.scrollHeight)把滚动条拖到页面最底部，进而触发懒加载的逻辑。time.sleep(2)等待时间不宜太长也不宜太短，太短数据没加载完就继续滚了，太长则拖慢整体效率。

更优雅的方案是点击“加载更多”按钮，思路是重复“找按钮、点击、等待新数据”的循环：

from selenium.webdriver.common.by import By from selenium.webdriver.support.ui import WebDriverWait from selenium.webdriver.support import expected_conditions as EC wait = WebDriverWait(driver, 10) for i in range(5): try: load_more = wait.until( EC.element_to_be_clickable((By.CLASS_NAME, "load-more-btn")) ) load_more.click() wait.until( EC.presence_of_element_located((By.CSS_SELECTOR, ".new-item")) ) except Exception: print("没有更多加载按钮或已加载完所有数据") break

但这里有一个实际问题：如果新增的元素和旧元素选择器相同，你通过presence_of_element_located等待时，由于元素已经存在，等待条件会立即返回，导致你没等到新数据就去点下一次按钮了。这里可以用一个更精准的方式：记录当前数据量，等待数据量变大。

prev = len(items) load_more.click() wait.until(lambda d: len(d.find_elements(By.CSS_SELECTOR, ".list-item")) > prev)

3.3 跨越难点的JavaScript执行

Selenium一个很有用的特性是execute_script，它允许你直接在浏览器上下文里执行任意JS代码。这个能力在几种情况下特别有用：

• 获取元素的某种状态，用标准API拿不到时；
• 滚动页面触发懒加载；
• 修改元素的属性值、移除属性，绕过某些前端校验；
• 直接读取JS变量或接口返回的数据。

一个典型场景：某些网站在表单提交前用JS做了校验，禁止你填入不符合规则的内容。这时你可以用execute_script直接设置元素的value值：

element = driver.find_element(By.ID, "phone") driver.execute_script("arguments[0].value = '13800138000';", element)

另一个场景：某些数据在DOM中找不到，但存在JS全局变量中，比如window.__data。这时候可以直接在JS上下文里读出来：

data = driver.execute_script("return window.__data;")

这个返回值在Python里可能会是字典、列表等基础类型，直接处理起来非常方便。还有一种场景是页面里渲染的数据很深层级嵌套，CSS选择器写起来又长又容易断，我直接返回整块数据再做后续解析，省去一层层找元素的麻烦。

execute_script还有一点需要注意：不能直接返回DOM元素对象，它会被序列化成某种WebElement引用，想要拿属性值最好在JS里处理干净再返回：

titles = driver.execute_script(""" return Array.from(document.querySelectorAll('.list-item .title')).map(el => el.textContent); """)

3.4 与Requests结合：两种方案配合的混合模式

Selenium不是万能的，它的短板在于速度快不起来。但很多场景可以组合使用：Selenium负责处理登录、获取带认证的Cookie，拿到之后把Cookie交给Requests去抓接口，这种“混合模式”能有效提高整体效率。

具体思路是这样的：先让Selenium打开登录页，模拟输入账号密码，等登录成功后，用driver.get_cookies()拿到会话Cookie，然后将这些Cookie转成Requests可用的格式，之后就可以用Requests直接请求目标接口了。这样既能绕开登录限制，又能获得Requests的高并发和低消耗。

cookies = driver.get_cookies() import requests session = requests.Session() for cookie in cookies: session.cookies.set(cookie["name"], cookie["value"], domain=cookie.get("domain")) resp = session.get("https://example.com/api/data", headers={"User-Agent": "Mozilla/5.0"})

这种模式适合“登录后拦截接口”的场景，比全程用Selenium翻页效率高出好几个量级。但它的前提是你能从抓包工具里找到那个数据接口，且接口没有额外的签名参数。如果你不熟悉浏览器的Network面板，可以顺着这个思路学一下怎么找XHR请求，这是爬虫进阶路上非常关键的一环。

4. 常见问题与排查技巧实录

4.1 核心问题速查表

这里整理了一份我在实际回答中被问得最多、自己处理最多的问题速查表，每条都是踩过坑才总结出来的。

4.2 设计全网环境下最常见的一个隐蔽坑：等待时间与元素状态的匹配问题

我的经验里，新手遇到最多的不是“选择器写错”，而是“等待条件选错”。比如有人用presence_of_element_located等待一个元素，发现它经常能等到，但等到之后一click()就报错。因为presence只代表元素存在于DOM中，不代表它可见、可点击。很多前端框架渲染出来的元素，最初是display:none或disabled状态，要等后续JS把它变为可用状态。

正确做法是等待时选对EC条件：

• 等待元素可见：EC.visibility_of_element_located
• 等待元素可点击：EC.element_to_be_clickable
• 等待元素消失：EC.invisibility_of_element_located
• 等待文本变化：EC.text_to_be_present_in_element

这些条件本质上是帮你做了“轮询+条件判断”两件事。每个等待条件内部都是循环检测，默认每0.5秒检查一次，直到超时为止，可以理解成一套自动的“尝试—判断—重试”机制。

4.3 怎么确认页面真的渲染完了

排查问题时，我最常用的手段是截图和打印页面源代码。截图能直观看到页面当前长什么样，打印源码能看渲染后的DOM结构。这两个手段配合起来，基本能把大部分加载问题定位清楚。

driver.save_screenshot("screen.png") html = driver.page_source with open("page.html", "w", encoding="utf-8") as f: f.write(html)

打开page.html，搜索你要抓的关键词，如果源码里有但Selenium找不到，说明是选择器写错了；如果源码里没有，说明页面JS还没跑完，需要优化等待策略；如果源码里压根没有这个数据，可能数据根本不在DOM里，而是存在前端状态对象中，需要回头用execute_script直接读，或者去Network里找接口。

4.4 遇到反爬时怎么调整

站点识别Selenium的手段通常是检测navigator.webdriver属性、浏览器的自动化标记、CDP（Chrome DevTools协议）调用痕迹，以及行为上的异常，比如鼠标轨迹、点击间隔、访问速度等。对于前两者，最基础的两个手段：

options.add_experimental_option("excludeSwitches", ["enable-automation"]) options.add_experimental_option("useAutomationExtension", False)

上面两行代码可以在一定程度上弱化自动化标记。更彻底的做法是：

driver.execute_cdp_cmd("Page.addScriptToEvaluateOnNewDocument", { "source": """ Object.defineProperty(navigator, 'webdriver', { get: () => undefined }); """ })

这行代码在页面加载前就注入JS，把navigator.webdriver属性改造掉。实测下来，不少站点的基础检测能被绕过。

但我要强调一点：如果你的目标站点验证码异常频繁、或者有非常严苛的风控策略，技术上再怎么调也是打地鼠式的对抗，价值不大了。遇到这种情况，我的建议是调整采集策略：降低频率、控制每天的总量上限、减少单次会话的持续时长。自动化工具的使命是提高效率，但前提是合理合法地使用，不要给自己惹上不必要的麻烦。

4.5 JavaScript渲染相关的特殊坑

页面里如果有WebSocket实时推送数据，会发现Selenium拿到某个状态之后，数据还在不断变化。这种场景下别急着把页面关掉，先判断目标数据是“实时快照”还是“连续推进”。如果需要稳定抓取某个瞬时值，用JS全局变量或JSON解析要比DOM文本稳得多。

另一个坑是定时器和动画。比如数据已经出现在DOM上，但页面动画还在移动元素位置，导致你click()的时候点偏了。我遇到过点击按钮时因为页面顶部弹窗把按钮遮住而报错的情况，解决办法是用scrollIntoView把目标元素滚动到可视区，再加一个合适的等待时间。

5. 这些坑总结起来，Selenium的核心心得

写到这里，我脑子里翻过几个实际项目。一个朋友要抓一个前端框架做的数据报表，页面上一堆图表和过滤条件，我用Requests逆向了半天接口，发现参数都被打包成加密串了，最终老老实实用Selenium每十分钟跑一轮，把页面渲染后的表格数据提取出来，稳定跑了两三个月，最大的麻烦反而是浏览器驱动的定时更新。另一个项目是抓一个图片站，列表数据在DOM里，但翻页是JS动态加载，我用了滚动加载方案，加上限速和随机延时，几千页跑下来没出大问题。

实战里我深刻体会到几个原则。第一，能用显式等待就不用隐式等待和固定sleep，这是Selenium入门到进阶最重要的一道坎。固定sleep的问题在于它在等待时是无条件空转，网络差的时候不够用，网络好的时候浪费几秒钟，每个页面多几秒，几千页跑下来差距就非常大了。而显式等待是根据实际条件触发返回的，快的时候几毫秒，慢的时候等到超时，整体吞吐量会好很多。

第二，能用有头模式跑通，再换无头模式做效率优化。有头模式最大的价值是“看得见”，出了问题截图定位往往比读错误日志快得多。真正上生产环境时再切换无头，同时配合--log-level=3减少控制台刷屏。

第三，高频登录态的站点优先考虑“保持会话”策略。用固定--user-data-dir保留登录态，能省去每次登录的时间和风险，也是规模化采集的基础要求之一。

第四，设计异常处理时必须记住driver.quit()一定要执行，否则浏览器进程会在后台堆积，跑不了几百个页面就内存耗尽。推荐用try/finally或者with结构来保证资源释放。

第五，也是我最有感触的一点：Selenium解决的问题是“页面是JS渲染的”，但它不是唯一的答案。有些场景接口逆向比Selenium高效十倍，有些场景Playwright的API设计比Selenium顺手，有些场景甚至用Chrome DevTools Protocol直接写脚本更灵活。技术选型永远是在效率、稳定性和维护成本之间做权衡，不要因为Selenium学得最熟练就处处用它，也不要因为听说它是重型工具就避之不及。工具是死的，思路是活的，把Requests的轻量、Selenium的完整渲染能力和浏览器的调试能力灵活组合起来，采集效率才会真正上台阶。