滑块缺口定位不准是因模板匹配失败，需确保背景图与滑块图同源同尺寸，禁用ddddocr的OCR模块，并用OpenCV二值化预处理。
滑块缺口定位不准，ddddocr.DdddOcr 返回空列表怎么办
滑块验证码的“缺口定位”本质是模板匹配，不是OCR。如果 slide_match 方法返回空列表，大概率是图像预处理没做对，或者截图区域没对齐目标区域。
实操建议：
- 确保传入的背景图（无滑块）和滑块图（带小图块）是同一时刻、同一分辨率下截取的，缩放会直接破坏像素级匹配
- 不要用浏览器全屏截图后裁剪，而应直接用
selenium的element.screenshot_as_png截取两个<img>元素原生尺寸图 - 若页面有阴影、边框或轻微模糊，先用 OpenCV 做二值化：
cv2.threshold(img, 0, 255, cv2.THRESH_BINARY + cv2.THRESH_OTSU) -
ddddocr.DdddOcr(det=False, rec=False, old_version=True)必须显式关闭识别模块，否则默认启动图文识别流程，干扰滑块匹配
文字类验证码识别失败，classification 返回乱码或空字符串
ddddocr 的图文识别模型对字体、噪声、扭曲敏感，不是万能黑盒。它只在训练集覆盖的字体样式+常见干扰（点/线/浅色底纹）下稳定输出。
常见错误现象：
立即学习“Python免费学习笔记（深入）”；
- 返回空字符串 → 图像太小（
width 或 <code>height ），或灰度值全为 255（纯白） - 返回单字符或重复字符（如 "AAAA"）→ 图像被过度二值化，粘连严重
- 识别结果含符号（如 "@"、"#"）→ 模型把噪点当字符学进去了
实操建议：
- 输入前统一 resize 到宽 ≥ 120px，高 ≥ 40px，用双线性插值：
cv2.resize(img, (120, 40), interpolation=cv2.INTER_LINEAR) - 避免全局阈值，改用自适应阈值：
cv2.adaptiveThreshold(gray, 255, cv2.ADAPTIVE_THRESH_GAUSSIAN_C, cv2.THRESH_BINARY, 11, 2) - 禁用
old_version=True参数——新版模型（v1.4+）对倾斜、轻度扭曲支持更好，但要求输入为 RGB 或灰度图，不能是 RGBA
并发调用 ddddocr.DdddOcr 报 RuntimeError: module not initialized
这个错误不是多线程问题，而是 ddddocr 内部的 ONNX Runtime 实例不支持跨进程共享。你在多个子进程（比如 multiprocessing.Pool）里重复初始化了同一个 OCR 实例。
实操建议：
- 每个进程必须独立创建
DdddOcr实例，不能从主进程 pickle 传递过去 - 别在全局 scope 初始化 OCR 对象；把它放到 worker 函数内部，或用
threading.local()绑定线程实例 - 如果用 FastAPI/Gunicorn，需配置
preload=False并在每个 worker 启动时延迟加载 OCR 实例 - 注意内存：每个
DdddOcr实例常驻约 80–120MB 显存/CPU 内存，10 个进程就是 1GB 起步
为什么不用 recognize_from_file 直接读图？
因为文件路径读取会触发额外 IO 和格式解析，容易在容器或无权限环境失败；更重要的是，它绕过了你对图像的可控预处理环节。
实操建议：
- 一律用
recognize(np.ndarray)或recognize(bytearray)接口，图像数据由你全程掌控 - 从
BytesIO或 base64 解码得到的 bytes，直接传给recognize()，别落地成临时文件 - 如果必须用文件，确认路径是绝对路径，且 Python 进程有读权限——Docker 容器里常见相对路径失效问题
滑块和文字两类任务底层用的是完全不同的模型与流程，混用参数或输入格式是出错最频繁的原因。别指望一个 DdddOcr 实例通吃所有验证码，该分就分，该重开就重开。
