PyTorch本身不提供OCR端到端模型，需组合DBNet等检测模型与CRNN等识别模型，并自行完成对齐、串联和训练调度；标准torchvision.models无文字检测头，直接套用分类模型会导致定位漂移和漏检。
PyTorch 本身不提供 OCR 端到端模型，必须组合多个组件：检测（如 DBNet）、识别（如 CRNN 或 ViTSTR），且需自行对齐、串联和训练调度。
用 torchvision.models 做文字检测？别试了
标准 torchvision.models（如 ResNet、EfficientNet）没有内置文字检测头。DBNet、PSENet 这类检测模型需从头实现或复用社区代码（如 mmocr 的 PyTorch 版本或 dbnet_pytorch）。直接套用分类模型会导致定位漂移、漏检严重——因为文字区域小、长宽比极端、背景干扰强。
- 检测模型输入通常为 640×640 或 736×736，不是 224×224
- 必须带 FPN + PSE/DB 后处理，
torch.nn.functional.interpolate不能替代 - 训练时要用
icdar2015或total-text格式标注，不是 COCO JSON
CRNN 识别模型的输入预处理不能只靠 transforms.Resize
CRNN 要求所有文本行图像被拉伸成固定高度（如 32px），宽度按比例缩放但上限截断（如 280px），再做灰度化+二值化增强。直接用 transforms.Resize((32, 280)) 会扭曲字符宽高比，导致 “i” 和 “l” 混淆、“0” 和 “O” 误判。
- 正确做法：先等比缩放高度至 32，再左对齐补零至 280 宽；或用
torchvision.transforms.Resize([32, -1], interpolation=Image.NEAREST)配合自定义 pad - batch 内不同长度文本行必须 padding 到同一宽度，否则
torch.nn.utils.rnn.pad_packed_sequence会报错 - 标签需转为
torch.tensor，且用CTCLoss时禁止含重复字符合并逻辑（那是解码阶段的事）
torch.compile 在 OCR pipeline 中大概率失效
OCR 流程天然含动态 shape：检测输出的 bounding box 数量每图不同，裁剪后的文本行数量、长度都不固定。torch.compile 默认 trace 时会卡在第一个 batch 的 shape 上，后续变长 tensor 触发 recompilation，反而拖慢推理速度。
立即学习“Python免费学习笔记（深入）”；
- 仅对识别子网络（CRNN/ViTSTR）单独 compile 可能有效，但需确保输入 width 固定（如统一 pad 到 280）
- 检测网络中带 NMS 或 DB 后处理的模块（如
cv2.findContours或torch.topk动态索引）无法被 trace - 更稳的选择是用
torch.jit.script对识别模型导出，配合 OpenVINO 或 ONNX Runtime 加速
真正难的不是单个模块实现，而是检测框坐标如何无损传给识别模块、如何设计 joint loss 平衡检测与识别梯度、以及怎么让模型在低分辨率模糊文本上不崩——这些细节没标准答案，得靠 cv2.warpPerspective 对齐、torch.nn.GradScaler 控制梯度爆炸、还有大量人工抽检 bad case。
