企业官网建设流程全解析

做自动化流程的人大概都遇到过这种卡点：脚本跑到登录页，前面一路顺畅，最后被一个四位数的小图片拦住，整个流程直接僵住。我最初碰验证码也是为了这个——一批需要反复登录的自有系统做回归测试，人工敲一次两次还行，跑一轮几十个用例就崩了。后来一路从模板匹配摸到卷积网络，踩了不少坑，也积累了一些在文档里查不到的经验，这篇就把python识别验证码这件事从头到尾掰开讲一遍。

先把话说清楚：验证码识别在技术上属于典型的图像预处理 + 字符定位 + 分类识别三段式问题，跟人脸识别、车牌识别在方法论上是同源的，只是干扰更强、样本更脏、容错更低。它不是一个"调个库就完事"的任务，但也没有想象中那么玄。这篇文章适合三类人看：有 Python 基础想练手计算机视觉的；做自动化测试、需要在自有或已授权系统上跑通流程的；以及想理解一个图像分类模型从数据到上线完整链路的。零基础也能跟，我会把每个参数为什么这么设讲明白。

1. 先把问题拆开：验证码识别到底难在哪

很多人第一次做这个，思路是"找个 OCR 库，把图丢进去，拿结果"。跑十张能对三张，然后就开始怀疑人生。问题不在库，在于没有先判断自己面对的是哪一类问题。验证码这个筐里装的东西差别极大，字符粘连的、带干扰线的、字符旋转的、背景有噪点的、甚至是行为式的，处理路线完全不是一回事。先分类，再选路，这是省时间的唯一办法。

1.1 四类常见验证码，四套完全不同的打法

我按处理难度从低到高排一下，你可以对着自己的目标图先归个类。

这个表的意义在于帮你止损。如果你手上的图属于第一类，用 OpenCV 写五十行代码就解决了，上深度学习纯属浪费；反过来，如果属于第三类，你死磕投影切分法会卡死在"字符粘在一起分不开"这一步，怎么调参数都没用，因为信息在切分阶段就已经丢了。

提示：先拿 20 张样本图，用画图工具放大看清楚——字符是等宽的吗？有倾斜吗？干扰线和字符的颜色差异大吗？这三个问题的答案基本决定了你的技术路线。

1.2 为什么我不建议新手直接上深度学习

我见过太多人第一步就是去找个开源模型、拉一批数据、开训。结果呢？训练集准确率 99%，测试集 60%，然后开始怀疑模型结构、换骨干网络、调学习率，折腾一周毫无进展。

根子通常在数据侧，不在模型侧。你要识别的那类图，样本是你自己攒的，几十张到几百张，类别分布还极不均衡（数字 1 出现得少，0 出现得多）。在这种数据量下，一个精心调过的传统方法往往吊打一个胡乱训的深度模型。

我的建议是阶梯式推进：先用传统方法跑出一个基线，哪怕只有 60% 准确率，你也有了对照；再上模型，看提升多少；如果提升不明显，说明瓶颈在预处理和数据，不在模型容量。这套流程看着笨，但它能让你每一步都知道自己在改什么，而不是在黑暗里乱撞。

另外一个现实因素是调试成本。传统方法的中间结果——二值图、去噪图、切分结果——全是可以直接存成图片看的东西，出问题一眼就能定位到哪一步。深度模型是个黑箱，你只能看 loss 曲线猜。新手用黑箱调试，效率极低。

2. 环境搭建与工程结构：把脏活提前干完

工具链这块我不想写得太啰嗦，但有几个版本坑必须提前说，否则你会在一个莫名其妙的报错上耗掉半天。我自己就被 OpenCV 的读写路径问题坑过两次，中文路径读进来是 None，排查了四十分钟才发现是编码问题。

2.1 依赖选型与版本踩坑

核心就四个包，够用了：

pip install opencv-python numpy pillow torch torchvision

逐个说一下选型理由。OpenCV负责所有图像层面的操作，二值化、滤波、形态学、连通域、轮廓，它的 C++ 底层让批量处理几百上千张图时速度完全够用，纯 Python 的 PIL 做同样的事会慢一个数量级。NumPy是底层数据结构，OpenCV 读进来的图本身就是 ndarray，投影计算、掩膜操作全靠它。Pillow不是必须的，但它的 Image 对象在跟一些库对接时更方便，而且处理中文路径比 OpenCV 稳。PyTorch是后面训模型用的，如果你只做传统方法，这个可以不装。

版本上要注意三点：

• opencv-python和opencv-contrib-python不要同时装，会互相覆盖导致某些函数找不到。需要 SIFT 之类的扩展算法就只装 contrib 版本。
• OpenCV 4.x 里cv2.findContours只返回两个值（contours, hierarchy），网上大量 3.x 时代的老代码返回三个值，直接抄会报 unpack 错误。
• PyTorch 装 CPU 版就够跑验证码这种小模型了，验证码输入尺寸通常是 32×32 到 64×64，CPU 训练几千张样本也就十几分钟，没必要折腾 CUDA。

如果你在虚拟环境里做，建议把依赖版本钉死，我吃过一次亏：隔了两个月重跑一个旧项目，numpy自动升级到 2.x，某些依赖还按 1.x 的 API 写，直接一片红。

2.2 目录结构和数据流的约定

这个看着琐碎，但我强烈建议你一开始就定好。验证码项目最容易失控的地方就是数据——原图、中间图、标注、切分出来的单字符样本，搅在一个文件夹里，过两周自己都认不出哪是哪。

我现在的习惯是这样：

captcha_project/ ├── raw/ # 原始图，只读，绝不修改 ├── processed/ # 预处理后的中间图，按日期分子目录 ├── chars/ # 切分出来的单字符，按类别分子目录 │ ├── 0/ │ ├── 1/ │ └── ... ├── labels.csv # 整图标注：文件名,答案 ├── scripts/ # 各个处理脚本 └── models/ # 训练产物

raw/设为只读这个习惯特别值得养。我有过一次手贱，直接在原图目录上跑了个批量二值化并覆盖保存，几百张原图全毁，只能重新抓。中间结果一律往processed/扔，随时可以删了重来。

labels.csv用两列就够：文件名和答案。别用一堆散落的 txt，后面做训练集划分、统计类别分布的时候会感谢自己。

3. 预处理是胜负手：把图喂胖之前先喂干净

这一段是我最想强调的。做过几个项目之后我的结论很明确：验证码识别的瓶颈，八成在预处理，两成在模型。同一份数据，预处理到位和不到位，准确率能差三四十个点。而预处理的每一步，参数都不是拍脑袋来的，背后都有道理。

3.1 灰度化与二值化：阈值到底怎么定

彩色图先转灰度，这是标准动作。OpenCV 默认用的是加权平均，公式大致是0.299R + 0.587G + 0.114B，权重按人眼对不同波长敏感度来的。如果你的验证码是彩色的（比如每个字符颜色随机），灰度化之后字符和背景的对比度可能会被压得很低，这种情况要换个思路——按通道分离，挑对比度最大的那个通道做后续处理，往往比直接转灰度效果好。

二值化才是关键。两种主流方案：

import cv2 def binarize(path, block_size=15, c=8): img = cv2.imread(path, cv2.IMREAD_GRAYSCALE) if img is None: raise ValueError(f"读取失败，检查路径或编码: {path}") # 方案A：全局 Otsu，自动寻找类间方差最大的阈值 _, otsu = cv2.threshold(img, 0, 255, cv2.THRESH_BINARY + cv2.THRESH_OTSU) # 方案B：局部自适应，按邻域均值动态定阈值 adaptive = cv2.adaptiveThreshold( img, 255, cv2.ADAPTIVE_THRESH_GAUSSIAN_C, cv2.THRESH_BINARY, block_size, c ) return otsu, adaptive

Otsu 的原理简单说：把 0~255 所有可能的阈值都试一遍，选那个让"前景像素"和"背景像素"两组之间方差最大的。方差最大意味着两组分得最开，所以它自动就找到了一个合理的分割点。优点是全自动，缺点是假设图像是双峰的——如果背景有渐变、有底纹，直方图不是两个峰，Otsu 就会分错。

自适应阈值解决的就是这个问题。它不用一个全局值，而是对每个像素，看它周围block_size × block_size的区域，算个加权平均，再减去常数c作为这个像素的阈值。这样背景亮的地方阈值高，暗的地方阈值低，渐变背景也能处理。

这里有两个参数必须记牢：

• block_size必须是大于 1 的奇数。传偶数直接抛异常，这是最常见的低级错误。取值一般跟字符笔画宽度挂钩，笔画粗就调大。我通常从 15 开始试，字符很小（比如 20px 高的图）就降到 11 或 9。
• c是从局部均值里减掉的量。c越大，二值化后前景越少（白色区域变少）。对于黑色字符白底的图，c取 5~15 比较常见。调参的时候盯着中间结果看：如果字符被"吃"掉了一部分，说明c太大；如果背景噪点全冒出来了，说明c太小。

还有一个反常识的点：二值化不一定总是对的。有些验证码的干扰是以"同色系浅色噪点"形式存在的，粗暴二值化会把这些噪点固化成实心色块，反而比灰度图更难处理。我遇到过一次，直接在灰度图上做形态学 + 自适应对比度增强，效果比先二值化好得多。所以别迷信流程，看着结果调。

3.2 去噪三板斧：滤波、形态学、连通域

二值化之后的图通常还带着干扰线、噪点和边框。这块我总结了三招，按顺序上。

第一招：中值滤波。cv2.medianBlur(img, ksize)，取邻域内像素的中位数替换中心像素。它对"孤立的椒盐噪点"效果极好，而且不像均值滤波那样把边缘糊掉——因为中位数不受极端值影响。ksize必须是大于 1 的奇数，3 对付细碎噪点够了，5 会开始侵蚀细笔画，慎用。这个参数要跟字符笔画宽度对比着来，如果笔画本身就只有 1~2 像素宽，ksize=3都可能把笔画切断。

第二招：形态学开闭运算。开运算是先腐蚀后膨胀，去掉细小的突出物和孤立点；闭运算是先膨胀后腐蚀，填补小孔洞和断裂。关键在结构元素的选择：

import cv2 import numpy as np # 去除细的横向干扰线 kernel_h = cv2.getStructuringElement(cv2.MORPH_RECT, (15, 1)) opened = cv2.morphologyEx(binary, cv2.MORPH_OPEN, kernel_h) # 修复字符内部的断裂 kernel_small = cv2.getStructuringElement(cv2.MORPH_ELLIPSE, (2, 2)) closed = cv2.morphologyEx(binary, cv2.MORPH_CLOSE, kernel_small)

这里是核心技巧：干扰线通常有明显的方向性。横向的线用(15, 1)这种扁平核做开运算，一通操作下来横向线没了，字符因为笔画有纵向延伸所以基本保留；纵向干扰线用(1, 15)的瘦高核。这个思路的本质是"用形状先验去过滤"——你比机器更清楚干扰长什么样，那就把这个先验编码进结构元素里。核的长度要大于干扰线的粗细，但小于字符笔画的长度，一般取字符高度的 1/2 左右。

第三招：连通域面积过滤。二值图上每个连通块都有面积属性，字符的面积和噪点的面积往往差着一个数量级。

num, labels, stats, centroids = cv2.connectedComponentsWithStats( binary, connectivity=8 ) areas = stats[1:, cv2.CC_STAT_AREA] # 跳过索引0（背景） median_area = np.median(areas) mask = np.zeros_like(binary) for i in range(1, num): area = stats[i, cv2.CC_STAT_AREA] # 面积在合理区间，且宽高比不离谱，才认为是字符 w = stats[i, cv2.CC_STAT_WIDTH] h = stats[i, cv2.CC_STAT_HEIGHT] if 0.3 * median_area < area < 3 * median_area and 0.2 < w / h < 2.5: mask[labels == i] = 255

用中位数而不是平均数来定基准，是因为平均数容易被极端值（超大连通块）拉偏。系数 0.3 和 3 这个区间取得比较宽松，宁可多留也别误杀，反正后面还有模型兜底。宽高比那个条件主要用来滤掉长条形的干扰线残余。

注意：连通域过滤对"字符粘连"的情况会失效——两个字符粘成一个连通块，面积是单个的两倍，刚好落在阈值边缘。这种情况别硬调参数，直接换端到端模型路线。

3.3 字符切分：投影法、连通域法和滴水算法怎么选

切分是把整图变成"单字符小图"的过程，是传统路线的命门。

垂直投影法是最常用的。原理很直白：把每一列的黑像素个数加起来，得到一个一维数组，字符所在的位置黑像素多，字符之间的空隙黑像素少，于是数组上会出现"峰-谷-峰"的形态，在谷底切开就完成分割。

def vertical_projection(binary): # 假设字符是黑色(0)、背景白色(255) proj = (binary < 128).sum(axis=0) return proj def split_by_projection(proj, min_gap=2, min_width=5): spans, in_char, start = [], False, 0 for i, v in enumerate(proj): if v > 0 and not in_char: in_char, start = True, i elif v == 0 and in_char: in_char = False if i - start >= min_width: spans.append((start, i)) if in_char: spans.append((start, len(proj))) return spans

min_width这个参数很关键，用来过滤掉过一个像素宽的空隙也当成分割点造成的碎块。min_gap是用来合并邻近字符的：如果两个字符间距特别小，投影谷不够深，就容易把一个字符切成两半，这时可以设定"间隔小于 N 像素就不切"。

投影法失效的典型场景：字符倾斜。斜体字在垂直方向上有重叠，谷底不清晰。解决办法是先做倾斜校正——用最小外接矩形cv2.minAreaRect求出每个连通块的角度，取中位数作为整体倾斜角，再用仿射变换转正。

连通域法更直接，逐个找连通块然后按 x 坐标排序。缺点是遇到i、j这种上下分离的字符，一个字符会被拆成两个块，需要在后处理里按"x 范围重叠且垂直方向相邻"的规则合并回去。8、0这种中间有空洞的也没问题，connectedComponentsWithStats默认按外包围框统计，不影响。

滴水算法处理粘连字符厉害，它模拟水滴从字符顶部往下滴，遇到黑色像素就按规则往左或往右走，走到最底下形成的轨迹就是分割线。实现起来比投影法复杂，但对付手写体和粘连字有明显优势。我的态度是：能不用就不用，除非你确认数据里粘连率很高。

选型的原则就一条：先用眼睛看切分结果。把切分后的每张单字符小图存下来，抽 50 张看一遍，如果错切率超过 15%，别往下走了，换路线。我有一次没检查就闷头训模型，训完准确率死活上不去，回头一看切分阶段就把三分之一的图切歪了，模型再强也是白搭。

4. 识别环节：从模板匹配到端到端模型

预处理和切分搞定，就剩"给一张小图判断它是哪个字符"了。这部分从轻到重有三个档位，我按适用场景分别讲。

4.1 模板匹配：小样本场景的最优解

如果你要识别的验证码字体固定、字号固定、无旋转，模板匹配能达到令人惊喜的效果，而且零训练成本。

做法是：每种字符手工挑一张（或几张平均后）干净样本当模板，识别时把待测小图缩放到模板尺寸，逐个算相似度。cv2.matchTemplate提供几种算法，验证码场景我一般用TM_CCOEFF_NORMED，它做的是归一化相关系数，对整体亮度变化不敏感，比TM_SQDIFF稳健。

def match_char(char_img, templates, size=(32, 32)): char_resized = cv2.resize(char_img, size, interpolation=cv2.INTER_AREA) best_label, best_score = None, -1 for label, tpl in templates.items(): res = cv2.matchTemplate(char_resized, tpl, cv2.TM_CCOEFF_NORMED) score = float(res.max()) if score > best_score: best_label, best_score = label, score return best_label, best_score

注意这里的cv2.resize一定要在匹配之前做，并且待测图和模板要用同一种插值方式。我一开始一边用INTER_AREA一边用INTER_LINEAR，同一张图在两种插值下差好几个点，白折腾半天。

模板的另一个诀窍是每类多备几个模板。同一个字符在不同位置、不同干扰下的样子不一样，一个模板覆盖不了。我的习惯是每类挑 3~5 张，取最高分。样本从哪来？从你已经切分好的chars/目录里人工核对后挑，这是唯一需要人工的地方。

模板匹配的天花板很明显：字体一变、字号一变、稍微旋转一下就崩。但作为第一版基线，它的价值巨大——一晚上就能跑通全流程，拿到一个 70%~90% 的对照数字，后面上模型有个参照物。

4.2 训一个小 CNN 做单字符分类

一旦有了切分好的单字符样本（按类别分好文件夹），单字符分类就是标准的图像分类任务。验证码场景不需要 ResNet 那么重的网络，一个小卷积网完全够用。

import torch import torch.nn as nn class CharNet(nn.Module): def __init__(self, num_classes): super().__init__() self.features = nn.Sequential( nn.Conv2d(1, 32, 3, padding=1), nn.BatchNorm2d(32), nn.ReLU(), nn.MaxPool2d(2), # 32x32 -> 16x16 nn.Conv2d(32, 64, 3, padding=1), nn.BatchNorm2d(64), nn.ReLU(), nn.MaxPool2d(2), # 16x16 -> 8x8 nn.Conv2d(64, 128, 3, padding=1), nn.BatchNorm2d(128), nn.ReLU(), nn.AdaptiveAvgPool2d((1, 1)) ) self.classifier = nn.Linear(128, num_classes) def forward(self, x): return self.classifier(self.features(x).flatten(1))

设计上几个决定值得说明。输入定成32×32 单通道，因为切分后的字符小图本来就不大，再大也是补零浪费算力；单通道是因为前面已经二值化了，彩色信息没意义。用BatchNorm是为了让训练稳定，验证码样本里背景干净程度参差，BN 能缓解分布差异。结尾用AdaptiveAvgPool2d((1,1))而不是全连接层，是把特征图压成一个向量再接分类头，参数量小得多，小数据集上不容易过拟合。

训练超参的起步配置：

数据增强那条我想重点说。切分本身是不精确的，同一个字符每次切出来的位置和大小都会有 1~2 像素的抖动。如果你的训练集全是完美居中的干净样本，模型上线后一定会因为这点抖动掉点。加随机平移是性价比最高的增强，几乎不用写几行代码，效果立竿见影。旋转同理，切分时如果角度校正有残差，模型也得能扛住。

训练完的评估要盯混淆矩阵，不只看总准确率。常见的问题是0/O、1/l、8/B、5/S这几对互相错，这属于先天相近，只能靠更多样本或者后期加规则约束（比如已知验证码只有数字，就把字母类别的 logit 屏蔽掉）。这个技巧在已知字符集的情况下非常有效，能直接砍掉一整类错误。

4.3 不定长验证码：CTC 路线的关键细节

字符数不固定、或者粘连严重切不开时，就得放弃切分，直接整图输入、整图输出。CTC（Connectionist Temporal Classification）是主流做法：模型输出一个宽度方向上的序列，每个时间步预测一个字符概率分布，CTC 负责把重复字符和空白符号折叠成最终结果。

对验证码来说，这条路线的优势在于不需要字符级标注——你只需要知道整图答案，不需要知道每个字符在图上的精确位置，标注成本大幅降低。这对自建数据集是决定性的优势。

网络结构上，用卷积层提取特征后把高度压成 1，宽度保留作为时间维，接一个 BiLSTM，再接全连接输出。输入高度统一成 32，宽度按比例缩放（比如固定成 128 对应 4 位字符）。

几个实操细节，都是踩过才记住的：

• 宽度要留够。CTC 要求时间步数 ≥ 目标序列长度，而且实践中要留 2 倍以上余量，否则模型学不会对齐。4 位字符的图，宽度方向至少给到 32 个时间步。
• 字符集要加 blank。类别数 = 字符集大小 + 1，那个 1 是 CTC 的空白符号，忘了加会直接报错或者训出诡异结果。
• 解码用贪心就够。torch.argmax后按 CTC 规则折叠，验证码场景序列短，束搜索带来的提升微乎其微，但推理速度慢好几倍。
• 训练集规模要求更高。CTC 在小数据上容易学出"所有时间步都输出 blank"这种退化解，几千张起步比较稳妥。

这条路线的整图准确率提升是肉眼可见的，但工程复杂度也上去了。如果你的切分能做，我建议先用分类路线，把 CTC 当备份方案。

4.4 通用识别库的正确用法与它的天花板

有些场景你压根不想训模型，只想快速跑通。这时候可以用一些开箱即用的通用识别库——它们通常内置了预训练模型，几行代码出结果。

用法上没什么好讲的，但预期管理很重要。这类库的训练数据和你的场景一定不完全一致，字体、干扰样式、字符集的差异都会影响效果。我的经验是：面对"轻干扰型"的图，它能给到 70%~85%，属于能用的水平；面对"强干扰型"或者特殊字体，可能直接掉到 40% 以下。

正确的用法是当基线，不当终局。先用它跑一遍，看看整体准确率和失败样本长什么样，失败样本的共性会告诉你真正的问题在哪——是预处理没做够？是字符太特殊？还是干扰太强？这些信息比你自己瞎猜有价值得多。

另外，这类库通常是 CPU 推理，速度快，适合做"高置信度样本直接过、低置信度样本人工复核"的两段式流程。这个工程模式后面还会提到。

5. 参数怎么算：几个必须动手算清楚的数

这一段可能有点枯燥，但都是能让你的项目少走弯路的关键账。我发现很多人做这类项目最大的问题是没有量化的目标，不知道多少样本够、多少准确率算达标，全凭感觉。

5.1 样本量估算：多少张图才够

先算单字符样本。假设字符集有 36 个（10 个数字 + 26 个字母），每个类别想要模型学稳，经验值是300~500 张。取中位数 400，那就是 36 × 400 ≈14400 张单字符样本。

换算回整图：一张 4 位验证码切出 4 个单字符，理论上需要 14400 / 4 =3600 张整图。但考虑到切分失败率（假设 20% 的图切不出来或切不对）、类别分布不均衡（某些字符天然出现得少），实际需要乘一个 1.5 左右的系数，也就是5000~6000 张原始图。

这个数字听着不小，但如果你做的是自有系统的测试，让脚本每天定时跑几次、每次换个验证码，两周就能攒够。攒的时候注意别只抓同一时段的样本——服务端的字体渲染、干扰线生成如果带随机种子，不同时段可能有微妙差异。

如果走 CTC 端到端路线，因为不需要字符级切分，样本利用率更高，3000~4000 张通常能出效果，但前提是字符数一致或者高度规整。

提示：样本量不足时的补救顺序是——先加数据增强（平移、旋转、轻微缩放、亮度抖动），再考虑迁移学习（用在大字符集上预训过的特征提取器），最后才考虑减字符集（比如从 36 类砍到 10 类数字）。降字符集是最暴力也最有效的手段，如果业务上允许，优先考虑。

5.2 整图准确率的换算账

这个账我强烈建议每个人都算一遍，因为它会彻底改变你对"准确率"的直觉。

一张 4 位验证码，假设单字符准确率是 98%，那么整图全对的概率是：

0.98 ^ 4 ≈ 0.9224

看起来还行。但如果单字符准确率掉到 95%：

0.95 ^ 4 ≈ 0.8145

掉到 90%：

0.90 ^ 4 ≈ 0.6561

看到没有？单字符准确率只掉了 8 个点，整图准确率掉了 27 个点。误差是指数级放大的。这就是为什么同样一个分类模型，做单字符识别感觉良好，做整图识别就崩盘。

反过来这个账也很有指导意义：如果你的整图目标是 90%，那么单字符准确率必须达到0.9^(1/4) ≈ 0.974，也就是97.4% 以上。这个目标一摆出来，你就知道"随便训训"是绝对不够的，得在预处理和数据上下功夫。

位数越多越恐怖。6 位验证码要做到 90% 整图准确率，单字符得达到0.9^(1/6) ≈ 0.9827，也就是 98.3%。这就是为什么长验证码的识别难度是断崖式上升的。

5.3 训练超参的起步配置

除了前面提过的网络超参，还有几个跟数据相关的参数需要定：

验证集划分要分层采样，保证每个类别的比例在训练集和验证集里一致。sklearn的train_test_split加个stratify参数就行。不做分层的话，稀有类别可能全被划到一边，评估结果会失真得很厉害。

6. 常见问题排查实录

这部分是我最想写的内容，因为真正卡人的从来不是理论，是那些"文档里不写、但你一定会遇到"的问题。

6.1 高频问题速查表

6.2 几个不写在文档里的坑

坑一：训练集和测试集的时间泄露。如果你的验证码是分批抓的，第一批当训练集、第二批当测试集，看着是分开了，但如果两批是同一天抓的、干扰模式高度相似，评估结果会虚高。我的做法是按抓取时间切分，用早期数据训练、用最近几天抓的数据测试，这样测出来的数字才接近线上真实水平。第一次发现这个问题时，我的评估准确率从 94% 掉到了 78%，虽然难受，但总比上线后崩盘强。

坑二：验证码本身会消耗。这类图片通常是一次性的，识别失败就得刷新，刷新后又是新图。这意味着你在做端到端评估时，"重试"会混进准确率里。评估必须做单次通过率统计，不要用"重试 3 次内的成功率"，后者会严重高估。

坑三：图像尺寸不一致。有些系统生成的图会随字符数变化宽度。如果你的模型输入固定尺寸，一定要做等比缩放 + 边缘填充，而不是直接硬拉伸，否则字符比例会变形，识别率骤降。填充用背景色（通常是白色 255），这样不影响特征。

坑四：中文路径和空格路径。这个前面提过，但值得再说一遍。批量处理脚本一定要加异常捕获，把失败的路径打印出来，否则一张坏图能让整个批处理挂掉，而你连是哪张都不知道。

坑五：评估指标选错了。整图准确率才是最终指标，单字符准确率只是诊断工具。我见过有人用单字符准确率 96% 汇报项目成果，实际整图只有 85%，交付时被打回。对外一律报整图准确率，这是唯一有意义的数字。

7. 合规边界与工程化收尾

技术本身是中性的，但用法有边界。这一段我态度很明确，因为这是我做这类项目时最先想清楚的事。

7.1 哪些场景可以做，哪些坚决不碰

可以做的：自有系统的自动化测试和回归验证；自己搭建的练习环境，用自己生成的验证码数据练手；已获得明确授权的情况下对特定系统做安全评估；给自家产品做验证码强度评估——反过来验证自家的验证码是不是太弱，这个用途很多人忽略，但价值很高。

不能做的：对任何第三方系统、任何未经授权的目标做识别。这不是技术问题，是底线问题。我在做第一个项目时就给团队定过规矩：所有涉及验证码的工作，必须能说清楚"这是谁的系统、有没有授权"，说不清的一律不做。

还有一点是我个人的体会：真正的安全设计从来不是靠验证码本身。一个系统如果把安全性全押在"图难认"上，那它本身就是脆弱的。做过识别这一侧之后，你反而会更清楚什么样的验证码设计是有效的——比如加入行为特征、加入时效限制、加入风险评分，这些才是真正有韧性的方案。这个视角的转变挺有意思的，从"怎么破"变成"怎么防得更合理"。

7.2 提升稳定性的工程手段

最后说说工程层面的东西，这是决定你的脚本能不能长期跑的关键。

两段式流程。不要指望 100% 准确，正确的心态是"高置信度自动过、低置信度人工兜底"。具体做法是给每个识别结果附一个置信度（分类模型用 softmax 最大概率，CTC 用序列概率的乘积），阈值以上的直接采用，以下的要么重试、要么进人工队列。这个模式在实际项目里非常实用，一个 85% 准确率的模型配上一个合理的置信度阈值，可以把实际错误率压到很低。

失败重试要带策略。重试不是简单刷新再来，要设上限（比如 3 次），并且每次重试之间要有间隔。无脑重试只会浪费资源和时间。

日志要记全。每条记录至少包含：原始图路径、预处理参数、切分结果、识别结果、置信度、最终是否成功。出问题的时候这些日志就是唯一的线索。我有一次被一个"偶发失败"折磨了两天，最后靠日志发现是某批次图片的 DPI 元数据异常导致读取尺寸不对。

版本管理。模型文件、预处理参数、训练数据都要有版本。我吃过一次亏，模型更新后发现效果变差，想回滚却找不到旧模型和对应的数据，只能重训，白搭一天。

性能上的取舍。单张图的完整流程（读取 + 预处理 + 切分 + 推理）在 CPU 上大概是 20~50 毫秒，如果只是偶尔用几下，完全不用优化；如果需要批量处理几千张，把预处理写成向量化操作、模型做 batch 推理，能快好几倍。但别过早优化，先把准确率搞定再说。

我个人在这个方向上来回折腾了挺久，最后沉淀下来的一句话是：先看清楚你的图长什么样，再决定用什么工具。大部分翻车的项目，问题都不是模型不够强，而是从第一步就没搞清自己在处理什么。字体、干扰方式、字符集、位数，这四个信息拿到了，路线基本就定了。至于模型，够用就行，把省下来的时间花在数据清洗和失败样本分析上，回报率高得多。

还有个小技巧分享给准备动手的人：在建任何模型之前，先写个脚本把 100 张图的预处理中间结果拼成一张大图存下来，人眼过一遍。你会发现很多问题根本不需要跑代码就能看出来——比如某批图的对比度明显偏低、某个位置的字符总是被干扰线压住。这一步花二十分钟，能省掉后面好几天。