简介：面向Python课程设计中的“文字点选验证码”场景，这份资源提供了一套从模型训练到服务部署的完整识别方案，适合需要完成选字、点选类验证码识别课设或入门小样本视觉模型应用的学习者。识别引擎基于约300张样本训练，取得96%准确率，单次识别约100~300毫秒，且经过Python3.6、3.8、3.10的Windows环境验证；编译后的代码在1核2G的低配服务器上也能稳定运行，实用性较强。压缩包共48个文件，大小121.82MB，主要包含Python源码（19个py）、模型权重（bin）、预编译模块（pyd）、验证码图片样本（png/jpg）以及依赖清单、接口服务、前端演示页面等，结构便于按“训练—识别—部署”流程阅读。目前已有437人学习/下载，对正在选毕业设计或课程设计题目的同学来说，可作为功能完整、测试充分的参考实现。
1. 文字点选验证码识别：96%准确率的Python课设源码值不值得拆
文字点选验证码识别，是Python爬虫和自动化测试绕不开的一道坎。网页上那种"请依次点击：选择、文字"的交互校验，脚本处理起来比普通图形验证码麻烦得多：既要读提示词，又要在图里定位每个字，还得按顺序输出坐标。这份课设源码把这条链路完整打通了——提示词OCR、文字检测、坐标排序一步到位，训练只用了300张样本就跑到96%准确率，单张识别耗时约100~300ms，模型经过编译后连1核2G的云服务器都能无压力运行。对正在做Python课程设计的学生来说，它是能直接跑通并拿去答辩的完整项目；对爬虫开发和测试工程师来说，它是低门槛接进业务的现成方案。源码自带训练好的模型、Flask服务、gunicorn配置和一批测试图片，属于能跑、能改、能讲清原理的那一档资源。
2. 识别链路与模型选型：提示词OCR、文字检测、坐标排序怎么协同
文字点选验证码的识别不是单一模型干完的活，它是几个环节串起来的pipeline：先读提示，再找字，最后排序。任何一环出错，都会直接导致点错位置或点错顺序。这一章把识别主线拆开讲清楚，也说明为什么这套方案的选型能同时满足快和准。
2.1 先拆识别主线：提示词从哪来，点击坐标从哪出
一套完整的文字点选验证码，界面通常分两块：顶部或侧边是提示文字区，比如"请点击：选择、文字"；下方是点选图区，里面散落着十几个汉字或词语。要模拟人工点击，得先知道要选哪些字、按什么顺序选，再知道每个字在图里的坐标在哪里。识别主线拆成三步：第一步，提示词OCR，把提示区的文字序列识别出来，得到有序的待点击词表；第二步，文字检测，在点选图里用目标检测模型框出所有候选文字，每个框带类别和置信度；第三步，坐标排序，按提示词顺序在候选框列表里逐个匹配，输出"字→坐标"的有序结果。
第三步看着简单，却是最容易翻车的地方。目标检测模型返回的框顺序本身是乱的，如果你直接按类别名去排序，要么漏字要么顺序错。常见做法是：先用OCR拿到提示词顺序，再遍历每个提示词，在已经检出的框里挑置信度最高且文字匹配的那个，最后按提示顺序组装坐标序列。有些项目里会把提示区也当作检测目标，用同一个模型直接出文本序列，但那样会把OCR问题和检测问题耦合在一起，小样本下效果很不稳定，所以这份源码用的还是分离式方案。
返回的坐标格式也要提前约定好。有的验证码校验接口要的是"点击顺序+坐标"，有的只认坐标序列，顺序默认和请求数据里的提示词一致。这套项目返回的click是二维数组，每个元素[x, y]对应text里相同下标的文字，这个约定要写死在接口文档里，否则调用方解析时很容易对不上位。
2.2 为什么300张图能训到96%：小样本训练的三个前提
96%这个数字放在验证码识别里相当能打，但它确实是小样本训练跑出来的，训练集只有300张。为什么这么少的数据能到96%？三个前提缺一不可。第一个前提是任务本身约束够小。文字点选验证码的候选字通常来自固定字库，常用汉字加数字字母，总共也就几百个类，而且提示词一般只有2到4个字，每个检测框的尺寸相对规整。分类空间小，检测目标结构固定，模型要学的自由度就低。第二个前提是预训练权重复用了。项目里model目录下除了best.bin，还有一个pre_model.bin，按命名习惯这就是预训练权重。常见做法是加载在通用目标检测数据集上预训练过的backbone，冻结前几层，只微调检测头，300张图单独训检测头是够用的。
第三个前提是数据增强做得狠。验证码是规整图形，合理的增强组合是随机旋转、透视变换、亮度抖动、加噪点和干扰线。有增强的情况下，300张可以等效出一两千张的样本多样性，这就是为什么有的项目上千张反而过拟合，而300张加增强能到96%。小样本训练还有一个容易被忽略的细节：验证集划分。常见做法是固定随机种子按比例划出10%到15%作为验证集，并保证每个字在验证集里都出现过，否则准确率统计会虚高。有人问为什么不用PaddleOCR直接端到端识别整张图，道理很简单：点选验证码要的是坐标而不是文字本身，通用OCR擅长把文字识别成字符串，但定位每个字在哪还得靠检测模型，把两者结合是这个场景里公认成本最低的方案。
2.3 识别速度的三块天花板：输入尺寸、推理框架、线程配置
100~300ms这个区间，在CPU上跑出来很实际。决定速度上限的主要是三块。第一是输入尺寸，输入图resize得越大，检测小字越准，推理越慢，320输入比640输入能快一倍以上。文字点选验证码的字体通常较大且独立摆放，320到416就够用，这份源码能在1核2G服务器上无压力运行，实际输入尺寸大概率落在这个区间。第二是推理框架，同一份权重用PyTorch直接推理，CPU上慢得离谱，转成ONNX或OpenCV DNN格式之后速度能降一半以上。best.bin这个后缀不像PyTorch官方权重（一般是.pt或.pth），更像是经过转换的部署格式。第三是CPU线程数，低配置机器上OpenCV DNN默认线程数不一定和机器核数匹配，一个通用习惯是在加载模型后显式设置线程数到物理核数，避免线程切换带来的额外开销。
| 路径 | 作用 |
|---|---|
| captcha.py | 核心识别模块，封装检测、OCR、排序全链路 |
| demo.py | 单张图片测试入口 |
| service.py + src/api | Flask HTTP 服务 |
| gunicorn_conf.py | gunicorn 启动配置 |
| model/best.bin | 训练完成后导出的推理模型 |
| model/pre_model.bin | 预训练或中间权重 |
| bilbil.py | 批量采集与打标辅助脚本 |
| res*.jpg、img_*.png | 测试图片与训练可视化曲线 |
上表只是按代码结构归类，具体实现里还有static和docs目录，一个放前端静态资源，一个放说明文档。如果部署时错把pre_model.bin当成best.bin来用，速度不会变，但准确率大概率会掉，因为pre_model是训练起点，没有经过业务数据微调。这也是很多同学复现时觉得"模型加载成功了但效果不对"的原因之一，先用demo.py确认加载的是不是想要的那份权重。
3. 300张图训出96%准确率：标注格式、训练参数与模型文件选型
模型能跑到96%，训练链路的细节决定结果。做课设最容易犯的错误是把样例代码一跑就当完成，换到自己的数据上效果就崩。这一章把从标注到出模型的完整链路走一遍，照着做可以少踩一半的坑。
3.1 标注格式与目录组织：课设里最快被卡住的环节
文字点选的数据标注核心是一个字一个框。用什么工具不是重点，重点是导出的格式和训练脚本对得上。课设圈里最常用的是LabelImg，手动框出每个字，标签直接填汉字或拼音。项目根目录的bilbil.py，从命名和位置看就是数据准备阶段的采集和打标辅助脚本，作用是产出一批待标注的原图，再把标注结果整理成训练集，它不在识别主链路上，但解释了训练数据从哪来。
常见标注格式有两种：VOC的XML和LabelMe的JSON。如果拿到的是VOC格式，要转成YOLO训练用的txt格式，因为训练脚本大多按类别id加归一化坐标读取。转格式脚本一般长这样：
# convert_voc_to_yolo.py 把VOC xml统一转成YOLO txt import xml.etree.ElementTree as ET from pathlib import Path def voc_to_yolo(xml_path: str, out_path: str, class_names: list): tree = ET.parse(xml_path) root = tree.getroot() size = root.find("size") w, h = int(size.find("width").text), int(size.find("height").text) lines = [] for obj in root.iter("object"): name = obj.find("name").text box = obj.find("bndbox") x1 = float(box.find("xmin").text) y1 = float(box.find("ymin").text) x2 = float(box.find("xmax").text) y2 = float(box.find("ymax").text) # YOLO格式：类别id + 归一化的中心x、中心y、宽、高 cx = (x1 + x2) / 2 / w cy = (y1 + y2) / 2 / h bw = (x2 - x1) / w bh = (y2 - y1) / h lines.append(f"{class_names.index(name)} {cx:.6f} {cy:.6f} {bw:.6f} {bh:.6f}") Path(out_path).write_text("\n".join(lines), encoding="utf-8")这个脚本逻辑不复杂，但有三个地方必须注意。第一，VOC里的xmin、xmax是绝对像素坐标，而YOLO训练要的是归一化坐标，分母必须是图片真实宽高而不是固定值。第二，class_names的索引顺序就是模型预测时的类别id，训练和预测必须用同一份列表，否则重训一次类别全错。第三，中文标签名直接写进XML容易出现编码问题，我一般会先把汉字映射成拼音或数字id，等模型预测完再映射回汉字展示。目录组织同样重要，常见做法是data下分images和labels两个目录，再按train和val分子目录，文件名一一对应。300张图规模不大，但目录一乱就会出现训练时图片和标签对不上、loss正常但mAP为0的诡异结果。
3.2 训练参数怎么定：从一张成绩表读懂模型状态
小样本训练就是走钢丝，参数不对容易过拟合或欠拟合。给一份课设常见的参数范围，照着调能省很多时间：
| 参数 | 参考值 | 说明 |
|---|---|---|
| img_size | 320~416 | 输入尺寸，兼顾小字与速度 |
| batch_size | 8~16 | 300张图不建议超过16 |
| epochs | 100~200 | 配合早停，验证集稳定就停 |
| lr | 0.001~0.01 | 加载预训练权重时取小值 |
| 数据增强 | 旋转/亮度/加噪 | 小样本必开，关掉必过拟合 |
| 早停 patience | 20~30 | 验证集指标连续不涨就停 |
训练入口通常是YOLO系列常见的train.py，命令行参数大致如下：
python train.py --img 416 --batch 16 --epochs 150 \ --data captcha.yaml --weights pre_model.bin --patience 30这条命令里--weights指向pre_model.bin作为初始权重，训练过程中验证集指标最好的那一轮会单独存一份best.bin，和初始权重分开。--img和--batch对应前面参数表的输入尺寸和批大小，--patience是早停轮数，验证集连续30轮不涨就自动停。小样本训练宁可早停也别硬撑到epochs跑完。
训练过程中的可视化同样重要。项目目录里那一堆myplot*.png和res*.jpg，就是训练过程的loss曲线和验证结果图。用Python数据分析的手段看一眼，能快速判断模型有没有好好收敛：loss曲线一直震荡不下降，大概率是学习率太大；验证集准确率曲线和训练集曲线越拉越开，就是过拟合了，回去把增强调强。小样本还有一个容易被忽略的参数是类别数。文字点选候选字不固定，有的图只有汉字，有的带数字字母，如果把全部常见字都放进去，300张图平均每类只有几张，检测头根本学不过来。更合理的做法是只建模实际出现频率高的字，把生僻字丢掉，换来的准确率提升比堆样本更快。
3.3 best.bin和pre_model.bin：训练产物到底该怎么选
训练结束后model目录下出现两个文件：best.bin和pre_model.bin。很多人搞不清这两者的差别，部署时随便拿一个用，结果精度和预期差一大截。按通用命名习惯，pre_model.bin是预训练权重复本，作为训练起点存在；best.bin是训练过程中在验证集上表现最好的那一轮权重导出的推理文件，部署时务必选best.bin。一个血泪教训是：有些项目把最后一个epoch的权重当成best导出，而最后一个epoch往往已经过拟合，验证集准确率反而比中间轮次低。选型之前先在验证集上跑一遍对比，别只看文件名。
bin后缀不是Python生态里常见的模型格式。PyTorch官方权重是.pt或.pth，ONNX是.onnx，OpenVINO是xml加bin的组合。这份源码单独一个.bin，更可能是把权重转成OpenVINO中间表示或直接序列化的二进制格式，好处是丢弃了Python侧动态图的开销，加载更轻、推理更快，在1核2G机器上跑得动也就说得通了。如果你要重训，回到PyTorch权重训完再走导出流程；如果只想部署，直接用best.bin即可。
4. 从demo到线上服务：Flask接口、gunicorn参数与1核2G部署
模型训完只是第一步，课设答辩和实际使用要的是能被调用的服务，不是命令行里跑两张图。这套项目给了demo.py、service.py和gunicorn_conf.py三个入口，正好对应本地单张测试、HTTP服务、线上部署三级递进。
4.1 demo.py：先跑通单张识别再谈别的
demo.py是第一个入口，主要用来验证模型能不能正常加载、单张图的识别结果长什么样。参考实现思路，核心代码会写成这样：
# demo.py 单张图片识别入口 import sys from captcha import TextSelectSolver def main(): # 核心识别器，初始化一次，后续识别请求都复用这个实例 solver = TextSelectSolver( model_bin="model/best.bin", img_size=416, # 输入尺寸 conf_thres=0.5, # 置信度阈值：低于该值的结果直接丢弃 nms_thres=0.45, # NMS阈值：控制重叠框的合并力度 ) image_path = sys.argv[1] if len(sys.argv) > 1 else "res.jpg" result = solver.solve(image_path) # 返回结构：提示词顺序、对应点击坐标、置信度列表 print("识别文字:", result["text"]) print("点击坐标:", result["click"]) print("置信度:", result["conf"]) if __name__ == "__main__": main()这段代码有几个参数值得细说。conf_thres=0.5意味着置信度低于一半的检测框会被扔掉，阈值调低能多捞出模糊字，但误检也会变多。文字点选里漏点一个关键字的代价比多点一个无关框大得多，所以我习惯额外跑一组0.3到0.4的对比。nms_thres控制NMS合并相邻框的力度，文字框之间通常有间隙，0.45是稳妥默认值，遇到粘连笔画时提到0.5。model_bin指向部署模型，保持和验证集上表现最好的那个文件一致。跑通demo.py的意义在于确认三件事：模型能加载、图片路径能读、输出字段和自己预期一致。很多人跳过这一步直接上HTTP层，结果排查问题时根本分不清是模型的问题还是接口的问题。环境上如果卡在依赖安装，注意项目声明支持的是Windows下python3.6、3.8、3.10，建议用venv装对应版本，不要拿最新版Python硬试。
4.2 service.py：用Flask把识别器包成POST接口
验证码识别要接入爬虫或测试流程，最常见方式是抛一个HTTP接口，传图片过去拿到坐标。service.py就是干这个的，Flask实现，接口设计大概是：
# service.py 提供HTTP识别接口 from flask import Flask, request, jsonify from captcha import TextSelectSolver import base64 app = Flask(__name__) # solver放到模块级，全局只初始化一次，避免每个请求重新加载模型 solver = TextSelectSolver(model_bin="model/best.bin", img_size=416) @app.route("/api/captcha/solve", methods=["POST"]) def solve(): data = request.get_json(force=True) img_b64 = data.get("image") # 前端传来的base64字符串 img_bytes = base64.b64decode(img_b64) # 还原成字节流 result = solver.solve_bytes(img_bytes) # 识别接口，内部解析图像字节 return jsonify({"code": 0, "message": "ok", "data": result}) if __name__ == "__main__": app.run(host="0.0.0.0", port=8000)接口里有两个设计细节值得学。第一，solver在模块级初始化，而不是放在函数里每次new一个，否则每个请求都要重新加载模型，单张耗时直接飙到秒级。第二，图片用base64字符串在JSON里传输，省去临时文件读写，也避免多机部署时文件路径不共享的问题。solve_bytes这类接口内部通常用cv2.imdecode解析字节流，只要像素数据完整，imdecode会自动判定编码格式。Flask自带开发服务器只能调试用，课设答辩时演示没问题，真要挂到服务器上必须交给gunicorn这类生产级WSGI服务。
4.3 1核2G部署：gunicorn参数设不好，模型再快也白搭
低配置机器部署的坑，多数不在模型而在服务进程管理。直接看gunicorn的启动配置：
gunicorn -c gunicorn_conf.py service:app对应的gunicorn_conf.py，参考写法如下：
# gunicorn_conf.py workers = 1 # 1核机器的硬限制，多于1个worker内存直接翻倍 threads = 4 # 单进程内开线程，处理并发请求 timeout = 30 # 模型冷启动慢，超时给足30秒 bind = "0.0.0.0:8000" # 监听地址 worker_class = "gthread" # 线程模式，替代默认的同步worker这几个参数是1核2G机器上的血泪配置。workers必须等于1，因为每个worker是独立进程，每个进程都要把best.bin加载进内存，开4个worker就是4份模型常驻，2G内存很快就爆。threads=4配合gthread模式，让一个进程内用线程处理并发，内存几乎不额外增加，吞吐量能顶住常见的爬虫并发。timeout设大是因为模型首次请求时可能要做预热，30秒足够。部署完一定要做的验证动作是压并发：先用curl测单张通过，再用Python的requests并发发20个请求看响应时间。1核2G机器如果出现内存缓升不下降，去查系统日志里有没有OOM killer记录，有的话说明workers或threads还是开多了。
5. 避坑指南：模型加载、编码、多进程与排序规则里的四个翻车现场
这套源码在作者机器上验证过，换到别人机器上未必一次跑通。以下五条是我按经验盘点的高频翻车点，每条都是现象、原因、解决的顺序，可以对照排查。
5.1 模型加载报错：OpenCV DNN版本与导出环境不匹配
现象：代码跑起来后，加载best.bin时直接抛错，提示类似OpenCV DNN的unknown layer或parse error，换了Python版本也一样。 原因：bin模型是从特定环境导出的，不同OpenCV DNN版本对层类型的支持有差异，低版本遇到高版本导出的新层类型会直接拒绝加载。 解决：固定OpenCV版本。先运行print(cv2.getBuildInformation())确认当前版本，再把requirements.txt里的opencv-python锁到和导出环境一致的版本，比如opencv-python==4.5.5.62。如果本机已经混装过多个版本，用pip强制重装后再跑。不要在这类问题上消耗时间，模型文件本身没问题。
5.2 中文路径与编码：图片能打开，标签全是乱码
现象：在Windows下把测试图片放到带中文的目录里，读图成功但识别结果为空；标注文件里的中文类名在训练时变成了一串问号或乱码。 原因：Windows默认编码是GBK，训练脚本以utf-8读文件，两边不一致导致字符串解析失败。图片路径含中文时，OpenCV的imread在不同版本里表现也不一样，读不到就直接返回空图。 解决：路径一律用英文，这是最省事的方案；类名映射成拼音或数字id，在最终展示层再映射回汉字。项目里那个"新建文本文档.txt"如果出现在目录里，当成干扰项删掉，别让它参与任何自动读取。
提示：如果在Windows下同时跑多个Python项目，建议用venv隔离环境，避免OpenCV和NumPy版本互相污染。
5.3 gunicorn多worker导致内存翻倍，1核2G直接卡死
现象：本地Flask开发服务器跑得好好的，一上gunicorn且workers开了4个，服务器内存很快吃满，进程被系统杀掉，识别服务间歇性不可用。 原因：每个worker独立fork，各有各的模型常驻内存。1核2G机器上4个worker的模型占用远超剩余内存，触发OOM killer。 解决：把workers降为1，改用gthread线程模式，让线程共享进程内的模型实例。若确实需要多worker，在gunicorn_conf.py里加preload=True，让模型在fork之前加载进内存，再配合Linux的COW机制降低重复占用。部署后监控free -m，内存稳定在70%以内才算通过。
5.4 测试图96%但线上截图识别率骤降
现象：项目自带的res.jpg、img_*.png识别几乎全对，换到真实网页截图后准确率掉到八成以下，小字和干扰线多的图尤为严重。 原因：训练集只有300张，风格相对统一，真实场景的字体、背景、干扰方式变了，分布漂移直接把准确率拉下来。这不是代码bug，是小样本模型的固有问题。 解决：先做图像预处理，灰度化、二值化、去干扰线能消除一部分分布差异；再做多尺度推理，小字图先放大1.5倍再识别。这两招都救不回来时，说明需要补充真实场景样本做二次微调，而不是继续调阈值。
5.5 点选顺序全乱：坐标都对，点击顺序不匹配
现象：检测框位置准确，文字类别也正确，但把结果提交上去服务器校验失败，日志显示点击顺序和提示词顺序不一致。 原因：模型输出的检测框顺序是乱的，后处理里如果没有按提示词顺序重排，直接按框坐标排序或按类别排序，都会和真实需求对不上。 解决：识别链路最后强制加一步映射，先用OCR拿到提示词序列，再逐个提示词去匹配检测结果里的候选框，匹配成功则记录坐标，最后按提示词顺序输出坐标列表。这一步放在后处理里，不要依赖模型的输出顺序。
6. 进阶落地：用批量验证脚本钉死准确率与耗时
模型再好，没有量化手段等于黑匣子。我在交付这类项目前，一定会写一个批量验证脚本，把准确率和耗时一次性跑出来，作为后续所有改动的基准线。这套流程只应该用在你有权测试的目标上，先把边界划清，再谈优化。参考脚本如下：
# bench.py 批量统计准确率与单张耗时 import glob import time from captcha import TextSelectSolver solver = TextSelectSolver(model_bin="model/best.bin", img_size=416) images = sorted(glob.glob("test_images/*.jpg")) ok = 0 total_cost = 0.0 for path in images: # 文件名约定：正确的点击文字放在前缀，如 "选择_文字_01.jpg" truth = path.split("/")[-1].split("_")[:2] start = time.perf_counter() result = solver.solve(path) cost = time.perf_counter() - start total_cost += cost if result["text"] == truth: ok += 1 print(f"{path}: {result['text']} 耗时 {cost*1000:.1f}ms") avg = total_cost / len(images) * 1000 print(f"准确率: {ok}/{len(images)} = {ok/len(images):.2%}") print(f"平均耗时: {avg:.1f}ms")这里有个细节：统计时间用perf_counter而不是time.time，因为perf_counter不跟随系统时钟调整，计时更稳。文件名约定是朴素的真值管理方式，适合300张这种小规模验证集；样本上到几千张后，我一般改用独立json记录label和图片路径的对应关系。批量脚本跑完，如果准确率达标但耗时偏高，优先检查输入尺寸和CPU线程数；如果耗时尚可但准确率差，回到第3章去看增强和类别数。项目里附带的myplot*.png和res*.jpg配合批量脚本使用，本质上是一套用Python数据分析手段来debug模型的习惯——先看图，再动参数。
另一个明显提升小字识别率的技巧是双尺度推理：同一张图分别在0.8倍和1.5倍下各跑一次，对两组检测结果里的重叠框做置信度加权合并，小字场景准确率通常能再提升2到3个百分点，代价是耗时翻倍。跑批量验证时先记录单尺度基准，再决定要不要开双尺度。自从一次被"best.bin换目录后准确率神秘下降"折腾了半个下午，我每次交付这种识别项目都会强制自己走一遍批量验证：模型文件路径、依赖版本、阈值参数全部钉死在README里，换机器能复现，答辩才能站得住。希望帮到你。
本文还有配套的精品资源，点击获取
