企业官网建设流程全解析

简介：这是一套基于深度学习、采用纯Java实现的智能车牌识别源码与模型包，支持14种中文车牌类型，面向Java技术栈开发者、算法工程师以及需要离线车牌识别能力的软件项目，可有效填补Java生态中轻量级深度学习推理落地的空白。资源共126个文件，压缩包约14.51MB，以74个Java源码文件为核心，覆盖图像预处理、车牌定位、字符分割与识别等完整流程；配套ONNX模型、Dockerfile和Shell脚本可快速构建部署环境，JPG/PNG样例图片及XML/YML配置便于测试调优。已有271人学习使用，适合直接集成到现有Java系统中，也可作为研究Java端深度学习推理的参考实现。通过这份资源，读者可获得可运行的工程化代码、预训练模型、容器化部署脚本以及清晰的目录结构，显著降低从零搭建车牌识别系统的成本，快速落地多省份、多类型中文车牌的识别需求。

1. 用 Java 部署深度学习车牌识别，先把“纯 Java”的定义敲定

看到“基于深度学习纯 java 的智能车牌识别”这个标题，第一反应是和大多数团队的现状有点反着来。现在一说到车牌识别，习惯性就是 Python 写模型、Flask 起一个 HTTP 服务，Java 业务系统再去调用。这个方案能跑，但多一个服务就多一个故障点，模型更新、内存管理、OOM 处理全都要跨语言协调。而这个标题给出的信号很直接：把 ONNX 或 TorchScript 模型塞进 Java 进程里，让 JVM 自己完成车牌定位、类型分类和字符识别，整套流程离数据库和业务代码更近。

“纯 Java”不等于没有本地库，而是指应用代码、模型推理 API、后处理都在 JVM 里完成。实际落地时通常会用到 JavaCV/OpenCV 的 JNI 绑定，或者 DJL 自带的图像处理，严格说还是有点本地依赖，但业务层完全可以不写一行 Python。支持 14 种中文车牌类型这件事，真正难的其实不是“识别字符”，而是类型判断和字符序列解码要共用一个前向传播结果。就算你没做过图像识别，只要熟悉 Spring Boot 这类 Web 开发，按“模型加载 → 图像预处理 → 推理 → 后处理”这条路也能走通。

这篇内容适合几类人：一是正在做停车场、园区门禁或高速收费的 Java 后端工程师，想干掉单独的 Python 服务；二是对深度学习感兴趣但不想换技术栈的 Java 开发者；三是手头有“源码 + 模型”包但不知道怎么工程化的人。下面我按自己的实现习惯，把模型选型、源码结构与参数调优拆开讲，代码都以可复现为主。

2. 纯 Java 深度学习推理选型与14种车牌的类别建模

2.1 Java 生态里跑 CNN 推理的三种常见方案

要在 JVM 里跑深度学习模型，常见做法是三个：Deep Java Library、ONNX Runtime Java API、Deeplearning4j。DJL 对前端 API 的封装最友好，而且能同时加载 PyTorch、TensorFlow、ONNX 格式，还内置了图像分类和检测的推理接口，省去手工写张量转换。ONNX Runtime 则是“只做推理、不做训练”的轻量运行时，模型先由 Python 侧导出成.onnx文件，Java 端只用OrtSession就能完成前向传播。Deeplearning4j 本身支持训练，但模型社区和部署资料已经明显不如前两者活跃，适合老项目维护，不适合新开车牌识别。

我通常建议新项目直接用 ONNX Runtime。原因是车牌识别模型一般由 YOLO 变体做检测、轻量 CNN 做字符识别，导出成 ONNX 非常顺滑。Java 端只需要引入一个onnxruntime的 Maven 依赖，把所有 numpy 操作替换成 OpenCV 或 NDArray 操作就行。三个方案的对比如下：

2.2 检测模型与识别模型的分工

车牌识别不是单模型一次出结果，而是典型的级联结构。第一个模型负责“车牌在哪”，通常是一个单阶段目标检测网络，输出候选框和置信度。第二个模型负责“这是什么车牌”，输入是第一个模型裁剪出来的车牌图像，输出包括两个分支：一个是车牌类型分类，另一个是字符序列识别。拆分的好处是训练和调优互不干扰，检测模型误检时不会连带破坏字符识别。

14 种中文车牌类型的分类维度很多，颜色是最直观的线索，但同一颜色可能对应不同用途。蓝牌是小型车，黄牌是大型车，绿牌是新能源车，白牌是政法和警用，黑牌是涉外车辆，此外还有教练车、领馆车、使馆车、港澳入出境车、挂车、拖拉机、临时牌等。只用颜色做类型判断不够稳，因为图像白平衡很可能把蓝色偏成蓝灰色。更可靠的做法是把颜色特征和字符特征一起喂给分类头：车牌的汉字（如“京”“使”“学”）和尾部编码的组合，往往比单一颜色更稳定。

2.3 车牌类型和字符集的标签设计

模型输出不是直接输出中文汉字，而是索引映射。拿“京A12345”举例，模型实际上预测了省份汉字、字母、数字三部分。更常见的做法是把完整车牌的每个字符位置当成一个序列识别任务，但车牌字符数不固定，所以需要给特殊字符占位。14 种车型之间的差异有一部分体现在前几位字符里，例如警车的“警”字、教练车的“学”字、使馆车的“使”字，所以类型分类头可以输出一个一维 softmax 概率向量。代码里用枚举把类型对应到索引：

public enum LpType { UNKNOWN(0), BLUE(1), YELLOW(2), GREEN(3), WHITE(4), BLACK(5), COACH(6), POLICE(7), EMBASSY(8), CONSULATE(9), HONGKONG(10), MACAO(11), MOUNTED(12), TRAILER(13), TEMPORARY(14); private final int index; LpType(int index) { this.index = index; } public int getIndex() { return index; } public static LpType fromIndex(int idx) { for (LpType type : values()) { if (type.index == idx) { return type; } } return UNKNOWN; } }

代码逻辑很直白：模型输出的argmax得到一个整数索引，再用fromIndex映射成业务对象。这里有个关键点：索引 0 一般被保留给“无效/背景”，所以模型最后全连接层的输出节点数应该是 15，而不是 14。很多第一次做多分类的人在这里栽跟头，训练时明明是 14 类，导出模型却只有 14 个输出，推理时索引对齐直接乱掉。实际源码里通常还会把 14 种类型映射成一组颜色码和业务描述，方便直接落库。

3. 源码工程结构、模型文件与本地加载细节

3.1 源码包里的最小目录设计

拿到一个“源码+模型”的压缩包，先不要急着运行，第一步是理清目录结构。一个教科书式的 Java 车牌识别项目大概长这样：

lpr-java/ ├── src/main/java/ │ ├── com/example/lpr/ │ │ ├── config/LPRProperties.java │ │ ├── engine/DetectionEngine.java │ │ ├── engine/RecognizeEngine.java │ │ ├── model/LpType.java │ │ ├── model.PlateResult.java │ │ ├── service/PlateRecognizeService.java │ │ └── util/ImagePreprocessor.java ├── src/main/resources/ │ ├── models/ │ │ ├── lpr_detect.onnx │ │ ├── lpr_type.onnx │ │ └── lpr_ocr.onnx │ └── labels/ │ └── plate_type.txt ├── src/test/java/ │ └── RecognizeTest.java └── pom.xml

这个结构里最有参考价值的是models目录，三个.onnx文件分别对应检测、类型分类、字符识别。也有项目把类型分类和字符识别合并成一个模型，这样两个模型就能完成全部流程。我不建议把模型和源码放同一个包后直接打进 Jar，因为模型文件动辄几十 MB，每次发版都重新打一次 Jar 很笨重。更常见的做法是把模型目录外置，通过application.yml配置绝对路径。源码包里保留的是默认模型，方便启动时快速跑通。

3.2 用 ONNX Runtime 加载本地模型并创建 Session

加载本地模型的核心是OrtEnvironment和OrtSession。整个 JVM 进程只应该初始化一个OrtEnvironment，因为它管理着线程池和内存分配。多个模型可以各自创建OrtSession，但不要每个请求新建 session，否则 C++ 侧的内存开销会直接拖垮 JVM。

import ai.onnxruntime.OrtEnvironment; import ai.onnxruntime.OrtSession; import org.slf4j.Logger; import org.slf4j.LoggerFactory; public class OnnxModelLoader { private static final Logger log = LoggerFactory.getLogger(OnnxModelLoader.class); private final OrtEnvironment env; public OnnxModelLoader() { this.env = OrtEnvironment.getEnvironment(); log.info("ONNX Runtime created: {}", env.getVersion()); } public OrtSession load(String modelPath) throws Exception { OrtSession.SessionOptions options = new OrtSession.SessionOptions(); options.setIntraOpNumThreads(2); options.setOptimizationLevel(OrtSession.SessionOptions.OptLevel.ALL_OPT); OrtSession session = env.createSession(modelPath, options); log.info("Loaded model: {}, inputs: {}", modelPath, session.getInputNames()); return session; } }

代码里有几个参数需要重点说明。setIntraOpNumThreads(2)是控制单个算子内部的并行线程数，不是整个模型线程数。车牌识别部署在 Web 容器里时，JVM 本身已经在跑大量业务逻辑，把该值设成 2 或 4 能避免模型推理把 CPU 核心全部抢走。OptLevel.ALL_OPT表示开启所有图优化，ONNX Runtime 会做算子融合和内存复用，对 GraalVM Native Image 或 Spring Boot 打包环境非常有用。

3.3 输入张量的 shape 与归一化参数

模型加载不是难点，输入张量形状才是最容易写错的地方。检测模型输入一般是[1, 3, 640, 640]，对应 batch、通道、高、宽。ONNX Runtime 的输入格式是OnnxTensor.createTensor(env, FloatBuffer, shape)，但 Java 侧没有直接读图像成 float 数组的 API，需要先用 OpenCV 把Mat转成byte[]再转 float。下面的代码演示了完整的转换流程：

import org.bytedeco.opencv.opencv_core.Mat; import org.bytedeco.opencv.opencv_core.Size; import org.bytedeco.opencv.opencv_dnn.Dnn; import org.bytedeco.opencv.global.opencv_imgproc; public float[] preprocess(Mat src, int targetSize) { Mat resized = new Mat(); opencv_imgproc.resize(src, resized, new Size(targetSize, targetSize)); Mat rgb = new Mat(); opencv_imgproc.cvtColor(resized, rgb, opencv_imgproc.COLOR_BGR2RGB); int total = targetSize * targetSize * 3; float[] data = new float[total]; for (int c = 0; c < 3; c++) { for (int h = 0; h < targetSize; h++) { for (int w = 0; w < targetSize; w++) { double[] bgr = rgb.ptr(h, w).get(); float val = (float) bgr[c]; data[c * targetSize * targetSize + h * targetSize + w] = ((val / 255.0f) - 0.485f) / 0.229f; } } } return data; }

这段代码严格复现了 PyTorch 训练时的预处理逻辑：先缩放、再转 RGB、最后按 mean/std 标准化。三个关键点：一是c * targetSize * targetSize确定了 CHW 排布，很多库默认用 HWC 排布，不转 shape 的话模型输出全是噪声；二是0.485/0.229这组参数来自 ImageNet，如果训练时用的是自定义均值，这里必须改成训练时的值，源码包里一般会在 README 或配置里写明；三是resize不是简单拉伸，车牌识别对畸变非常敏感，拉伸总会导致长宽比失真，后续识别率会下降几个点。这里可以用opencv_imgproc.resize配合INTER_CUBIC解决，也可以等比缩放后填充黑边，两种都行。

4. 核心识别流程：灰度化、NMS、字符/类型后处理的 Java 实现

4.1 先用目标检测模型定位车牌区域

把图像送入检测模型后，你会得到一个形状类似[1, 25200, 6]的输出，其中 25200 是模型在所有尺度上生成的锚框数量，6 是x, y, w, h, confidence, class。拿到这个原始输出以后不能直接画框，需要做置信度过滤和非极大值抑制。手写 NMS 很容易在小项目里失控，我一般直接用 OpenCV 的Dnn.NMSBoxes，Java 侧只需要把结果转成Rect数组。

import org.bytedeco.opencv.opencv_core.Rect; import org.bytedeco.opencv.opencv_dnn.Dnn; List<Rect> filterBoxes(float[] output, int rows, float confThreshold) { List<Rect> boxes = new ArrayList<>(); List<Float> confidences = new ArrayList<>(); for (int i = 0; i < rows; i++) { int offset = i * 6; float confidence = output[offset + 4]; if (confidence < confThreshold) { continue; } float cx = output[offset]; float cy = output[offset + 1]; float w = output[offset + 2]; float h = output[offset + 3]; int x = (int) (cx - w / 2); int y = (int) (cy - h / 2); boxes.add(new Rect(x, y, (int) w, (int) h)); confidences.add(confidence); } Rect[] picked = new Rect[boxes.size()]; Dnn.NMSBoxes(boxes.toArray(new Rect[0]), confidences.toArray(new Float[0]), confThreshold, 0.4f, picked); return new ArrayList<>(Arrays.asList(picked)); }

这段代码去掉明显低于阈值的框，再把剩余结果交给 NMS。NMSBoxes的最后一个参数0.4f是 IoU 阈值，含义是“两个框的交并比大于 0.4 就只保留置信度高的那一个”。车牌目标小，建议把 IoU 阈值调低到 0.3～0.35，宁可少一个重复框也别漏框。还有一个容易忽略的点：rows对应模型输出的锚框数量，如果模型输入尺寸是 640，那么rows通常是 25200；实际源码里要写死或从配置读取，不能指望推理输出自动告诉你。

4.2 对裁剪区域做识别前处理

检测模型返回的车牌框是原图坐标系下的，直接裁剪会混入车灯、保险杠等背景，特征会被干扰。我一般会在裁剪后加一道“边缘校正”逻辑：对裁剪的小图做灰度化、Canny 边缘检测，再用霍夫变换找直线，把畸形区域透视校正成矩形。这里不展开霍夫的数学原理，重点看实现顺序。

public Mat rectifyPlate(Mat cropped) { Mat gray = new Mat(); opencv_imgproc.cvtColor(cropped, gray, opencv_imgproc.COLOR_BGR2GRAY); Mat edges = new Mat(); opencv_imgproc.Canny(gray, edges, 100, 200); Mat lines = new Mat(); opencv_imgproc.HoughLinesP(edges, lines, 1, Math.PI / 180, 50, 100, 10); // 根据直线交点估算四个角点 List<Point> corners = estimateCorners(lines); Mat corrected = perspectiveTransform(cropped, corners); return corrected; }

这里最值得说的是Canny的两个阈值，正值 200、负值 100。如果车牌在逆光环境里，边缘不连续，可以把负阈值降到 50；如果车身边缘纹理太多，误检大量直线，就提高负阈值到 150。HoughLinesP的最小线段长度100已经能过滤掉大部分字符边缘，因为单个字符的笔画像素长度远小于车牌边框。做完透视校正后的Mat才真正拿去给类型分类和字符识别模型，这一步能稳定提升两个模型的精度。

4.3 输出解析：类型概率、字符序列和置信度

识别模型的输出通常有两个头：一个头输出[1, 15]的类型概率分布，另一个头输出[1, Seqlength, numCls]的字符序列概率。Java 端处理时，要一次性从同一个OrtSession.run()的结果里取出两个OnnxTensor，再转成float[][]和float[][][]。

public PlateResult parseOutput(Map<String, OnnxTensor> result, List<String> charList) { float[] typeProbs = result.get("type_probs").getFloatBuffer().array(); float[][][] seqProbs = (float[][][]) result.get("seq_probs").getValue(); int typeIdx = argmax(typeProbs); StringBuilder plateText = new StringBuilder(); float maxScore = 0.0f; for (int t = 0; t < seqProbs[0].length; t++) { int charIdx = argmax(seqProbs[0][t]); float score = seqProbs[0][t][charIdx]; if (score > maxScore) { maxScore = score; } if (charIdx == 0) { continue; // blank，代表当前位没有字符 } plateText.append(charList.get(charIdx)); } return new PlateResult(LpType.fromIndex(typeIdx), plateText.toString(), maxScore); }

这段代码里使用了带 blank 的 CTC 解码策略：模型会预测出比实际车牌更长的序列，解码时把所有预测为 blank 的位置跳过，再合并相邻重复字符。注意seqProbs[0].length是模型设置的“最多字符数”，中文车牌最长一般是 8 个字符（如新能源车、使馆车），超过这个长度模型就不会继续输出。charList.get(charIdx)里的charList是从labels.txt读出来的字符表，顺序必须和训练时完全一致。类型概率和字符置信度分开返回，方便调用方做业务判断，比如置信度低于 0.6 时认为“该图不清晰，需要重新抓拍”。

5. 识别精度和性能的平衡点：调参、单一指标验证和灰度发布

5.1 推理参数最值得动的 3 个值

车牌识别部署到生产以后会遇到训练时没见过的光照、倾斜、遮挡情况，但源码包里不会带你做无数轮训练。此时最划算的是调推理侧参数。第一个是输入分辨率，检测模型默认 640，可以改成 480 或 320，速度提升接近一倍，但实际测试中 320 对夜间小目标车牌漏检非常明显，不建议低于 480。第二个是置信度阈值，不同类型车牌应该用不同阈值，比如新能源绿牌的字符清晰，置信度可以设 0.5，而临时牌经常反光，阈值反而要降到 0.35。第三个是图像增强开关，例如对过于暗的图像自动做 CLAHE 对比度增强，这一项在低照度和逆光场景里收益最大。

5.2 14 类车牌的针对性增强小技巧

14 种类型不要只靠一个全局指标衡量。我会把测试集按车牌类型拆开，分别统计各类型的 F1。常见问题有两个：白色警用车牌在很亮的背景下容易漏检，原因是白色车牌和白色车身边界模糊；绿色新能源车牌在树荫下会被误判成蓝牌。对第一个问题，可以在检测前对图像做直方图均衡化；对第二个问题，在识别模型训练数据里加大遮阴场景的占比，如果只是用现成模型，那就用 OpenCV 在 HSV 通道对绿色区域做一次颜色空间增强。

5.3 灰度发布不是只有推荐位

模型文件不能直接替换然后推到所有节点。简单可靠的方案是给每个模型文件加一个版本号后缀，比如lpr_detect.onnx.v12，配置中心通过规则决定哪部分流量走新模型。灰度流量从 5% 起步，观察错误率有没有异常提升。车牌识别这种业务，最终的验证标准往往是日志里“置信度小于阈值”的记录数量，而不是人工抽查几十张图。可以写一个脚本把这些低置信度记录连同原图、预测结果按类型堆叠展示，方便运维在 30 秒内发现问题。等全部节点灰度完成后，再统一改配置指向新模型文件，同时保留旧文件至少一个发布周期。

最后分享一个只靠现有代码就能做的“回放测试”：把真实请求的原始图片和识别结果按yyyyMMdd_车牌号_置信度.jpg命名保存到本地某个目录，隔天用同一批图片重新跑一遍识别，和昨天结果做逐字段 diff。这个方法不用额外写复杂测试框架，但能让你第一次直观看到“某一次模型调整到底改了什么”。

本文还有配套的精品资源，点击获取