静态解析器为什么抓不到动态内容
BeautifulSoup 的工作方式是解析一段已经拿到的 HTML 字符串，它不负责发请求，更不负责执行 JavaScript。requests 拿回来的响应体，是服务器最初吐出的那份源码，浏览器里后来用 JS 拼上去的节点，它一概看不到。
现象很典型：浏览器里价格、库存、评论数都正常显示，右键查看网页源代码却找不到对应元素。这时候 soup.find('div', class_='product-price') 返回 None，不是选择器写错了，是数据压根不在响应里。
import requests
from bs4 import BeautifulSoup
response = requests.get('https://example-store.com/product123')
soup = BeautifulSoup(response.text, 'lxml')
price_div = soup.find('div', class_='product-price')
# 返回 None
要拿到这部分内容，思路只有一个：让某个东西真正把 JS 跑一遍，再把执行后的 DOM 交回给 BeautifulSoup。BeautifulSoup 负责解析，渲染交给别的工具，两者分工。
渲染引擎的几种接法
早期最省事的是 requests-html，它把请求、渲染、解析包在一起，API 和 requests 几乎一致。
from requests_html import HTMLSession
session = HTMLSession()
response = session.get('https://example-store.com/product123')
response.html.render(timeout=20) # 执行JavaScript渲染
dynamic_html = response.html.html
soup = BeautifulSoup(dynamic_html, 'lxml')
price = soup.select_one('.product-price').text
print(f"解析到价格：{price}")
但这里有个现实问题得先说清楚：requests-html 最后一个版本停在 0.10.0，作者已明确不再维护。它内部下载的 Chromium 版本很旧，在 Python 3.10 以上环境里经常出现 pyppeteer 启动失败、Browser closed unexpectedly 之类的报错。新项目不建议再选它，老项目能跑就别动。
更稳的选择是 Selenium 4 或 Playwright。以 Selenium 为例，拿到渲染后的 page_source，再丢给 BeautifulSoup：
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 bs4 import BeautifulSoup
driver = webdriver.Chrome()
driver.get('https://example-store.com/product123')
WebDriverWait(driver, 20).until(
EC.presence_of_element_located((By.CSS_SELECTOR, '.product-price'))
)
html_content = driver.page_source
driver.quit()
soup = BeautifulSoup(html_content, 'lxml')
price = soup.select_one('.product-price').text
注意这里把固定 timeout=20 换成了显式等待。固定等待的问题是：网慢的时候 20 秒还没渲染完，你取到的仍是半成品 HTML，选择器照样返回 None，而且这种失败是间歇性的，很难复现。显式等待盯着目标元素出现再往下走，判定标准明确——元素出现即视为渲染成功，超时抛异常即视为失败，比 sleep 靠谱得多。
解析器选型与性能取舍
BeautifulSoup 本身支持多种底层解析器，速度差别不小。lxml 基于 C 实现，通常比纯 Python 的 html.parser 快，原文提到”快 30% 以上”这个量级在多数场景下成立，但具体倍数取决于文档结构和机器，不必当成硬指标。
选解析器时还有两个坑：lxml 需要单独装 C 依赖，某些精简镜像里装不上；html5lib 容错最好但最慢，只在 HTML 结构极其混乱时才值得用。日常抓取优先 lxml，环境装不上再退回 html.parser。
这套方案什么时候不该用
渲染方案不是万能钥匙，用之前先判断目标数据到底从哪来。
如果页面数据是通过 XHR/Fetch 接口异步加载的，正确做法是直接抓那个接口，而不是渲染整个页面。打开开发者工具的 Network 面板，筛选 XHR，往往能看到返回 JSON 的请求，直接请求它拿到的数据结构更干净，速度也快一个数量级。渲染浏览器是最后手段，不是首选。
渲染方案的真实代价：每个页面要启动浏览器上下文，内存和 CPU 开销远高于纯 HTTP 请求；并发上不去，几十个页面就可能把机器拖慢。适用场景是数据确实由前端 JS 计算或拼装、没有独立接口可抓的情况。不适用场景是接口可直连、或页面结构静态但被误判为动态。
另外，渲染会真实加载页面里的所有资源，包括埋点脚本和广告，请求频率必须压住。robots.txt 要遵守，采集行为本身要合法，这部分没有技术捷径可绕。
环境与版本上的现实提醒
Selenium 4 之后不再需要单独下载 chromedriver，Selenium Manager 会自动匹配浏览器版本，省掉了过去版本对不上的经典报错。如果还在用 Selenium 3，webdriver.Chrome() 找不到 driver 是高频问题，升级到 4 是最省事的解法。
Playwright 在无头渲染和等待机制上做得更细，page.wait_for_selector 语义和上面的显式等待一致，对多浏览器支持也更完整。团队如果本来就在用 Playwright 做端到端测试，抓取时顺手复用同一套依赖，比再引入 Selenium 更划算。
无论选哪个渲染引擎，都建议在正式跑之前先手动验证一次：把渲染后的 HTML 存成文件，用 BeautifulSoup 离线解析一遍，确认选择器能命中。把”渲染是否成功”和”解析是否正确”这两步拆开验证，出问题时能立刻定位是渲染没跑完还是选择器写错，比混在一起调试省时间。
ID:6499
