基于Python的车牌识别系统开发：从图像处理到深度学习实战-平芜编程栈

1. 项目背景与选题价值：为什么大家都在做车牌识别

车牌识别系统，放在几年前还算是个“高大上”的课题，现在几乎是计算机视觉方向学生和工程师绕不开的经典实战项目。原因很简单：它麻雀虽小，五脏俱全，涉及图像处理、目标检测、字符分割、模式识别甚至深度学习，一条链路走下来，基本上把视觉领域的主要知识点全过了一遍。

我接触车牌识别这个方向，最早是在某实验室做智能停车项目的时候。当时团队的诉求很朴素：出入口道闸要自动抬杆，司机不用刷卡也不用掏手机。真正动手之后才发现，一个看似“扫一眼车牌”的操作，落到代码层面要考虑光照变化、车牌倾斜、字符粘连、汉字识别一堆问题。也正是这些“麻烦”，让车牌识别成为练习计算机视觉基本功的最佳载体之一。

这个选题对开发者或者学生来说，价值不只是“交一个开题报告”。它能让你完整经历一个真实工程项目的生命周期：需求分析、方案选型、数据集构建、模型训练、系统集成、测试迭代。无论你是想积累实际项目经验，还是准备毕业设计，或者打算切入智慧停车、智能安防赛道，车牌识别都是很好的起点。

注意：开题报告和最终系统实现虽然是两件事，但开题本身就是“设计先行”，想清楚要做什么、怎么做、凭什么这么做，后续开发和论文写作都会顺很多。

2. 需求分析与技术选型：先把“做什么”彻底想明白

2.1 核心功能需求的拆解

车牌识别系统的核心功能，说起来就一句话：从一张图片或一段视频里找出车牌位置，把车牌上的字符读出来。但这句话背后藏着一串问题：

图像里可能有多个车牌，要不要都识别？先设定单车牌为主、多车牌为扩展。
车牌是静止的还是运动的？如果做停车场入口，车辆基本是缓行的；如果做道路监控，车速快、姿态多变，难度完全不同。
识别结果怎么用？直接显示字符，还是联动道闸、计费系统？这决定了要不要预留接口。

我建议把需求分成三个层次来做：

需求层级	具体内容	优先级
基础功能	单张图片的车牌定位与字符识别	必做
功能扩展	视频流实时识别、多车牌识别、倾斜校正	重要
业务联动	出入口道闸模拟、数据库存储、查询界面	加分项

开题阶段把这三个层次梳理清楚，后面开发就有明确的节奏，不会东一榔头西一棒子。我当时最深的体会是：需求没想清楚就写代码，等于闭着眼开车，代码改了多少版，方向还是模糊的。

2.2 技术路线的对比与选择

车牌识别的主流技术路线，目前基本是两大流派：传统图像处理和深度学习。两者各有优劣，适合不同场景。

传统图像处理的经典流程是：图像预处理 → 车牌定位（颜色特征或边缘特征） → 字符分割 → 模板匹配识别。优点是计算量小、部署简单，在光照稳定、车牌标准的场景下效果不错；缺点是环境适应性差，遇到倾斜、模糊、强反光时容易翻车。

深度学习路线则通常走两个方向：一是用目标检测模型（YOLO、SSD等）先找车牌，再用CRNN、LSTM等模型做序列识别；二是端到端模型，直接输入图像输出车牌字符。优势是准确率高、适应性强，缺点是模型大、推理慢、对硬件有一定要求。

我个人在模拟项目X里的做法是“两条腿走路”：定位阶段使用轻量级目标检测网络，识别阶段先尝试传统分割加模板匹配做基线，再用一个序列识别模型做精度提升。这样既有对比数据，又能体现工作量，写在报告里也更好看。

拿计算资源来说，如果只有一台普通CPU笔记本，跑YOLO模型训练会很煎熬——我试过，一个Epoch跑十几分钟是常态。这种情况下可以考虑用预处理好的公开数据集做微调，或者干脆先只用传统方法打通全流程，深度学习部分作为优化方向来写。开题报告里方案不必定死，但技术路线一定要写清楚、理由充分，评审老师就喜欢看到这种“想明白了”的选题。

2.3 开发语言与框架的取舍

既然标题是“基于Python”，那开发语言没什么悬念。Python在计算机视觉领域的生态优势太明显了，OpenCV、Pillow负责图像处理，PyTorch、TensorFlow负责深度学习，Flask或PyQt负责界面，一条龙全包。

我实际用下来的组合是：

Python 3.9+：版本别太老，新的也不一定稳，3.9到3.11之间最省心。
OpenCV 4.x：图像读写、颜色空间转换、形态学操作的主力。
PyTorch 2.x：用来训练检测模型，调试方便、社区资源多。
LabelImg或Labelme：标注车牌位置，虽然费人工，但质量可控。
Flask：如果要做成Web服务，比桌面程序更实用。

这里有个容易踩的坑：OpenCV的版本不同，一些API行为会有差异。比如旧版本里某些形态学运算的参数，升级后默认值变了，可能导致同样的代码结果不同。建议项目一开始就锁定版本，写进requirements.txt，别让环境问题消耗时间。

3. 系统架构与模块设计：把黑盒子拆成看得见的零件

3.1 整体架构的分层设计

车牌识别系统如果不做架构设计，直接把图像丢进一个函数，也能出结果，但谈不上系统。真正的系统要分层，每层职责清晰，方便调试和维护。

我的参考分层是这样的：

数据层：负责读图、读视频流，做格式转换和基础增强。最简单的做法是做一个数据加载器，不管是单张图片还是摄像头帧，都统一输出标准尺寸的图像。
检测层：核心是车牌定位，输出车牌区域的边界框坐标。这一步是整个系统的门面，定位不准，后面识别就不用谈了。
识别层：拿到车牌区域图，做字符分割或序列识别，最终输出结构化车牌文本。
应用层：把检测和识别封装成接口，配合界面或服务对外提供功能。

分层设计的好处，我在实际开发中体会很深。某次识别结果一直乱码，排查了半天才发现是预处理那层的高斯模糊参数出了问题。如果没有分层，所有代码糅在一起，这种问题定位至少要翻个两三倍的精力。

3.2 模块划分与职责边界

细化到模块级别，我会抽出这几个核心模块：

模块名	主要负责	对外输入/输出
图像采集模块	加载图片、视频帧、摄像头流	输出BGR格式图像
预处理模块	灰度化、滤波、边缘增强、归一化	输出处理后的图像
车牌检测模块	目标检测模型推理，得到车牌框	输出边界框坐标与置信度
字符识别模块	分割/序列识别，得到字符内容	输出车牌字符串
结果管理模块	保存识别记录、支持查询	输出结构化数据

这里特别提醒一点：模块之间不要互相“越权”。比如预处理模块里不要顺手把识别结果也打印了，检测模块内部不要纠结用什么字体显示。边界清晰了，遇到性能瓶颈时，你才知道该优化哪个环节。

3.3 代码结构参考目录

一个容易读、好扩展的项目目录，长下面这个样子。这是我踩过好多次坑之后的总结，入门同学可以直接照着搭：

LicensePlateRecognition/ ├── config/ # 配置文件 ├── data/ # 数据集存放目录 ├── data_aug/ # 数据增强脚本 ├── detection/ # 车牌检测模块 ├── recognition/ # 字符识别模块 ├── preprocessing/ # 图像预处理模块 ├── tests/ # 单元测试 ├── utils/ # 工具函数 ├── app.py # 主入口 └── requirements.txt

没用过的朋友可能觉得目录结构无关紧要，真正跑起项目来就知道：目录乱成麻的项目，光是找文件就能让人崩溃。我在某次实训课上带过一个新手项目，最后三天基本是在“考古式查找代码”，血的教训。

4. 关键技术实现路线：从图像到车牌文本的完整流水线

4.1 预处理：让图像“更好说话”

预处理是车牌识别第一步，也是很多人忽略的一步。你以为摄像头拍出来的车牌就是干干净净一块蓝底白字？实际场景里，过暗、过曝、反光、模糊、污渍，各种问题都能让后续算法崩溃。

基本预处理链路由这几步组成：

灰度化：把彩色图变成灰度图，减少计算量的同时保住纹理特征。
滤波去噪：我用高斯滤波居多，既能平滑噪点，又不会把边缘直接糊没。核大小通常取3×3或5×5，核太大车牌字符边界会模糊。
对比度增强：直方图均衡化在这里效果明显，尤其是阴天或者背光场景，能让背景和字符的灰度差异拉大。
边缘检测：Sobel、Canny都行。做定位时，Canny产出的边缘图配合形态学膨胀，能让车牌区域变成连通块。

注意：传统方案中，预处理质量直接决定定位准度。一般情况下判断预处理好不好的标准就一条：人眼能不能在结果图上轻松看出“这就是个车牌”。

4.2 车牌检测的两种实现路径

车牌检测是系统的关键环节，检测框稍微偏一点，识别模块拿到的区域就包含大量背景噪声，识别率直线下降。现阶段我推荐掌握两条路线，理解它们各自的适用场景：

传统定位路线依赖车牌颜色特征——国内蓝牌居多，HSV颜色空间里蓝色区域相对集中。操作流程是：转换到HSV → 设定蓝色阈值 → 二值化 → 形态学闭运算连接断裂区域 → 找轮廓 → 按宽高比过滤候选框。

这套方法的好处是“快”，一张图毫秒级完成，非常适合资源受限的原型系统。问题是阈值对光线的依赖性强，傍晚和正午的蓝色表现差异很大，需要动态调整。

深度学习检测路线是当前工程主流，我用轻量级YOLO系列做车牌检测，精度和速度平衡较好。训练前需要准备几百到几千张标注好的车牌图像，如果自己标注工作量大，可以先用公开数据集预训练，再用自采数据微调。

两条路线各有适合的场景，我是先实现传统方法跑通基线，再用深度学习方法把准确率拉高。写报告时，这样对比的实验数据也非常有说服力。

4.3 字符识别：从“切”到“认”

车牌字符识别可以简单拆成两步：第一步把车牌区域拆成单个字符，第二步把每个字符识别出来。

传统的字符分割思路依赖字符间的垂直投影和连通域分析。二值化之后，每个字符会形成明显的“峰谷”区域，通过找谷底就能切分。但这个方法在字符粘连（比如“浙F·5K29”里字母和数字靠太近）时会失灵，需要人为加规则修正。

模板匹配识别是无脑的做法——准备一套车牌字体模板，每个候选字符计算相似度，取最高分。缺点是对变形、模糊字符不友好，优点是不用训练、实现快。

深度学习的识别方案通常用CRNN（CNN+RNN+CTC），直接把整张车牌图映射成字符序列。它的优点是不用明确分割字符，对粘连问题的鲁棒性更强，也是我现在更推荐的方向。

不过要注意：车牌里有汉字（省份简称），还有英文大写和数字，类别数虽不多，但中文汉字的笔画差异较大，样本不均衡时容易出现“粤”“蒙”这类少见汉字识别率偏低的情况。数据准备阶段，要专门保证各省简称的样本量均衡。

4.4 后处理与输出：细节决定体验

识别完之后，还需要做一步简单但重要的后处理。比如标准车牌通常是省简称+字母+点+数字字母组合，格式不对劲，就要能自动修正或提示“待人工确认”。再比如置信度低于某个阈值的样本，不能硬报一个结果，应标记为疑似失败，这在实际业务中很关键。

我第一次做识别系统时，没做后处理，结果一张严重模糊的车牌被硬识别成另一张完全不同的车牌，还打出“识别成功”，后来才明白：给出置信度并设置拒绝阈值，比“宁可错杀不可放过”要科学得多。

5. 数据集与实验环境准备：搞到靠谱的数据是成功的一半

5.1 数据来源的合法性与质量把控

车牌识别系统的成败，很大程度由数据决定。模型没见过某类光照下的车牌，真遇到了就是会认错，这是深度学习的老实话。

数据集来源大致有三类：

公开数据集：网络上有不少开源的车牌数据集，但质量参差不齐，有些图像分辨率低到难以分辨字符。使用前要逐张扫一遍，把模糊、重复、损坏的筛掉。
自采数据：有条件的，可以用手机或相机在停车场、路边拍摄。这样做的好处是数据贴近真实场景，采样时要注意角度、距离的变化，单一正面角度会让模型泛化性变差。
合成数据：通过字体渲染、透视变换、背景融合来造训练图。这个方法适合前期快速扩充数据量，但合成和真实之间有域差距，效果需要验证。

在高校或公司环境中，用他人真实车牌数据做训练，要注意隐私合规，尽量使用公开数据集或模拟生成的虚拟车牌。这不是套话，而是项目落地时躲不开的现实约束。

5.2 标注工具的使用与标注规范

标注车牌框位置是数据准备里最费人工的一步，我用的工具是LabelImg。流程很简单：

打开单张图片，框选车牌区域；
给类别命名为“plate”；
保存，生成与图片同名的XML文件；
转成模型要的格式（YOLO的txt格式或者Pascal VOC格式）。

实际操作中，最容易出的问题是：标注框过大，把附近的装饰物也算进去了；或者过小，切掉了车牌边缘。一个准则是：标注框尽量贴合车牌实际边界，稍微留出1到2像素余量，多了少了都会影响模型收敛。

我用LabelImg标注了五百张图，花了大概半天时间，这算快的。如果量太大，可以考虑借助预标注工具先标一轮，再人工修正，效率高很多。

5.3 实验环境与依赖安装

实验环境直接决定你开发的幸福指数。我的推荐配置如下：

操作系统：Windows 11或Ubuntu 20.04都行，个人更推荐Ubuntu，跑训练时环境问题少很多。
GPU：有NVIDIA显卡（哪怕6GB显存）就能明显加速训练，没有也能跑，只是慢一些。
Python环境：建议用Anaconda管理虚拟环境，避免多个项目依赖打架。

创建项目的虚拟环境基本流程无障碍，但有一个常见坑：安装PyTorch时一定要选对应CUDA版本的安装命令，直接用默认的pip install可能装成CPU版本。我当年就是因为这个，第一周训练慢到怀疑人生，后来才发现用的是CPU推理。

6. 系统实现与编码实战：从空文件到跑通全流程

6.1 主流程代码框架

下面给出一个最简可运行的框架，它把图片加载到输出识别结果的完整流程体现出来。

import cv2 from detection import detect_plate from recognition import recognize_plate from preprocessing import preprocess_image def run_single_image(image_path): # 1. 读取图像 img = cv2.imread(image_path) if img is None: raise FileNotFoundError(f"无法读取图片: {image_path}") # 2. 预处理 processed = preprocess_image(img) # 3. 车牌定位 plate_box, confidence = detect_plate(processed) if plate_box is None: return {"error": "未检测到车牌"} # 4. 裁剪车牌区域并识别 x, y, w, h = plate_box plate_region = img[y:y+h, x:x+w] plate_text = recognize_plate(plate_region) # 5. 输出结果 return {"plate": plate_text, "confidence": confidence} if __name__ == "__main__": result = run_single_image("test_car.jpg") print(result)

这段代码把五个核心环节串起来了。实际开发中，你可以先把detect_plate和recognize_plate做成“假实现”，先跑通流程，再去逐个模块填充细节。好比先搭好骨架，再去填血肉，我从头到尾都推荐这种开发节奏。

6.2 预处理模块实现要点

预处理模块看似简单，却不少坑。我从实用角度给出关键代码片段：

import cv2 import numpy as np def preprocess_image(img): # 缩放：统一宽度，保持比例 target_width = 800 ratio = target_width / img.shape[1] if ratio < 1: img = cv2.resize(img, (target_width, int(img.shape[0] * ratio))) # 灰度化 gray = cv2.cvtColor(img, cv2.COLOR_BGR2GRAY) # 高斯滤波 blurred = cv2.GaussianBlur(gray, (5, 5), 0) # 直方图均衡化 enhanced = cv2.equalizeHist(blurred) return enhanced

这里有个细节：为什么缩放放在第一步？因为后续的轮廓检测、形态学操作都依赖图像尺度。如果输入图片大小差异过大，检测参数就很难通用。统一到800像素宽，不是随便选的，兼顾了计算速度和定位细节保留。实际操作中还测过500和1200，800的效果最均衡。

6.3 车牌定位模块的两种代码速写

先看传统颜色定位方法的核心思路：

def detect_plate_by_color(img): hsv = cv2.cvtColor(img, cv2.COLOR_BGR2HSV) # 蓝色车牌范围，需要按实际环境微调 mask = cv2.inRange(hsv, (100, 100, 100), (130, 255, 255)) kernel = cv2.getStructuringElement(cv2.MORPH_RECT, (15, 5)) closed = cv2.morphologyEx(mask, cv2.MORPH_CLOSE, kernel) contours, _ = cv2.findContours(closed, cv2.RETR_EXTERNAL, cv2.CHAIN_APPROX_SIMPLE) candidates = [] for cnt in contours: x, y, w, h = cv2.boundingRect(cnt) # 车牌宽高比一般在 2.5 到 5.5 之间，面积也有限制 aspect_ratio = w / h if 2.5 < aspect_ratio < 5.5 and w > 100: candidates.append((x, y, w, h)) return candidates

这段代码的痛点是HSV阈值是写死的。太阳下山前一个样，雨天又一个样，想要适应多种环境，可以把阈值参数放到配置文件里，做一个简单的自适应调整逻辑。我试过最简单的自适应：取图像整体蓝色通道的均值和标准差，动态设定inRange的下界和上界，效果比固定阈值好不少。

再看基于YOLO的检测方法，代码层面主要是调用模型：

import torch model = torch.hub.load('ultralytics/yolov5', 'custom', path='best.pt', force_reload=True) model.conf = 0.5 # 置信度阈值 model.iou = 0.45 # NMS阈值 def detect_plate_with_yolo(img): results = model(img) boxes = results.xyxy[0].cpu().numpy() plates = [] for row in boxes: x1, y1, x2, y2, conf, cls = row if int(cls) == 0: # plate 类别 plates.append((int(x1), int(y1), int(x2 - x1), int(y2 - y1))) return plates

实际调试时要注意，torch.hub加载模型会连网，离线环境就要改用本地加载的方式。还有一个常见问题是模型文件路径带中文，容易读取失败，项目目录最好全用英文。

6.4 识别模块的快速实现思路

如果先做传统方案，识别模块可以拆成分割和匹配两部分。字符分割里水平投影和垂直投影两个步骤都要注意：

def segment_characters(plate_region): gray = cv2.cvtColor(plate_region, cv2.COLOR_BGR2GRAY) _, binary = cv2.threshold(gray, 0, 255, cv2.THRESH_BINARY + cv2.THRESH_OTSU) # 水平投影：找到字符区域的上下边界 horizontal_proj = np.sum(binary, axis=1) / 255 rows_with_text = np.where(horizontal_proj > 0)[0] upper, lower = rows_with_text[0], rows_with_text[-1] binary = binary[upper:lower+1, :] # 垂直投影：按峰谷切分字符 vertical_proj = np.sum(binary, axis=0) / 255 # 基于连续非零区域切分 split_points = [] in_char = False for i, val in enumerate(vertical_proj): if val > 0 and not in_char: start = i in_char = True elif val == 0 and in_char: split_points.append((start, i)) in_char = False return split_points, binary

切完字符之后，模板匹配就简单了。建议把模板图片尺寸归一化到和候选字符一样，用归一化相关系数作为相似度。实践中，如果字符间距太宽或太窄，固定的投影谷值会切错，这时要结合一个字符宽度的经验值做约束，比如标准车牌每个字符宽度大约占整个车牌宽度的十分之一。

深度学习的序列识别方案，参考结构是：一个CNN骨干提取特征，经过一个双向LSTM处理序列信息，最后接CTC损失解码出字符序列。这种方案的优势是不需要显式分割，代码模型部分参考成熟开源实现即可。对于开题报告来说，能讲清楚整体思路和选型理由，比贴大段训练代码更重要。

7. 实验测试与性能评估：用数字说话，别用感觉说话

7.1 评估指标的选择与计算

车牌识别系统不是“能跑就行”，要有量化指标。最核心的三个指标是：

检测准确率：正确检测到车牌的图像数，除以总测试图像数。这里的“正确”定义为预测框和真实框的IOU大于某个阈值（通常0.5）。
识别准确率：整牌识别正确的比例。注意是整牌全对才算对，有一个字符错就整牌错。
字符准确率：所有识别出的字符里，正确的比例。这个指标更宽容，能看出模型到底“差在哪个字”。

我当时在模拟项目中的做法是单独统计这两项指标，因为定位已经错了，识别率再高也没意义。实测中，检测准确率如果能达到95%以上，识别端才有优化的空间。低于90%说明定位模块要优先修，别急着调识别模型。

7.2 测试数据集构建

测试集不能和训练集混在一起。基本原则是：测试集要覆盖训练时没见过的场景，否则指标虚高。

我的测试集包含四类图：标准白天光照、夜间路灯光照、雨天反光、倾斜角度大于15度。每类五十张到一百张，这样能看出模型的真实短板。另一个技巧是统计“错误分布”：识别错了，到底是错在省份汉字、字母还是数字？这类信息对后续优化方向非常有指导意义，我自己整理过一次之后，发现大量错误集中在反光场景的“0”和“O”、“1”和“I”这类易混字符上，于是有针对性地做了数据增强。

7.3 性能调优的常用手段

如果测试结果不理想，排优先级调优的思路大致是这样：

数据层面：加数据增强（亮度扰动、角度旋转、模糊模拟），补充失败样本。
模型层面：换更大的骨干网络，或者调整输入分辨率。
后处理层面：对易混字符做规则修正，比如“0”和“O”在车牌中的出现位置有规律，可以结合上下文修正。

调优要有耐心，一次只改一个变量，否则出了问题根本不知道是谁引起的。我见过有同学同时改了数据增强、模型结构和损失函数，结果指标下降了，折腾了一周才发现是某两个改动相互冲突。

8. 常见问题排查与避坑指南：踩过的坑都给你标出来了

8.1 检测框不准的典型原因与对策

检测框偏移是常见“翻车点”，归纳下来有三类原因：

表现	可能原因	解决建议
框偏大，包含背景	标注不规范，训练数据框过大	重新标注或裁剪数据集中错误的框
框偏小，切掉字符	模型收敛不充分或输入分辨率过低	提高输入分辨率、增加训练轮数
框抖动，时大时小	视频帧之间检测不稳定	加入时序平滑，参考前一帧结果

8.2 字符识别易错清单

根据我的实测经验，易错点集中在以下几类：

汉字“沪”和“护”字形极像；
大写字母“O”和数字“0”在低分辨率下难区分；
字符“B”和“8”经过透视变形后容易被混淆；
车牌字符间距不均导致的切偏。

对策很简单：训练数据里专门加入这些容易混的字符变体，或者在后处理时结合车牌字符位规则做约束。比如车牌第二位一定是字母，如果模型在第二位输出了数字8，大概率应该修正为B。

8.3 工程开发节奏的避坑忠告

做这类项目最容易踩的坑是“前期太浪后期补牢”。前两周就把所有精力花在研究模型调参上，结果数据没准备好，项目后期疯狂加班补数据。我建议4:4:2的比例分配时间：四成用于数据和需求梳理，四成用于模型和代码实现，两成用于测试和文档。开题报告阶段，一定要把数据获取方案和时间计划写清楚，后面严格执行。

9. 项目计划与成果预期：让自己的开题报告更有说服力

9.1 分阶段时间安排参考

一个典型的三个月开发周期，可以大致划分成：

第1-2周：文献调研、技术路线验证、数据集收集与整理。
第3-4周：实现基础预处理和传统检测流水线，完成基线系统。
第5-6周：训练深度学习定位模型，替换传统定位模块。
第7-8周：实现字符识别模块，先跑通模板匹配，再训练序列识别模型。
第9-10周：系统集成，设计测试用例，完成指标评估。
第11-12周：优化性能，撰写报告，准备答辩。

这个时间表是理想化版本，实际中几乎每次都会遇到标注返工、训练时间超出预期、答辩材料挤压写论文时间等状况。所以每周都要留出半天做“缓冲池”，别把所有工序排满。

9.2 成果形式与可展示内容

开题报告的成果预期部分，要写清最终交付什么：

一个可运行的Python车牌识别系统；
支持单张图片和本地视频的人机交互界面；
基于测试集的定量评估报告，包含检测准确率、识别准确率等指标；
项目文档与使用说明。

就我的答辩经验来说，能够现场演示整个识别流程，并且在演示过程中遇到一张困难样本还能从容解释处理策略，比堆砌任何华丽的文字都有效果。

10. 写在最后的一点个人经验

车牌识别这个项目，做到最后你会发现，真正值钱的不是某个模型踩到的97%还是98%准确率，而是你对“一个视觉系统是怎么从需求落到可运行代码”这个全过程的理解。这种工程思维，是任何单点技术都替代不了的。

如果你打算把这个项目继续往后延伸，可以考虑的方向也很多：移动端部署、多摄像头联动、极端天气下的鲁棒性、基于Transformer的端到端车牌识别、与数据库联动的完整停车管理后端。技术上每往前走一步，都是新的挑战和收获。

我个人体会最深的倒不是模型精度本身。记得有一次调了很久的识别错误，最后发现是图像预处理里某个参数在不同分辨率图片上表现不一致，导致检测框一直在车牌边缘“游走”。那一刻才真正理解：视觉系统是水桶效应，任何一个环节漏了水，整个系统的准确率都会崩盘。

所以，开题阶段多花时间想清楚“为什么这么做”，绝对值得。架构想透了，代码实现时自然会顺畅；指标想清楚了，调优时也就有了方向。这大概就是做这个项目最值得带走的收获。