企业官网建设流程全解析

入行自动化测试这几年，遇到最多也最让人头疼的一个场景就是各种验证码。数字的、滑块的、算数的还算好对付，真正让我卡了好几个晚上的是“中文点选”——页面上出一张乱序文字图，让你按顺序点击“技、术、创、新”之类的文字。手动点太费劲，写脚本去点又需要同时解决识别精度和点击坐标换算的问题。这篇就记录一下我最终用 DrissionPage 把整个流程跑通的全过程，包括完整代码、坐标计算方式、踩过的那些坑，以及轮滚、iframe、动态加载这类高频问题怎么处理。如果你是做自动化办公、内网系统自动化、或单纯想学 DrissionPage 操作网页元素的，这篇可以直接照着抄。

1. 整体设计与思路拆解

1.1 中文点选验证码到底在验证什么

先搞清楚原理，脚本才能写得顺。中文点选验证码本质上是一个“图片 + 文字提示 + 点击坐标”的组合验证。系统生成一张背景图，背景上散落着若干汉字，同时在提示区告诉你需要按什么顺序点，比如“请依次点击：中 文 验 证”。你点的顺序、点的位置都要匹配才能通过。因为汉字不是简单滑块那种规则形状，识别难度比数字字母要高，很多自动化工具在这种验证码前面直接从“工具”变“人工”。

它的判定逻辑一般是：后台在生成验证码图片时，会记录每个文字在图片中的真实坐标。你提交的坐标如果与真实坐标距离小于某个阈值，并且顺序正确，就判定通过。所以我们的自动化目标非常明确：拿到图片 → 找出文字坐标 → 按提示顺序模拟点击。

这里有一点必须说在前头：我只在自己负责维护、有明确授权的内部业务系统和本地测试环境上做这套自动化，这也是我写代码前一直坚持的红线。大家如果要复用，一定要先确认目标系统的使用条款和授权边界，别拿这个去对付没有权限的站点。

1.2 为什么选 DrissionPage 而不是 Selenium

做网页自动化，最多人提的就是 Selenium，但我在这个项目里选择 DrissionPage，主要是三个原因。

第一，DrissionPage 不依赖 WebDriver。Selenium 每次都要下载和浏览器版本严格匹配的 chromedriver，换个浏览器版本就要重来一遍，内网环境还不一定能下载。DrissionPage 直接通过浏览器 DevTools 协议控制 Chromium 内核，启动快、免驱、版本兼容性明显好。

第二，元素定位语法更贴近人话。DrissionPage 的ele()方法用css:、xpath:、@属性、文本查找等做前缀就能定位，而且一个方法同时支持单个元素和等待条件，写起来省很多代码。

第三，交互能力更顺手。DrissionPage 的click()方法原生支持相对元素左上角的偏移坐标点击，这个特性在点选验证码场景里简直是救命的，不用自己去算浏览器边框、页面滚动、元素偏移这些乱七八糟的偏移量。

1.3 整体自动化流程怎么拆

一套完整的流程，我拆成了四步：

1. 打开登录页，定位到验证码图片元素，并把它截取成图片数据。
2. 对图片做识别，拿到提示文字在图片内的坐标。
3. 通过 DrissionPage 的偏移点击，模拟鼠标点这几个坐标点。
4. 提交表单，判断是否成功；不成功就刷新验证码重新来。

这四个环节里，最容易出问题的是第二步识别和第三步坐标换算。识别不准后面全白搭，坐标换算错一个像素点击也会偏移，所以我下面会分别把这两个关键环节的代码和计算过程完整展开。

2. 环境准备与 DrissionPage 基础操作

2.1 环境安装与浏览器初始化

环境要求其实很低，Python 3.8 以上就行。我本地用 Windows 11 做开发，服务器上放了个 Linux 环境跑定时任务，DrissionPage 两个平台都支持得很好。

pip install DrissionPage

装完后，它会自动下载匹配的 Chromium 内核。如果你本机已经有 Chrome，也可以直接接管现有浏览器进程，这在调试脚本时特别方便，能看到每一步的实际点击轨迹。

from DrissionPage import ChromiumPage, ChromiumOptions # 方式一：启动一个全新页面 page = ChromiumPage() # 方式二（调试推荐）：接管本机已打开的 Chrome # 先用命令行启动 Chrome 带远程调试端口，再用下面的代码连接 # chrome --remote-debugging-port=9222 # page = ChromiumPage(addr_or_opts='127.0.0.1:9222')

第一次跑的时候建议用“方式二”，因为脚本点击时你能肉眼看到整个浏览器操作过程，哪个坐标点偏了、哪个文字没识别到，一目了然。等代码稳定了再改成新开页面全自动。

启动浏览器后，访问登录页：

page.get('https://example.com/login') page.wait(2)

2.2 定位验证码元素并截图

中文点选验证码在 DOM 里一般是一个<img>标签或者一个带背景图的div。我在实际项目里遇到的是一个div包裹的 canvas 图片区域。用 DrissionPage 定位非常直接：

# 根据 class 定位验证码图片区域 code_elem = page.ele('css:.verify-code', timeout=10) # 截图并转成图片数据，注意这里是元素截图，不是整页截图 img_bytes = code_elem.get_screenshot(as_bytes='png')

get_screenshot(as_bytes='png')返回的是 PNG 格式的二进制数据，后面接 OpenCV 就能把数据流转成图片矩阵。这里要注意：一定是对元素本身截图，而不是对整个页面截图再裁剪。整页截图的像素和页面滚动位置强绑定，坐标换算会多出不少麻烦，元素截图直接得到局部图片，坐标计算简单很多。

2.3 页面滚动与滑滚轮操作

搜索热词里出现了“drissionpage 滑动滚轮”，这里是真实高频需求，因为验证码不一定总在第一屏。如果登录页较长，验证码被折叠在下方，直接截图会截出空白区域，点选坐标也会整体偏移。这时候必须先滚动页面。

DrissionPage 里滚动有两类思路，一种是直接控制页面滚动条，另一种是用鼠标滚轮动作模拟真实交互。我按场景分别说下。

第一种，页面滚动条直接滚动：

# 滚动到底部 page.scroll.to_bottom() # 滚回顶部 page.scroll.to_top() # 向下滚动 500 像素 page.scroll.down(500) # 向上滚动 300 像素 page.scroll.up(300)

第二种，模拟鼠标滚轮：

# 在当前位置执行滚轮动作，第一个参数是水平偏移，第二个是垂直偏移 # 正数代表向下滚，负数代表向上滚 page.actions.wheel(0, 500)

两种方式什么区别？如果是普通的长页面，page.scroll.to_bottom()足够了。但有些页面监听了鼠标滚轮事件，监听逻辑写在wheel事件里，用scroll()直接改滚动条位置不会触发事件，页面内容可能不会按预期加载。这时候就必须用page.actions.wheel()模拟真实的滚轮操作，让页面认为用户真的在滚鼠标。

我遇到过一个场景：页面上半部分是表单，下半部分是验证码，验证码区域用懒加载实现了，必须滚到附近才动态生成。用scroll.down(500)好几次都没触发加载，换成page.actions.wheel(0, 500)就正常了。排查原因就是页面绑定了 wheel 事件去触发加载逻辑。

另外，如果你要点击的元素可能不在当前视口内，DrissionPage 的click()其实会自动把元素滚动到可见区域再点击，但为了截图坐标准确，我还是建议先手动让验证码区域完整露出视口，再进行截图和后续偏移点击，避免意外滚动导致的坐标错位。

3. 中文点选验证码的识别与点击实现

3.1 两种识别方案怎么选

拿到验证码图片后，核心任务就变成了“找字”。目前主流方案有两种。

第一种是模板匹配。提前准备好每个汉字的图片模板，然后用 OpenCV 的matchTemplate在验证码背景图里找最匹配的位置。优点是完全离线运行，速度快、可控性强；缺点是需要提前准备模板，而且模板风格和验证码字体差异大的时候准确率会下降。

第二种是深度学习 OCR。可以用ddddocr这种开箱即用的库，它自带目标检测模型，可以直接返回图中每个文字的外框坐标。优点是省去准备模板，对多种字体泛化能力好；缺点是依赖模型文件，第一次运行要下模型，有些内网环境不方便，而且结果偶尔会带误差。

我的建议是：如果你只针对一个固定的业务系统做自动化，验证码字体和背景风格基本不变，用模板匹配最稳，可控性最强。如果做的是一个通用工具，可能面对不同站点，那就上 OCR 识别，省事但需要容忍一定的准确率波动。下面两个方案的代码我都贴出来。

3.2 方案一：OpenCV 模板匹配实现点选识别

先准备模板。我是在验证码图片样本里把每个字裁剪出来保存成模板图，比如muban/中.png、muban/文.png。模板图片最好能包含文字本身的轮廓，背景尽量干净。

import cv2 import numpy as np from io import BytesIO def img_bytes_to_cv2(img_bytes): """将 DrissionPage 截图得到的 bytes 转成 OpenCV 图像矩阵""" return cv2.imdecode(np.frombuffer(img_bytes, np.uint8), cv2.IMREAD_COLOR) def match_single_word(bg_img, template_img, threshold=0.85): """ 在背景图中匹配单字模板，返回中心坐标 阈值 threshold 表示匹配相似度，越大越严格 """ result = cv2.matchTemplate(bg_img, template_img, cv2.TM_CCOEFF_NORMED) _, max_val, _, max_loc = cv2.minMaxLoc(result) if max_val < threshold: return None, max_val h, w = template_img.shape[:2] # 计算出模板左上角位置后，转为中心点坐标 center_x = max_loc[0] + w // 2 center_y = max_loc[1] + h // 2 return (center_x, center_y), max_val

这段代码里最关键的是cv2.matchTemplate。它的原理是把模板图在背景图上逐像素滑动，每滑到一个位置计算一次相似度，最终得到一个响应矩阵，cv2.minMaxLoc取出相似度最高的位置和值。如果这个最高值低于阈值，说明图片里可能没有这个字，或者说背景干扰太强把真正的文字位置盖过了。

接下来组合出一个完整的识别函数。假设验证码提示区给了一串需要点击的文字，比如“请依次点击：技 术 创 新”，程序提取出这四个字，依次去匹配：

def extract_click_words_from_tip(tip_text): """ 从提示文本中提取需要点击的汉字列表 具体提取规则要根据实际页面结构来写，示例：去掉前缀提示词后按空格拆分 """ prefix_keywords = ['请依次点击', '请按顺序点击', '请点击'] for kw in prefix_keywords: if kw in tip_text: tip_text = tip_text.replace(kw, '') # 去掉冒号、逗号、空白字符 for ch in ['：', ':', '，', ',', ' ']: tip_text = tip_text.replace(ch, '') return list(tip_text)

然后用一个循环去匹配并保存结果：

tip_text = '请依次点击：技 术 创 新' click_list = extract_click_words_from_tip(tip_text) bg_img = img_bytes_to_cv2(img_bytes) match_points = [] for word in click_list: template_img = cv2.imread(f'templates/{word}.png') point, score = match_single_word(bg_img, template_img, threshold=0.82) if point is None: print(f'文字 {word} 匹配失败，最高相似度 {score:.3f}') continue match_points.append(point) print(f'文字 {word} 匹配成功，坐标 {point}，相似度 {score:.3f}')

匹配失败的情况很常见，尤其背景图和模板图风格不完全一致的时候。我的经验是阈值先设 0.8，一次失败了打印出相似度，再根据日志把阈值往下调或者优化模板。

3.3 方案二：ddddocr 目标检测识别

如果你不想准备模板，下面的方式更省事。ddddocr有一个 det 模式，专门做验证码文字检测，会返回每个文字的外框坐标。

pip install ddddocr

import ddddocr # 初始化检测模型，det=True 表示启用目标检测 ocr = ddddocr.DdddOcr(det=True, ocr=False) def detect_words_by_ddddocr(img_bytes): """ 使用 ddddocr 目标检测识别图片中的文字位置 返回格式：[{'box': [x1, y1, x2, y2], 'text': '中'}, ...] """ results = ocr.detection(img_bytes) word_positions = [] # results 的格式是 [[x1, y1, x2, y2], ...] for box in results: x1, y1, x2, y2 = box center_x = (x1 + x2) // 2 center_y = (y1 + y2) // 2 # 如果要文字内容，可以再用 ocr=True 识别每个裁剪区域 word_positions.append({ 'box': box, 'center': (center_x, center_y), }) return word_positions

ddddocr 的目标检测返回的是图片中“疑似文字”的区域框，它不负责判断这个字是不是提示里要点的那个字。要精确把“中”字和图片中的“中”区域对应起来，更严谨的做法是把每个检测框裁剪出来，再用识别模式ocr=True识别框内文字，然后与提示文字比对。这样准确率会好很多，但对性能要求高一点。

考虑到大部分固定业务系统验证码字体、风格都固定，我的个人项目最终选了方案一，因为模板一旦做好，后续识别速度非常快，而且不会受到外部模型服务的影响。

3.4 坐标换算与偏移点击

识别出图片内的坐标只是第一步，真正点击的时候，页面左上角坐标并不等于图片左上角坐标。因为验证码<div>在页面上有它自己的位置。需要把“图片内坐标”转成“元素内偏移坐标”。

DrissionPage 的click(offset=(x, y))方法，接收的是相对元素左上角的偏移量。所以我们只需要把识别到的图片内坐标原样传给 offset 就行，它自动帮我们处理了“元素在页面中的位置”这一层关系。

这里要特别提一个像素缩放问题。某些高分屏（比如 Windows 下的 125%、150% 缩放）或者浏览器页面设置了缩放比例，会导致截图图片的实际尺寸和页面布局尺寸不一致。比如截图是 300 像素宽，但页面上元素看起来是 375 像素宽，直接按截图像素传 offset 就会点歪。

解决思路是计算缩放比例：

def get_scale_ratio(code_elem, img_width, img_height): """ 根据元素在页面的实际大小与截图像素大小，计算缩放比例 code_elem: 验证码元素 img_width, img_height: 截图图片的宽高（像素） """ # 元素在页面中的实际尺寸 element_size = code_elem.size scale_x = element_size[0] / img_width scale_y = element_size[1] / img_height return scale_x, scale_y

得到比例后，点击坐标按比例换算：

def page_offset_from_img_center(center, scale_ratio): """图片内中心坐标 -> 元素内偏移坐标""" sx, sy = scale_ratio return (center[0] * sx, center[1] * sy)

然后执行点选。为了让行为更接近真人，我每次点击之间加了随机间隔：

import random import time for word, point in zip(click_list, match_points): offset = page_offset_from_img_center(point, scale_ratio) code_elem.click(offset=offset) print(f'已点击 {word}，偏移坐标 {offset}') # 随机等待 0.3~0.8 秒 time.sleep(random.uniform(0.3, 0.8))

这里code_elem.click(offset=offset)是 DrissionPage 的一个特别方便的方法，它会先保证元素可见，然后移动到元素左上角再加偏移量进行点击。不过要注意，offset 的坐标系是“物理像素”还是“CSS 像素”，取决于页面是否有缩放。所以我上面先拿到了页面元素的实际尺寸和截图尺寸，计算出 scale_ratio 再把坐标乘上去，就是为了规避这些环境差异。

3.5 提交表单、失败刷新与完整主流程

点选完成后，正常流程就是点登录/提交按钮，然后判断是否通过验证码验证。判断方式一般是看是否出现了新的错误提示，或者看地址栏有没有跳转。

一个比较稳的完整流程是写一个循环，最多重试 N 次。如果验证码失败了，就点击验证码图片本身来刷新，然后重新识别：

def auto_click_verify(max_retry=5): """ 自动完成中文点选验证码并尝试提交 """ for attempt in range(1, max_retry + 1): try: print(f'第 {attempt} 次尝试') # 1. 定位验证码元素并截图 code_elem = page.ele('css:.verify-code', timeout=10) img_bytes = code_elem.get_screenshot(as_bytes='png') # 2. 识别文字坐标（这里走模板匹配方案） bg_img = img_bytes_to_cv2(img_bytes) tip_text = page.ele('css:.verify-tip', timeout=5).text click_list = extract_click_words_from_tip(tip_text) match_points = [] for word in click_list: template_img = cv2.imread(f'templates/{word}.png') point, score = match_single_word(bg_img, template_img, threshold=0.82) if point is None: raise ValueError(f'{word} 匹配失败，score={score:.3f}') match_points.append(point) # 3. 计算缩放比例 img_h, img_w = bg_img.shape[:2] scaled_x, scaled_y = get_scale_ratio(code_elem, img_w, img_h) scale_ratio = (scaled_x, scaled_y) # 4. 依次点击 for word, point in zip(click_list, match_points): offset = page_offset_from_img_center(point, scale_ratio) code_elem.click(offset=offset) time.sleep(random.uniform(0.3, 0.8)) # 5. 点击登录/提交按钮 submit_btn = page.ele('css:.login-btn', timeout=5) submit_btn.click() # 6. 判断是否成功，这里用页面标题或特定元素判断 page.wait(2) if '欢迎' in page.title: print('登录成功') return True # 失败则刷新验证码，重新循环 print('验证码验证失败，刷新重试') code_elem.click() page.wait(random.uniform(1.0, 1.5)) except Exception as e: print(f'本次尝试异常: {e}') # 重新加载页面需要小心，重试太频繁容易被限制 time.sleep(2) return False

这个主流程基本是完整可直接跑的。几个变量的选择需要根据实际页面调整：验证码元素的标识（css 选择器）、提示文字元素的选择器、提交按钮的选择器、成功判断条件。这些在第一次写脚本时，建议用接管模式配合page.ele逐个打印排查，确定准确后再集成进循环。

4. 踩坑记录与常见问题排查实录

4.1 验证码元素总是定位不到

这个问题大概率出在 iframe 嵌套上。很多业务系统的登录页把验证码放在 iframe 里，DrissionPage 默认操作主文档，直接在主文档里找 iframe 内部的元素自然找不到。

解决办法是先切换进入 iframe：

# 通过 iframe 元素进入 iframe = page.ele('css:iframe[src*="captcha"]') page = iframe # DrissionPage 中 frame 对象可以直接作为当前页面操作 # 注意：这种写法只对 DrissionPage 有效 code_elem = page.ele('css:.verify-code', timeout=10)

如果你发现切换后仍然找不到，可能页面还有层叠 iframe，那就一层一层切，切一层定位一次，实在不行就用page.get_frame()相关方法遍历 iframe。

还有一种情况是元素在动态加载之前不存在。我的经验是：先加上等待，等验证码区域稳定后再定位。用page.ele("css:.verify-code", timeout=10)其实已经带了最长等待时间，但有些页面的验证码是通过 ajax 异步加载的，等待时间不够就定位不到，可以适当把 timeout 放大到 15 秒，并配合page.wait.load_start()等页面加载完成事件。

4.2 识别准确率忽高忽低

模板匹配方案里，准确率不稳定最常见的原因是背景干扰。有些验证码背景做了复杂的干扰线、噪点，matchTemplate会把干扰线误判成文字。我的处理办法有两个。

第一个是预处理。用 OpenCV 把验证码图片做灰度化、二值化，减少背景颜色干扰，然后再进行模板匹配。模板也要做同样的预处理，两者在同一色彩空间下匹配，准确率能提高不少：

def preprocess(img): # 转为灰度图 gray = cv2.cvtColor(img, cv2.COLOR_BGR2GRAY) # 二值化，黑白分明 _, binary = cv2.threshold(gray, 180, 255, cv2.THRESH_BINARY) return binary

第二个是阈值调节。把threshold从 0.85 调到 0.75 甚至 0.7，看匹配结果。我在本地实验时，发现有些字因为模板截图和实际字体有细纹差异，最高相似度只有 0.81。强行用 0.85 会导致这个字永远匹配不上，这时需要把阈值降低，但也不能太低，否则背景中的形近字会被误判。

另外，模板图和实际验证码字体风格必须一致。同一个“技”字，如果验证码是宋体，你准备的是黑体模板，matchTemplate几乎不可能匹配成功。所以制作模板时一定要从同源验证码截图里抠图，不要拿系统字体去生成模板。

4.3 点击总是偏一点，但坐标看起来没问题

坐标对但点不准，十有八九是缩放比例的问题。Windows 的“显示缩放”会让浏览器页面的 CSS 像素和截图物理像素不一致。截图返回的是一张像素图，它的像素密度是设备像素；而 DrissionPage 的点击 offset 通常基于 CSS 像素。如果不做换算，所有点击点在 CSS 像素坐标系下都会偏离，而且越往右下角偏得越厉害。

解决方法是先拿一个已知位置的元素做标定。比如验证码区域里如果有某个固定装饰图标，你先从截图里找到它的中心坐标，再对比页面元素实际位置的差值，算出横纵两个方向的缩放系数。这种方法比单纯看操作系统缩放设置要可靠得多。

还有一点是浏览器缩放快捷键 Ctrl + 加减号改变了页面比例，也会导致同样的误差。脚本调度前如果手动缩放过浏览器，建议先恢复 100% 缩放，或者直接用ChromiumPage()每次新开一个干净的浏览器进程。

4.4 常见问题速查表

4.5 我踩过比较深的一个坑：验证码“点对了还是失败”

有段时间脚本跑得很顺，但突然某天开始，点选坐标全部正确，提交后却总是提示“验证码错误”。排查到最后，发现是这个业务系统的验证码有一个隐藏的“语义顺序”校验。提示文字是“请依次点击：科 技 创 新”，系统要求四个字都点，但它校验的是“点选完成后鼠标轨迹是否符合从左上到右下的视觉顺序”，而不完全是后台记录的坐标顺序。

这听起来很绕，但实际影响是：如果四个字分布在不同方位，你按提示文字顺序点击，系统却能检测出鼠标点击轨迹的连续性异常，判定为机器操作。解决办法是把点击顺序稍微调整，不完全按提示顺序，而是先模拟一次“人工浏览”的移动轨迹：先在验证码区域中心悬停片刻，再依次点击。代码层面就是额外添加page.actions.move_to()动作，在每次点击前先移动到目标点附近，再重新点击。这样点击轨迹更接近真人，验证通过率从 60% 提到了 90% 以上。

for word, point in zip(click_list, match_points): offset = page_offset_from_img_center(point, scale_ratio) # 先移动过去，模拟人眼定位 code_elem.hover(offset=offset) time.sleep(random.uniform(0.2, 0.5)) code_elem.click(offset=offset) time.sleep(random.uniform(0.3, 0.8))

类似的坑还有很多，比如有些验证码会记录两次点击之间的最短最小间隔，低于 0.2 秒直接判定机器操作；有的验证码会检测鼠标移动的加速度曲线。这些都属于反自动化策略，没有统一解，只能根据实际页面的行为去适配。我的经验是：不要一上来就写满“随机”,先手动操作一遍，记下自己点每个字之间的时间差和鼠标停顿感，再把这些参数写进脚本。

5. 个人总结与后续扩展建议

整个项目从开始到稳定运行，我花了两个晚上，大部分时间都耗在坐标换算和验证码刷新逻辑上。最后跑稳定之后，登录一个原本要点十几秒验证码的系统，脚本能做到 5 秒内完成识别、点选、登录，成功率高的时候连续跑几十次不出问题。

我个人最大的体会是：DrissionPage 这套工具在“点击偏移”和“元素截图”这两个能力上，确实比 Selenium 顺手太多。验证码类自动化最痛苦的从来不是识别模型，而是“识别结果”和“页面点击”之间的坐标协调，DrissionPage 把这一层做得很干净。如果你后续要写滑块验证码、图标点选、甚至复杂的拖拽交互，这套流程的框架基本都能直接套用，要换的只是识别部分的算法和模板。

最后再分享一个小技巧：不要在脚本里把验证码刷新逻辑写成“失败就重试”的无限循环，最好加上最大重试次数和每次失败后的递增等待时间（比如第一次等 1 秒，第二次等 3 秒，第三次等 5 秒），否则遇到验证码服务暂时故障时，脚本会以很高频率刷新，容易被系统风控识别并临时封锁 IP。这种问题一旦发生，排查起来比改代码还麻烦。改成递增等待之后，脚本不仅更稳，也更有“人味”，长时间运行的安全性也高得多。