Canvas图表爬虫破解指南：用Selenium钩子捕获绘图数据

去年接了一个数据采集任务，目标是一个报表系统里的趋势图。一开始我想得很简单：requests 拿接口 JSON，不行就 selenium 模拟登录慢慢翻。结果打开开发者工具一看，整个人愣住了——整个页面只有一个 <canvas> 标签，图表里的数字、坐标轴标签、图例说明，全都"画"在了画布上，DOM 树里一个都找不到。之前的经验全部作废。这就是典型的 Canvas 渲染数据图表：前端用绘图引擎把数据变成像素，浏览器里看得见摸得着，爬虫这边却像隔了一层毛玻璃。

这篇文章就专门解决这个问题。我会先讲明白 Canvas 图表为什么难爬，再列出几条切实可行的路线，最后给出一套用 Selenium 注入钩子截获绘图数据的完整方案，包含我踩过的坑和排查思路。适合正在做数据采集、报表自动化、竞品数据监控的朋友参考。不管你是 Python 新手还是有一定经验的爬虫工程师，看完都能直接落地。

1. 为什么 Canvas 图表是爬虫的"黑盒"

1.1 Canvas 渲染的底层机制与 DOM 爬虫的盲区

先说清楚一个问题：普通网页里，数据展示靠的是 HTML 元素。一个表格、一段文字、一张图片，都有对应的 DOM 节点，爬虫解析 HTML 就能拿到内容。但 Canvas 完全不同。

如果说 DOM 像一份印刷好的报纸，文字、图片、位置都写在版面上，爬虫只要读报就能抄到内容；那 Canvas 就更像一块电子画板。页面在运行时通过 JavaScript 调用绘图 API，把点、线、面、文字一笔一笔画上去。画完之后，画板上只有最终的像素颜色，至于刚才画了哪条线、写了哪个字，画板自己并不保存。

用代码拆开看，Canvas 绘制的核心是这样的：

javascript复制const canvas = document.getElementById('chart');
const ctx = canvas.getContext('2d');
ctx.fillText('2024年Q1销售额', 100, 50);
ctx.beginPath();
ctx.moveTo(20, 200);
ctx.lineTo(180, 60);
ctx.stroke();

爬虫解析 HTML 时，看到的就是：

html复制<canvas id="chart" width="800" height="400"></canvas>

没有任何数据信息。真正的数据流转发生在 JavaScript 运行时，而 Selenium 这类自动化工具获取的是渲染后的 DOM，同样拿不到 canvas 内部的绘图调用记录。这就是最核心的盲区。

对比一下常见图表方案的爬虫友好度：

所以遇到 Canvas 图表，第一反应应该是：别在 DOM 里找数据，要找数据进入 canvas 之前的源头。

1.2 反爬者为什么偏爱 Canvas，以及常见的组合拳

很多数据平台宁可牺牲一部分用户体验，也要把图表从 SVG 换成 Canvas，原因很直接：数据不可见性。图表上的数值不进入 DOM，普通的 requests、Scrapy、Selenium 解析器全部失效，这就在第一层就挡住了大部分爬虫。

更狠的是，Canvas 渲染经常和反爬手段组合使用。我见过比较典型的配置是：

1. 数据接口加密：前端拿到的数据本身就是密文，要经过一波解密运算才能画到画布上。接口层就挡住了 90% 的请求型爬虫。
2. 接口响应不包含完整数据：服务端只返回最近一屏的增量数据，历史数据靠前端本地聚合，想直接从接口拿全量数据根本不可能。
3. Canvas 加 WebDriver 检测：页面加载时检测 navigator.webdriver 属性，如果发现是自动化环境，画布上会随机少画几个柱状条，或者把数值渲染成错误数字，让人防不胜防。
4. 关键信息不画在图上：坐标轴标签、图例数值用 Canvas 画，但 tooltip 里的详细数据却由另一个动态 DOM 生成，形成"页面可见、源码不可见、接口又加密"的三角结构。

这套组合拳打下来，单纯靠 Selenium 点击、截图已经不够用了，必须从多个层面同时下手。这就是为什么我接下来要讲的方案是"组合路线"而不是单点突破。

2. 四条可行的破局路线，怎么选才算高效

2.1 接口优先：Hook 网络请求才是最优解

先记住一个原则：页面不管渲染得多花哨，要把数据展示出来，数据一定得先传到前端。所以遇到任何 Canvas 图表，第一个动作永远是打开控制台的 Network 面板，看看到底哪个请求在返回原始数据。

有些站点接口是明文的，直接拿来用就行。但很多报表系统会对接口做签名、加密，这时候就需要让浏览器帮我们完成"请求 + 解密 + 渲染"的完整流程，而我们只负责在中间偷听。

推荐用 Selenium 注入 JavaScript 钩子来监听网络请求。以 fetch 为例，在页面加载前重写 window.fetch：

javascript复制const originalFetch = window.fetch;
window.__fetchLog = [];
window.fetch = function (...args) {
    const url = typeof args[0] === 'string' ? args[0] : args[0].url;
    const options = args[1] || {};
    return originalFetch.apply(this, args).then(response => {
        const cloned = response.clone();
        cloned.text().then(body => {
            window.__fetchLog.push({ url, request: options.body || '', response: body });
        });
        return response;
    });
};

这段代码的思路是：在数据到达页面之前，先把 URL 和响应体复制一份存到全局变量。之后用 driver.execute_script("return window.__fetchLog;") 就能拿到所有 fetch 请求的明文内容，就算页面把数据加密后再画到 canvas，我们拿到的也是解密前或解密后的原始 JSON，干净、完整、结构化。

同理可以 Hook XMLHttpRequest 和 WebSocket。很多图表实时推送数据时用 WebSocket，只有 Hook 了 WebSocket 才能拿到流式数据。这类方案的最大优点是：不关心图表怎么画，只关心数据怎么传。

2.2 JS 钩子：在 Canvas 绘图调用的源头截获数据

如果接口层做得很严，找不到明文请求，或者服务端只返回增量数据，那就要考虑第二层：在 Canvas 绘图调用的源头截获。

Canvas 绘制的所有文本、线条、图形，最终都会调用一个统一的 API。2D 模式下，文字绘制绕不开 CanvasRenderingContext2D.prototype.fillText 和 strokeText。我们可以重写这些方法，在绘图引擎真正画之前，把参数记录下来：

javascript复制const originalFillText = CanvasRenderingContext2D.prototype.fillText;
window.__canvasTexts = [];
CanvasRenderingContext2D.prototype.fillText = function (text, x, y) {
    window.__canvasTexts.push({ text: String(text), x, y });
    return originalFillText.call(this, text, x, y);
};

你可以把它理解为：拦住画家的笔，画家每写一个字，先让旁边的记录员抄一遍再落笔。这样页面渲染结束后，window.__canvasTexts 数组里就存了图表中所有被绘制出来的文字内容，包括坐标轴刻度、数据标签、图例名称。这些数据是精确的字符串，不是截图，不是 OCR 识别结果，比什么都可靠。

这个方法特别适合 ECharts canvas 模式、Chart.js 这类主流图表库，因为它们最后都是通过 fillText 把数值画到画布上。但也有失效的场景，后面我在实战部分详细讲。

2.3 截屏 + OCR 兜底：不依赖图表库的通用方案

钩子方案失效时，兜底方案是截屏 + OCR。思路非常简单粗暴：既然拿不到绘制的矢量数据，那就把 canvas 区域截图下来，再让 OCR 识别图片里的文字。

Selenium 里对 canvas 元素截图非常方便。定位到元素后直接：

python复制canvas = driver.find_element(By.TAG_NAME, 'canvas')
canvas.screenshot('chart.png')

得到图片后，可以用 Tesseract 或者 PaddleOCR 识别。我实测下来，PaddleOCR 对数字的识别精度明显优于 Tesseract，尤其是图表坐标轴上的负数、小数、百分比符号，PaddleOCR 的默认模型靠谱得多。

OCR 方案的优点是通用性强，不管图表是用 2D Canvas、WebGL 还是 CSS 绘制，只要画面能显示出来就能识别。缺点也很明显：返回的是"识别出来的文本"，可能有误差，而且丢失了坐标位置关系，无法知道某个数字属于哪个数据系列。所以这个方案一般用来应急验证，或者作为其他方案补充。

2.4 模拟交互读取 tooltip：单点取数的补充手段

还有一个容易被忽略的入口：tooltip。大部分 Canvas 图表在鼠标悬浮到数据点上时，会弹出一个浮层显示详细数值。这个浮层很多是 HTML DOM 元素，而不是 canvas 绘制出来的，意味着我们可以通过 Selenium 的鼠标操作触发它，再去读取 DOM。

具体操作是：先通过 ActionChains 把鼠标移动到 canvas 的某个像素坐标，触发 mouseover / mousemove 事件，等 tooltip 出现后，在 DOM 里查找 tooltip 节点并提取文本。

这个方案最麻烦的地方在于坐标计算。Canvas 里的数据点位置要么通过图表库 API 拿到，要么得根据图表的坐标轴范围手动换算像素位置。所以它更适合只取图表上几个关键数值的场景，比如"当前环比增长率""累计销售额"这种只显示在图表中央的指标卡，而不是整张图的所有数据点。

2.5 选型结论：按场景组合的策略表

四条路线各有适用场景，我把它们的优先级整理成一个表，方便你遇到实际问题时直接对照：

我的建议是：接口优先，钩子其次，OCR 兜底，tooltip 辅助。实际项目里，四者往往要组合使用，比如先用接口方案拿主数据，再用钩子验证数据准确性，最后用 OCR 抓几个接口里没有的指标。

3. 实战：Selenium 钩子方案完整实现与踩坑记录

3.1 环境准备：Selenium 与浏览器驱动安装中出现频率最高的坑

很多新手在 Selenium 环境搭建上就卡住了，这里先扫一遍常见的坑。

基础安装很简单：

bash复制pip install selenium

难点在浏览器驱动。Chrome 和 Chromedriver 的版本必须匹配，否则启动时会报 SessionNotCreatedException。这个异常信息很明确，一般提示 This version of ChromeDriver only supports Chrome version xxx。解决办法也很简单：到 chromedriver 官方下载地址找到与当前 Chrome 版本号一致的驱动，手动下载后放到一个固定目录，再用 Service 指定路径：

python复制from selenium.webdriver.chrome.service import Service
from selenium import webdriver

service = Service('/path/to/chromedriver')
options = webdriver.ChromeOptions()
options.add_argument("--headless=new")
driver = webdriver.Chrome(service=service, options=options)

如果你用了 Selenium Manager（Selenium 4.6 之后默认自带），大部分情况下驱动会自动下载，但公司内网环境可能访问不了下载源，这时候手动指定 Service 还是最稳的。

另一个高频坑是"headless 模式下页面不渲染 Canvas"。旧版 headless 模式和真实浏览器差别比较大，很多图表库检测到无头环境后干脆跳过渲染。Selenium 4 里推荐用 --headless=new，这是 Chrome 109 之后的新无头模式，行为更接近真实浏览器，Canvas 渲染兼容性好很多。还有个别极端情况，无头模式怎么调都不渲染，那就只能退回到有头模式跑在虚拟显示器上，Linux 下用 xvfb 解决，Windows 下可以跑一个最小化窗口。

3.2 注入绘图钩子的完整代码

先把最常用的方案写出来：代码在页面加载前注入一个 fillText 钩子，然后打开目标图表页面，等渲染完成后读取数据。Selenium 4 里有个特别好用的方法 add_script_to_evaluate_on_new_document，它会在每次新文档加载之前执行脚本，相当于让钩子常驻所有页面，比打开页面后再 execute_script 注入靠谱得多——因为后者时机太晚，图表可能已经画完了。

python复制import time
import json
from selenium import webdriver
from selenium.webdriver.chrome.options import Options

# 配置浏览器
options = Options()
options.add_argument("--headless=new")
# 隐藏自动化特征，减少部分站点对 Selenium 的检测
options.add_argument("--disable-blink-features=AutomationControlled")

driver = webdriver.Chrome(options=options)

# 注入的 JS 钩子：拦截 Canvas 2D 上下文中的文本绘制调用
hook_js = """
window.__chartData = [];
const _fillText = CanvasRenderingContext2D.prototype.fillText;
CanvasRenderingContext2D.prototype.fillText = function(text, x, y) {
    try {
        if (text !== null && text !== undefined) {
            window.__chartData.push({
                text: String(text),
                x: x,
                y: y,
                time: Date.now()
            });
        }
    } catch (e) {}
    return _fillText.call(this, text, x, y);
};
const _strokeText = CanvasRenderingContext2D.prototype.strokeText;
CanvasRenderingContext2D.prototype.strokeText = function(text, x, y) {
    try {
        if (text !== null && text !== undefined) {
            window.__chartData.push({
                text: String(text),
                x: x,
                y: y,
                time: Date.now(),
                mode: 'stroke'
            });
        }
    } catch (e) {}
    return _strokeText.call(this, text, x, y);
};
"""

# 在每次新文档加载前执行钩子
driver.add_script_to_evaluate_on_new_document(hook_js)

# 打开目标图表页面
driver.get("https://target-site.com/chart-page")

# 等页面渲染完成。更稳妥的做法是等待指标出现或轮询检查长度，
# 这里先固定等待，后面我会讲如何做动态等待。
time.sleep(5)

# 读取钩子捕获的数据
data = driver.execute_script("return window.__chartData;")
print("捕获到绘图文本数量:", len(data))
for item in data[:20]:
    print(item)

driver.quit()

这里我同时重写了 fillText 和 strokeText，因为有些图表库的边缘场景会用 strokeText 描边绘制文字，只重写 fillText 会漏数据。记录里加了一个 time 字段，方便后面分析多轮渲染时数据是否重复。

如果因为某些原因用不了 add_script_to_evaluate_on_new_document，还有一个兼容性更好的方案：先打开一个空白页，用 execute_script 注入钩子，再跳转到目标页面。原理是钩子已经存在全局作用域里，跳转后如果页面没刷新全局对象就会保留，但这个方法在目标页面强制刷新时会失效，所以不如第一种稳。

3.3 排查链路：钩子失效、Canvas 被污染、渲染不完整

写完钩子之后，真正让人头疼的是各种奇奇怪怪的失效问题。我把实际排查过程完整拆一遍。

第一个问题是钩子完全没有生效，window.__chartData 返回 null。排查链路是这样的：

1. 先在页面打开控制台手动执行一遍钩子，确认页面里确实存在 CanvasRenderingContext2D.prototype，而且页面确实在用 2D 绘图。如果页面用的是 WebGL 渲染，getContext('2d') 返回 null，图表走的是 GPU 管线，fillText 钩子自然不起作用。
2. 检查钩子注入时机。如果页面已经完成绘制后才 execute_script，那就晚了。必须用 add_script_to_evaluate_on_new_document 或者页面跳转前注入。
3. 检查是否被页面自带的事件覆盖。有些网站会动态加载图表库，图表库内部可能也重写了 Canvas 原型方法，导致我们的钩子被覆盖。解决方法是把钩子放到一个 setInterval 里，每隔一段时间重新注入一次，确保在图表渲染前能抢占原型方法。

第二个问题是 canvas.toDataURL 报 SecurityError，也就是常说的"画布被污染"。这个问题的典型场景是：canvas 里绘制了跨域的图片素材，浏览器安全策略会认为画布已经不可信，想导出数据就会抛异常。排查方法是在渲染前给 canvas 元素加上 crossOrigin = 'anonymous'，但前提是图片服务器返回了正确的 CORS 头，否则加了这个属性图片直接加载失败。真实的报表系统里 CORS 头往往不可控，所以我对 toDataURL 的态度是：能绕过就绕过，填了钩子拿文本数据，别依赖截图导出。

第三个问题是数据不全。最常见的原因就是等待时间不够，页面数据是异步加载的，图表分两三次渲染，第一次画框架，第二次填充数据，第三次更新动画。我吃过这个亏：固定 sleep 3 秒后采集，结果只拿到坐标轴的"0、100、200"这些刻度，数据标签一个都没有。后来我改成轮询检查数据的稳定性：

python复制def wait_for_chart_data(driver, min_count=10, stable_rounds=3, timeout=30):
    last_len = -1
    stable_count = 0
    start = time.time()
    while time.time() - start < timeout:
        current = driver.execute_script("return (window.__chartData || []).length;")
        if current == last_len and current >= min_count:
            stable_count += 1
            if stable_count >= stable_rounds:
                return True
        else:
            stable_count = 0
        last_len = current
        time.sleep(0.5)
    return False

这个思路是：只有当连续几轮数据长度不变、且总量大于阈值时，才认为渲染已经稳定。这样既不会在渲染中途抓漏，也不会为了等一个不存在的"加载完成标志"而卡死。

3.4 补充方案：无头模式截图与 OCR 的配合

当钩子方案确实走不通时，我会启动 OCR 兜底链路。完整的流程是：无头模式加载页面 → 等待 canvas 渲染完成 → 对 canvas 截图 → 预处理图片 → OCR 识别。

截图和识别的代码：

python复制from selenium.webdriver.common.by import By

canvas = driver.find_element(By.TAG_NAME, 'canvas')
canvas.screenshot('chart.png')

# 可选：用 PIL 对图片放大增强，提升 OCR 精度
from PIL import Image
img = Image.open('chart.png')
# 放大两倍，减少小字号的识别误差
img = img.resize((img.width * 2, img.height * 2), Image.LANCZOS)
img.save('chart_zoom.png')

OCR 部分我推荐 PaddleOCR，识别效果和易用性都不错：

python复制from paddleocr import PaddleOCR

ocr = PaddleOCR(use_angle_cls=True, lang='ch', show_log=False)
result = ocr.ocr('chart_zoom.png', cls=True)

texts = []
for line in result:
    if line:
        for word in line:
            texts.append(word[1][0])
print(texts)

实际使用中有两个经验。一是数字识别率通常 90% 以上，但"0"和"O"、""6""和""8""在某些字体下容易混淆，所以 OCR 输出后一定要和业务逻辑做校验，比如数据范围、求和校验。二是中文坐标轴标签的识别率受字体影响很大，如果图表用的是细字体，识别结果可能缺字，可以在预处理时做二值化或者锐化。

OCR 方案最大的价值在于：它不依赖图表库的实现细节，只要是显示在屏幕上的文字，理论上都能识别。虽然精度不如钩子方案，但作为应急兜底完全够用。

4. 工程化落地与反爬对抗：稳定性和合规边界

4.1 让爬虫跑得稳：等待策略、资源回收、运行监控

写完了能跑通的主流程，接下来要考虑的是怎么让它长期稳定运行。我帮别人维护过好几个类似的数据采集脚本，总结下来有四个地方必须处理。

第一，等待策略不要用固定 sleep。虽然前面给了 time.sleep(5) 这种示例，但实际线上环境网络波动很大，固定等待要么太快导致数据不全，要么太慢浪费大量时间。核心思路是动态等待：要么等 DOM 里某个隐藏的"加载完成"标志出现，要么像我前面写的那样轮询检查捕获数组的长度是否稳定。

第二，单个浏览器进程跑太久会越来越慢，内存占用飙升，最终导致崩溃。我通常的做法是：每抓取 N 个页面或每隔一定时间，主动重启浏览器。重启后要重新注入钩子，但钩子是在 add_script_to_evaluate_on_new_document 里注入的，新浏览器实例启动时再调一次就行，代码上不复杂。千万不能让一个无头浏览器连续跑一天一夜，谁跑谁知道。

第三，异常处理一定要分层。Selenium 常见的异常有 TimeoutException、ElementClickInterceptedException、WebDriverException，每个都可能是不同原因引起的。我的习惯是：最外层捕获所有异常并记录到日志，同时把当前页面截图存下来，方便事后分析是页面改版了还是网络波动。

第四，断点续爬。如果采集范围很大，建议每次落盘时都带一个任务标识，比如按日期、按数据源生成独立文件，采集过程中记录当前进度，重跑时只补增量。这样即使中途挂了，也不用从头再来。

4.2 反爬识别与规避：webdriver 特征、指纹伪装与频率控制

Selenium 最明显的特征是 navigator.webdriver 属性为 true。很多前端 JS 会检查这个属性，一旦发现就拒绝渲染图表或者强行清空 canvas。规避思路主要有两个：启动参数隐藏和 CDP 运行时删除。

启动参数层面，加上这个参数能减少大部分检测：

python复制options.add_argument("--disable-blink-features=AutomationControlled")

但还不够。更彻底的方法是通过 Chrome DevTools Protocol 在页面加载前执行一段脚本，把 webdriver 属性删掉：

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

注意这个操作要在 driver.get() 之前执行，否则页面已经加载完了，属性删不删都没意义。

频率控制是另一个容易被忽视的维度。很多爬虫不是被识别抓到的，而是被访问频率规律出卖的。比如一个报表系统，正常用户每 5 分钟刷新一次，你的脚本 0.1 秒内连续请求 10 个页面，这特征太明显了。我在脚本里强制要求每个页面之间随机等待 3 到 7 秒，并且把这个等待时间写进日志，方便回看时判断是否有异常。

还有一个容易被忽略的点：canvas 本身就能作为浏览器指纹的一部分。有些网站会先把文字画到 canvas 上，再通过 toDataURL 获取像素哈希值，作为设备标识。如果你的脚本每次跑的 canvas 指纹和真实浏览器不一致，风控系统可能把你识别为异常设备。尽量避免频繁更换分辨率、UA、渲染模式，保持环境稳定反而更安全。

4.3 合规边界：哪些事情不能碰

写数据采集的人，心里一定要有一根弦。技术是中性工具，但使用场景决定了合规性。这里说得直白一点：

第一，只采集你自己有权限访问的数据。公司内部的报表系统，如果你有账号权限，出于工作自动化需求去做采集，这属于职责范围内的合理操作，但最好先和相关负责人确认一下，别自己闷头写。

第二，不要用脚本大量并发请求目标服务器。无论数据是否公开，对服务器造成压力的行为都容易引发法律风险和 IP 封禁。控制频率、控制并发量，是基本的礼仪。

第三，很多网站的注册条款和服务协议里明确禁止自动化采集。比如大量招聘平台、交易平台，协议里都写了不能用爬虫。在开始爬之前，先花几分钟看看目标网站的 robots.txt 和服务条款。如果协议明确禁止，除非你是为了安全研究且已获得授权，否则尽量打消这个念头。

第四，不要采集个人隐私数据、账号密码、身份信息等。这类数据即使技术上能拿到，也可能踩到法律红线。做技术分享时也尽量不要拿真实网站的数据做演示，用本地起的测试页面或者模拟数据更安全。

最后再分享几点实际体会

踩过几次坑之后，我的习惯是：遇到 canvas 图表先做三件事——打开控制台看 Network 里有没有明文接口，搜一下页面 JS 里有没有 fillText 或 echarts.init 之类的特征字符串来判断图表库类型，然后再决定是走接口还是走钩子。能在接口层解决的事，绝不去 canvas 层面硬啃。这个思路能帮你省下大量调试时间。

最后再分享一个小技巧：分析页面 JS 文件时，搜 new Chart、echarts.init、Chart.defaults 这些特征字符串，能快速判断图表库版本。不同库的绘图调用方式不一样，钩子代码也需要微调。比如 ECharts 的 canvas 模式下，坐标轴刻度标签的绘制时机和数据标签不同，如果你发现捕获到的文本只有坐标轴没有数据标签，多半是 fillText 方法被图表库二次封装了，需要在捕获时加一层调用栈过滤。如果图表用的是自定义 WebGL 渲染，那就别在 canvas 层浪费时间，老老实实从数据接口入手。

这套方法论我反复用在不同项目里，从内部报表到公开数据平台都验证过。遇到难啃的 canvas 图表时，别慌，把链路拆开一层层试，最后总能找到突破口。希望这篇内容能让你少走弯路。