基于Python与OpenCV的车牌识别计费系统：单机无GPU闭环方案

简介：面向Python初学者、课程设计与毕业设计开发者，以及停车场管理系统二次开发人员，这是一套可直接在PyCharm中运行的智能停车场车牌识别计费系统源码与配套使用说明。系统借助百度AI开放平台的图片识别能力完成车牌识别，围绕车辆入场与出场判断、收入统计柱状图展示、车位满预警等场景，呈现了从识别接口调用到业务计费与数据可视化的完整实现路径。资源包共2003个文件，以1777个Python源码为主体，另含pyc、txt、xml、json等配置与数据文件，以及js、html、css前端页面和pdf、doc说明文档，压缩包约189.59MB，目录结构便于按模块查阅。已有248人学习下载，适合用来对照理解车牌识别接入、计费记录汇总与预警逻辑，并在此基础上做功能扩展或项目改造。

1. 从一个园区出口的排队问题说起

某园区地面有一百多个车位，早高峰出口能排出两三百米。收费员手工记进场时间，一辆车平均卡四十秒，遇到车牌脏了或者逆光，还得下车问一句。这种场景要的不是堆算力的检测模型，而是一套能跑在一台办公电脑上、现场能改费率、识别错了能人工兜底的完整流程。这套 Python 车牌识别计费系统就落在这个位置：摄像头进、道闸出，中间把车牌定位、字符识别、进出场配对、费率计算、记录归档、报表导出串成一条闭环。它适合两类人：做毕设或课设、需要一个功能闭环完整且代码量可控题目的学生；以及要给小型车场做一套低成本进出场方案的从业者。整份源码是一个纯 Python 软件包，不依赖 GPU，装完依赖就能在本机跑通全流程。下面按需求、架构、两条核心链路、避坑、验收的顺序拆开讲。

2. 需求拆解与技术选型：四类场景和一条轻量技术栈

2.1 四类核心业务场景的真实边界

第一类是入场。摄像头对着入口车道，车辆压到地感或者进入检测区，抓一帧图，识别号牌，写一条IN记录，抬杆，落杆。这里的关键指标不是识别率有多高，而是「一辆车只产生一条记录」和「识别失败时能在 3 秒内转人工」，因为入口堵车的体感全在这两点上。

第二类是出场。同样的识别动作，但多了一步：拿号牌去库里找最近一条未出场的IN记录，算出停车时长和金额，收费确认后才抬杆。出场链路必须能处理「找不到入场记录」的情况，比如入场时识别错了、或者车是从别的口进的，这时候要允许按车牌模糊匹配或者手工补录，而不是直接拒绝放行。

第三类是车辆身份区分。临时车按费率收费，包月车直接放行不收费，白名单车（内部车辆、特种车辆）也直接放行。这三类的判定优先级要定死：白名单 > 包月 > 临时，顺序颠倒就会出现包月车被收费的投诉。

第四类是后台。费率的增删改、车位余量统计、进出场流水查询和导出。这部分看起来最不起眼，但答辩和实际交付时，评委和甲方第一眼看的就是后台能不能改费率、报表能不能导出。

2.2 技术选型的取舍：为什么不上一整套深度学习流程

车牌识别这条路有很多走法，从纯 OpenCV 模板匹配到通用检测模型加识别模型都行。选型的锚点是部署环境：单机、无 GPU、可能是一台放在岗亭里的旧电脑，还要能在一台普通笔记本上现场演示。在这个前提下，比较四种常见组合。

我一般给的默认答案是第二条：定位仍然用 OpenCV 的颜色和边缘特征，识别环节留一个可替换的接口，默认走模板匹配，需要更强效果时换成小模型，接口不用改。理由是这套组合在一台没有独显的机器上仍然能跑到接近实时的处理速度，而且每一步都是白盒，出了问题能定位到是定位错了还是切字错了——答辩时被问到「为什么这里要这样做」，你有东西可讲。

数据库用 SQLite，不是为了省事，而是因为这个体量的车场一天几百条流水，SQLite 完全扛得住，还免去了安装数据库服务这一步。界面层用 PyQt5 或者 Flask 都行，前者是桌面端单文件启动，后者是浏览器访问，课设里桌面端更省事。

2.3 计费规则抽象：把「停车费」变成可配置的数据

计费是这个系统里最容易被写死的地方。见过太多版本，费率直接写在if里，改一次价格要改代码重新打包。合格的做法是把费率抽成数据结构，从 JSON 或者数据库读，程序只负责按规则算。规则本身按车辆类型分条，每条包含免费时长、首段费用、超出后的步长和单价、单日封顶。

from dataclasses import dataclass @dataclass(frozen=True) class RateRule: """一条费率规则，按车辆类型匹配；从 JSON 或 t_rate_rule 表载入""" vehicle_type: str # normal / monthly / free free_minutes: int # 免费时长，含边界（<= 该值不计费） first_hour_fee: float # 首小时（首段）费用 step_minutes: int # 超出首段后的计费步长，单位分钟 step_fee: float # 每个步长收多少钱 day_cap: float # 单日封顶 overnight_cap: float # 跨天附加费，每跨一天加一次 # 现场改价只改这一段，不动业务代码 RULES = { "normal": RateRule("normal", 15, 5.0, 30, 1.5, 40.0, 10.0), "monthly": RateRule("monthly", 0, 0.0, 60, 0.0, 0.0, 0.0), }

frozen=True是为了防止运行期有人不小心改了全局规则；free_minutes用「小于等于」而不是「小于」，是因为 15 分钟免费这种规则，用户的心理预期是停满 15 分钟整也不收钱，边界差一分钟就会有人来吵。step_minutes和step_fee拆成两个字段而不是直接写「每小时多少钱」，是为了支持半小时计费和每 15 分钟计费这种更细的规则。常见的误用是把跨天费用塞进day_cap里，结果停 25 小时和停 47 小时收一样的钱，这点在 4.4 会具体处理。

3. 总体架构与数据模型：三层结构和四张表的职责划分

3.1 三层结构：采集层、业务层、展示层

整个系统按三层切。采集层只干一件事：从摄像头或者视频文件拿帧，交出去，自己不判断业务。业务层是最重的一层，包含车牌定位与识别、进出场事件判定、计费、道闸控制。展示层负责界面和报表，不直接碰摄像头，只读业务层写出来的数据。

这样切的好处是把最容易变的部分隔离了：换摄像头只动采集层，换识别算法只动识别模块里的一个函数，改费率只动配置。做课设时这套结构还有个隐性好处——模块之间耦合低，一个人写三个模块也不会互相踩。

3.2 模块职责与一次完整通行的数据流

六个模块的职责边界要划清楚，否则就会出现「识别模块里顺手写了数据库」这种后期没法维护的情况。

视频采集模块维持一个固定长度的帧队列，避免识别耗时抖一下就把画面卡住；识别模块对外只暴露一个函数，输入一帧，输出(号牌字符串, 置信度, 车牌颜色, 裁剪图)，中间过程不出模块；事件模块负责把连续的识别结果收敛成一个车辆事件，包括按时间窗去重、判断是入场还是出场、判断是否需要人工介入；计费模块纯函数式，输入两个时间点和一条规则，输出金额和时长，不碰数据库；存储模块统一收口所有 SQL，别的地方不许直接连库；界面模块只调存储模块的查询接口。

一次入场的数据流是这样走的：采集模块出帧 → 识别模块给出号牌和置信度 → 事件模块检查该号牌在最近 60 秒内是否已有IN记录，没有则生成一条待写入事件 → 存储模块落库并返回记录 id → 道闸模块发抬杆指令 → 界面刷新当前在场车辆数。出场把中间换成「查最近一条未出场记录 + 计费」，其余一致。

提示：事件模块的时间窗去重是整个系统里最容易漏掉的一环，漏了就会出现同一辆车一分钟刷出十几条记录，报表全乱。

3.3 四张表的结构设计与索引选择

表设计的原则是「一条通行记录一行，字段尽量冗余」，不做过度范式化。号牌字符串在入库前统一成大写、去掉中间的点，这样查询时不用做函数转换，索引才能生效。

-- 通行记录：进出场共用一行，出场时回填 out_time 与 fee CREATE TABLE t_vehicle_record ( id INTEGER PRIMARY KEY AUTOINCREMENT, plate_no TEXT NOT NULL, -- 归一化后的号牌，大写无分隔符 plate_color TEXT, -- blue / green / yellow in_time TEXT NOT NULL, -- ISO8601 本地时间，统一格式便于比较 out_time TEXT, duration_min INTEGER, fee REAL DEFAULT 0, status TEXT NOT NULL DEFAULT 'IN', -- IN / OUT / EXCEPTION gate_id TEXT, -- 记录从哪个口进，多口场景必填 confidence REAL, -- 入场识别置信度，低于阈值转人工 snapshot_path TEXT -- 抓拍图相对路径，用于事后核对 ); CREATE INDEX idx_plate_in ON t_vehicle_record(plate_no, in_time DESC); CREATE INDEX idx_status ON t_vehicle_record(status); -- 费率规则：与代码里的 RateRule 一一对应，改价改这张表 CREATE TABLE t_rate_rule ( vehicle_type TEXT PRIMARY KEY, free_minutes INTEGER NOT NULL, first_hour_fee REAL NOT NULL, step_minutes INTEGER NOT NULL, step_fee REAL NOT NULL, day_cap REAL NOT NULL, overnight_cap REAL NOT NULL DEFAULT 0 ); -- 包月/白名单：判定优先级 白名单 > 包月 > 临时 CREATE TABLE t_monthly_vehicle ( plate_no TEXT PRIMARY KEY, vtype TEXT NOT NULL, -- monthly / white expire_at TEXT, -- 包月到期日，白名单可留空 owner_tag TEXT -- 备注，界面上只显示标签不显示个人信息 ); -- 操作日志：人工放行、改费率、补录都必须留痕 CREATE TABLE t_op_log ( id INTEGER PRIMARY KEY AUTOINCREMENT, ts TEXT NOT NULL, action TEXT NOT NULL, detail TEXT, operator TEXT );

idx_plate_in这个复合索引是性能关键：出场时要按号牌找最近一条未出场记录，走这个索引是一次范围扫描，不加索引就退化成全表扫描，跑上几个月流水过万之后，出场响应会明显变慢。status单独建索引是因为报表和「当前在场车辆」这类查询都是按状态过滤。抓拍图只存路径不存二进制，SQLite 里塞图片会让备份文件迅速膨胀到几百兆。

注意：时间字段一律存字符串但格式必须统一，混用2024/5/1 9:03和2024-05-01 09:03:00会让排序和区间查询同时出错。

4. 识别与计费两条核心链路：从一帧画面到应收金额

4.1 图像预处理与车牌定位：三个筛选条件决定成败

定位环节的目标不是找得准，而是「候选少而不错」。做法是先灰度、高斯模糊压噪，再用 Sobel 取水平方向梯度——车牌区域的字符是竖向笔画密集排列，水平梯度响应远强于车身和路面，这一步比直接上 Canny 更聚焦。二值化后用扁平的矩形核做闭运算，把一个个字符连成一整块，避免一个字符出一个框。

import cv2 import numpy as np def locate_plate_candidates(frame, min_area=1200, max_area=60000): """返回候选车牌的四个角点列表，按面积从大到小粗排""" gray = cv2.cvtColor(frame, cv2.COLOR_BGR2GRAY) gray = cv2.GaussianBlur(gray, (5, 5), 0) # Sobel 取 x 方向梯度：字符竖向笔画在水平方向变化最剧烈 sobel = cv2.Sobel(gray, cv2.CV_8U, 1, 0, ksize=3) _, binary = cv2.threshold(sobel, 0, 255, cv2.THRESH_BINARY | cv2.THRESH_OTSU) # 闭运算把字符连成整块，核的宽高比决定了粘连程度 kernel = cv2.getStructuringElement(cv2.MORPH_RECT, (17, 5)) closed = cv2.morphologyEx(binary, cv2.MORPH_CLOSE, kernel, iterations=2) contours, _ = cv2.findContours(closed, cv2.RETR_EXTERNAL, cv2.CHAIN_APPROX_SIMPLE) cands = [] for cnt in contours: area = cv2.contourArea(cnt) if not (min_area <= area <= max_area): # 筛 1：面积 continue rect = cv2.minAreaRect(cnt) w, h = rect[1] if h == 0 or w == 0: continue ratio = max(w, h) / min(w, h) if not (2.2 <= ratio <= 4.0): # 筛 2：宽高比 continue cands.append(cv2.boxPoints(rect)) cands.sort(key=lambda pts: cv2.contourArea(pts.astype(np.float32)), reverse=True) return cands

三个参数决定了这一段的效果。min_area和max_area跟分辨率强绑定，1280×720 下 1200 到 60000 是我常用的经验区间，换成 1920×1080 要同比放大三四倍，否则近处大车牌会被面积上限筛掉。kernel的宽度 17 是按「字符宽度加字间距」估的，车牌在画面里越大，这个值要越大，太小连不成块，太大会把相邻的文字或者边框一起粘进来。ratio区间取 2.2 到 4.0，覆盖了单层车牌的实际宽高比，双层车牌要单独处理。调试时如果发现候选为空，先打印闭运算后的图看一眼，多半是阈值或者核尺寸不对，而不是车牌真的没找到。

定位之后还有一个动作容易漏：透视校正。摄像头斜着装的时候，车牌是梯形，直接切字符会切歪。用四个角点做一次cv2.warpPerspective拉正，后面切字的准确率会明显提升。

4.2 字符分割与识别：垂直投影加可替换的识别接口

拿到拉正的车牌图，先统一高度到 40 像素左右，再做二值化反色，让字符是白底黑字里的白。然后按列求和做垂直投影，投影值接近零的列就是字符之间的间隙，据此切出单个字符。

def split_chars(plate_bgr, target_h=40, min_gap=2): """对已校正的车牌图做垂直投影切分，返回字符小图列表""" gray = cv2.cvtColor(plate_bgr, cv2.COLOR_BGR2GRAY) scale = target_h / gray.shape[0] gray = cv2.resize(gray, (int(gray.shape[1] * scale), target_h)) _, binary = cv2.threshold(gray, 0, 255, cv2.THRESH_BINARY_INV | cv2.THRESH_OTSU) proj = (binary > 0).sum(axis=0) # 每列的白色像素数 chars, start = [], None for x, v in enumerate(proj): if v > 0 and start is None: start = x elif v == 0 and start is not None: if x - start >= min_gap: chars.append(binary[:, start:x]) start = None if start is not None: chars.append(binary[:, start:]) # 首尾通常是边框和铆钉，按宽度裁掉过窄的碎片 return [c for c in chars if c.shape[1] >= 5]

target_h固定成 40 是为了让后面的模板匹配尺度一致，不固定的话同一个字符在不同距离下尺寸不同，匹配分数没法比较。min_gap控制最小间隙，太小会把一个字符切成两半，太大会把相邻字符粘成一个。返回前按宽度过滤掉小于 5 像素的碎片，主要是去铆钉和车牌边框。

识别环节建议留成接口，默认实现用模板匹配：准备一套归一化到 20×40 的标准字符模板，逐个cv2.matchTemplate取最高分。接口签名固定成recognize(char_img) -> (char, score)，以后换成小模型只要实现同一个签名，上层代码一行不改。这一步的常见误用是拿整张车牌图直接丢给识别，不做分割，结果字符粘连时全军覆没。

4.3 识别结果后处理：置信度、易混字符与多帧投票

单帧识别一定会有错，尤其是 0 和 O、8 和 B、2 和 Z、1 和 I 这几组。后处理要解决两件事：把明显错的帧丢掉，把多帧结果收敛成一个。

from collections import Counter # 易混字符按「位置」纠正更准确，这里给出简化版 CONFUSE = {"O": "0", "I": "1", "Z": "2", "B": "8", "S": "5", "Q": "0"} def vote_plate(samples, score_th=0.6, min_ratio=0.5): """samples: [(plate_str, score), ...] 同一辆车在一个时间窗内的多帧结果""" norm = [] for s, score in samples: if score < score_th or not s: continue norm.append("".join(CONFUSE.get(c, c) for c in s.upper())) if not norm: return None, 0.0 plate, cnt = Counter(norm).most_common(1)[0] ratio = cnt / len(norm) return (plate, ratio) if ratio >= min_ratio else (None, ratio)

score_th是单帧准入门槛，低于 0.6 的帧直接不参与投票，宁可少投也不让脏数据拉低一致率。min_ratio是一致率门槛，低于 0.5 表示这几帧结果互相矛盾，这时候返回None，交给事件模块标记为待人工确认，而不是硬选一个。

简化版的字符替换有个隐患：号牌的第 2 位通常是字母，后面若干位是数字和字母混合，全局替换会把本该是字母的位置改成数字。严格做法是按位维护允许字符集，第 2 位只允许字母，其余位按号牌类型校验。这一点在答辩时是加分项，能说清「为什么不能无脑全局替换」就说明你真的跑过数据。

4.4 入场出场配对与计费：去重、跨天与封顶

计费函数是整个系统里唯一必须做到零差错的部分，写错一次就是真金白银的投诉。核心是三件事：时长按分钟向下取整、超出首段按时长步长向上取整、跨天按天数和封顶双重约束。

def compute_fee(in_time, out_time, rule, is_free_vehicle=False): """in_time / out_time 均为 datetime；返回 (金额, 时长分钟)""" if is_free_vehicle: return 0.0, 0 minutes = int((out_time - in_time).total_seconds() // 60) if minutes < 0: return 0.0, 0 # 时间倒挂，不自动扣费，转人工 if minutes <= rule.free_minutes: # 免费时长含边界 return 0.0, minutes billable = minutes - rule.free_minutes if billable <= 60: fee = rule.first_hour_fee else: rest = billable - 60 steps = -(-rest // rule.step_minutes) # 向上取整，不足一步按一步 fee = rule.first_hour_fee + steps * rule.step_fee days = (out_time.date() - in_time.date()).days cap = rule.day_cap * (days + 1) + rule.overnight_cap * days return round(min(fee, cap), 2), minutes

-(-rest // rule.step_minutes)是向上取整的写法，停 61 分钟按 2 个半小时步长算，符合车场「不足一个计费单位按一个计费单位」的惯例，写成rest // step就会少收钱。days + 1是因为停 25 小时跨了一天，实际占用两个自然日，封顶要按两天算，再额外加一次跨天附加费，这样 25 小时和 47 小时的结果才不一样。时间倒挂（出场早于入场）必须单独拦下来，这种情况多半是手工补录填错了日期，直接算会得出负数金额，一旦落库，报表就会对不上。

出场配对用一条 SQL 完成，顺序是「同号牌、状态为 IN、按入场时间倒序取第一条」：

SELECT id, in_time FROM t_vehicle_record WHERE plate_no = ? AND status = 'IN' ORDER BY in_time DESC LIMIT 1;

取到了就回填out_time、duration_min、fee并把status改成OUT；取不到就把这条记录标成EXCEPTION，界面弹人工处理窗口。道闸指令在计费确认之后发，绝不能先抬杆再算钱。

5. 避坑与排查：五处最容易翻车的点

5.1 同一辆车一分钟刷出十几条记录

现象是报表里同一号牌连续多条IN，在场车辆数虚高。原因有两个：视频流是连续的，一辆车在检测区停留两三秒就是几十帧，每帧都识别成功了；或者闭运算之后的候选框在相邻帧之间位置抖动，识别出两个只差一位的号牌。解决办法是在事件层加时间窗去重，同一个号牌在 60 秒内只允许产生一条同向记录，同时要求连续 3 帧识别结果一致才落库。排查用这条 SQL，跑出来有数据就说明去重没生效：

-- 排查重复入场：同一号牌存在多条未出场记录 SELECT plate_no, COUNT(*) AS c, MIN(in_time), MAX(in_time) FROM t_vehicle_record WHERE status = 'IN' GROUP BY plate_no HAVING c > 1;

5.2 夜间和逆光下识别率断崖式下跌

现象是白天好好的，傍晚开始识别不出来，或者把「8」认成「B」。原因是夜间车灯直射导致车牌过曝，字符和底色的对比度被压平，Otsu 阈值算出来的分割点落在噪声上。解决分三层：硬件上给摄像头加补光或者换成宽动态的机型，这是最有效的一步；算法上在二值化前加一次直方图均衡（cv2.equalizeHist），并且对过曝区域先做一次限幅；策略上把夜间的时间窗从 3 帧放宽到 5 帧，靠投票把错帧压下去。如果条件允许，夜间直接降低自动放行阈值，全部转人工确认，用体验换准确率。

5.3 数据库报 locked，写入卡住

现象是跑一段时间之后写记录报database is locked，界面卡住不刷新。原因是 SQLite 默认的日志模式在「识别线程写、界面线程读」的情况下会出现写锁等待，读事务没结束写就进不去。解决办法是开 WAL 模式，并把所有写操作收敛到一个写线程里串行执行，界面只读不写。

import sqlite3 conn = sqlite3.connect("parking.db", check_same_thread=False) conn.execute("PRAGMA journal_mode=WAL;") # 读写可以并行，写写仍然串行 conn.execute("PRAGMA synchronous=NORMAL;") # 兼顾写入速度与掉电安全 conn.execute("PRAGMA busy_timeout=3000;") # 拿不到锁时等 3 秒再报错

busy_timeout这条最容易被忽略，没有它，一旦碰上锁就立刻抛异常；设成 3000 毫秒之后，短暂的写冲突会被自动重试掉。check_same_thread=False只在确实做了线程同步的前提下才开，否则会把问题从「报错」变成「偶发数据错乱」，更难查。

5.4 出场找不到入场记录，或者金额算成负数

现象是车主明明停了两个小时，系统提示「无入场记录」，或者金额显示 -5 元。原因通常有三种：入场时识别错了一位，出场识别对了，两边号牌对不上；车辆是从另一个入口进的，而查询只按当前gate_id过滤；手工补录时把日期填成了下个月。解决办法是查询时先精确匹配，匹配不到再做一次编辑距离为 1 的模糊匹配并把候选列出来让人工选，绝不能自动选第一个；gate_id不参与配对条件，只作为记录字段；计费函数里对负时长直接返回 0 并标记异常，让异常记录进人工队列。兜底逻辑一定要有，车场最不能接受的是车出不去。

5.5 道闸指令发了没反应

现象是界面显示已抬杆，实际杆没动，下一辆车压上来直接堵住。原因是串口指令发出去了但没有回读状态，继电器动作失败、串口被占用、或者杆子被人手动按下了都没人知道。解决办法是把道闸控制写成状态机：IDLE → OPENING → OPEN → CLOSING → IDLE，每个状态设超时，OPENING超过 3 秒没收到到位信号就重发一次，重发两次仍失败则界面红色告警并提示人工放行，同时把这次失败写进t_op_log。所有人工放行都必须记录操作人和时间，这是后期对账的唯一依据。

6. 验收与答辩：把演示流程当成一次真实通车

验收不是「能识别出车牌」就结束了。我带过的项目里，验收卡住的从来不是算法，而是流程断点。建议按下面这张表逐项过，每项都要有明确的观测方式，别靠感觉。

答辩演示有个顺序上的讲究：先讲架构图，再跑一次入场，紧接着跑一次出场并当场改一次费率，最后展示报表。改费率这一步一定要放在演示里做，因为它最能体现「配置化」这个设计决策，比任何口头解释都有说服力。演示用的视频提前剪好，包含一段正常光照和一段逆光，逆光那段故意让系统识别失败一次，然后展示人工确认流程——主动暴露一次失败并给出兜底方案，比全程顺利更能让人信服。

被问到「识别率多少」时，别报一个漂亮但没有依据的数字，说清楚测试条件：多少张图、什么光照、什么机位、错在哪些字符上、后处理修回了多少。被问到「为什么不用深度学习」，就回到 2.2 的部署前提，讲清楚在无 GPU 单机环境下这套组合的取舍，以及识别接口是可替换的。被问到「并发怎么办」，坦白说明这是个位数车位的单机场景，用 SQLite 加单写线程是有意为之，扩到多机位时会换成独立的服务进程。

最后说个我自己的习惯。从那以后我每次交这类系统，都会在演示前一天晚上，用一部手机当摄像头、一辆玩具车当车辆，把入场到出场完整跑二十遍，专挑光线最差的时候跑。翻车基本都发生在这些边角里，而不是在白天演示厅的灯光下。希望这份拆解能帮到你，把该踩的坑提前踩完。

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