企业官网建设流程全解析

广州交警针对的士、网约车违停霸占公交站的行为发布加强查处力度的消息后，不少做智慧交通、视频监控系统的开发者都在讨论：这类违停行为靠人工巡检效率太低，有没有可能通过AI视频分析自动发现、自动取证、自动推送？其实这正是智能交通系统里非常典型的“视频结构化 + 违法行为识别”场景。本文围绕公交站违停识别的完整技术链路，从视频流接入、车辆检测、多目标跟踪、电子围栏判定、车牌识别到告警推送，整理一套可以直接落地参考的实战方案。

1. 背景与核心概念

1.1 从一条交通治理新闻说起

公交车站在设计上是公交车专用停靠区域，但实际出行场景中，的士、网约车为了上下客方便，经常直接停在公交站区域内。这样一来，公交车无法正常进站，乘客只能跨车道上下车，既影响通行效率，也存在不小的安全隐患。交警部门加强查处力度是治理手段之一，但单纯依靠人工巡查存在覆盖时间有限、取证成本高、现场执法难度大等问题。

从技术视角来看，这是一个典型的“视频AI识别 + 违法取证 + 告警闭环”问题。如果能在已有监控摄像头的基础上，自动识别出“车辆进入公交站区域并停留超过一定时间”，同时抓拍车牌、保存证据图片和视频片段，就能为交通管理部门提供高效、可追溯的执法依据。

1.2 公交站违停识别要解决什么问题

要让系统真正可用，需要解决以下几个核心问题：

第一，目标识别。系统必须从视频画面中准确识别出“车”，并且区分小汽车、公交车、货车等常见车辆类型，避免把行人、电动车等非机动车误判为违停车辆。

第二，稳定跟踪。违停是一个持续状态，不是某一帧里出现了车就算违停。系统需要判断“同一辆车”是否持续停在公交站区域内，这就需要对车辆进行跨帧跟踪，给每一辆车分配稳定的ID。

第三，区域判定。公交站区域需要在视频画面中划定，通常是一个不规则多边形。系统需要判断车辆是否进入该区域、在区域内停留了多久、什么时候离开。

第四，证据留存。执法场景不能只发一条告警，还需要保存违停发生时的现场图片、视频片段、车牌号码、违停起止时间等信息，形成完整的证据链。

1.3 涉及的AI与工程概念

这个系统涉及的技术点比较集中：目标检测负责“找出画面中的车辆”，多目标跟踪负责“保持同一辆车的ID稳定”，电子围栏负责“划定公交站区域”，车牌识别负责“确认是哪辆车”，告警推送负责“把结果同步给执法或管理人员”。

此外，工程上还需要考虑视频流拉取、抽帧频率控制、结果入库、Webhook推送、系统稳定性等问题。下面会按照一条完整的开发链路逐步展开。

2. 系统整体设计与技术选型

2.1 业务需求拆解

在设计系统之前，先把业务需求拆分成可实现的模块。以一个公交站监控点位为例，核心需求如下：

• 实时读取公交站附近摄像头的视频流；
• 识别画面中的机动车，过滤公交车和无关目标；
• 对进入公交站区域的车辆进行持续跟踪；
• 当车辆在区域内停留超过设定时长（例如30秒）时，判定为疑似违停；
• 识别违停车辆车牌，并保存现场图和视频片段；
• 生成违停记录，通过接口或消息推送通知管理人员；
• 同一辆车在冷却时间内不重复告警。

需要特别说明的是，“停留多久算违停”取决于当地交通管理规则和场景要求，本文示例中采用可配置的时长阈值，实际项目请按业务规则调整。

2.2 技术选型

整体技术方案采用Python作为原型开发语言，原因在于AI生态成熟、代码表达简洁，适合快速验证算法链路。下面是一份参考选型：

版本方面不写死具体版本号，因为YOLOv8、PaddleOCR等组件迭代较快，建议按实际安装环境为准。重点演示的是整体实现思路，代码中使用的API以常见稳定版本为例。

2.3 整体处理流程

整个系统的处理流程可以概括为以下步骤：

1. 视频流模块按固定帧率抽帧；
2. 检测模块对每一帧执行车辆检测，输出车辆边界框；
3. 跟踪模块将当前帧检测框与已有轨迹进行匹配，更新车辆ID；
4. 判定模块根据车辆位置与公交站ROI的关系，维护每辆车的停留状态；
5. 当停留时长超过阈值时，触发车牌识别；
6. 证据模块保存现场图片、裁剪车牌图片和视频片段；
7. 告警模块写入数据库并推送Webhook；
8. 执法平台或管理人员查看记录并处置。

这套流程既能用于公交站违停，也能迁移到消防通道占用、应急车道占用等其他违法停车场景，只需要调整ROI区域、检测类别和判定规则。

3. 环境准备与项目结构

3.1 运行环境与依赖

建议使用Python 3.8以上版本，有NVIDIA GPU的机器可以显著提高检测速度，没有GPU也能用CPU跑，只是处理帧率会下降。核心依赖如下：

pip install opencv-python pip install ultralytics pip install paddleocr paddlepaddle pip install fastapi uvicorn pip install requests pip install pymysql

说明：PaddleOCR安装时需要匹配PaddlePaddle版本，如果只是测试车牌识别，可以先使用CPU版本的PaddlePaddle。实际生产环境建议根据服务器硬件选择合适的安装方式。

3.2 项目目录结构

建议按照功能模块组织代码，下面是一个参考结构：

bus_stop_violation/ ├── main.py # 主程序入口，串联整个流程 ├── config.py # 全局配置：ROI、阈值、数据库等 ├── modules/ │ ├── stream.py # 视频流接入与抽帧 │ ├── detector.py # 车辆检测 │ ├── tracker.py # 多目标跟踪 │ ├── judge.py # 违停判定逻辑 │ ├── plate.py # 车牌识别 │ ├── evidence.py # 证据保存 │ └── notifier.py # 告警推送 ├── evidences/ # 证据文件存放目录 └── requirements.txt

这样的结构方便后续扩展，例如增加新的检测模型、替换跟踪算法或接入更多摄像头点位。

3.3 准备测试视频流

开发调试阶段不一定需要真实摄像头，可以先用手机录制一段公交站场景视频，或者从公开数据集找一段包含车辆的监控视频，转成RTSP流或直接使用本地视频文件。OpenCV的VideoCapture既支持视频文件，也支持RTSP地址，调试时可以用文件输入，保证代码逻辑稳定后再切换到实时流。

4. 视频流接入与车辆检测

4.1 拉取RTSP视频流

视频流接入是整个系统的基础。OpenCV的VideoCapture支持传入RTSP地址，但需要注意拉流稳定性。摄像头断流、网络抖动都会导致cap.read()返回False，因此代码中必须加入自动重连机制。

下面是一个简单的视频流读取模块：

# 文件路径：modules/stream.py import time import cv2 def video_stream_reader(stream_url, frame_interval=0.1): """ 读取视频流并按指定间隔逐帧返回。 :param stream_url: 视频文件路径或RTSP地址 :param frame_interval: 抽帧间隔，单位秒 """ cap = cv2.VideoCapture(stream_url) if not cap.isOpened(): raise RuntimeError("无法打开视频流，请检查地址是否正确") next_time = time.time() while True: ret, frame = cap.read() if not ret: print("读取视频帧失败，尝试重连...") cap.release() time.sleep(2) cap = cv2.VideoCapture(stream_url) continue now = time.time() if now >= next_time: next_time = now + frame_interval yield frame if cv2.waitKey(1) & 0xFF == ord('q'): break cap.release()

这里有两个关键点。第一，frame_interval用于控制抽帧频率，假设检测模型单帧推理需要0.1秒，那么抽帧间隔建议也设置在0.1秒以上，避免推理速度跟不上视频帧率。第二，断流重连非常重要，摄像头长时间运行时难免出现网络闪断，没有重连机制会导致程序退出。

4.2 基于YOLOv8的车辆检测

车辆检测使用YOLOv8实现。COCO预训练模型支持80个类别，其中与车辆相关的类别主要有car（小汽车）、bus（公交车）、truck（卡车）。在实际场景中，公交车本身是公交站的使用者，通常需要过滤掉，只保留car和truck作为分析对象。

# 文件路径：modules/detector.py from ultralytics import YOLO # 加载预训练模型，可按需替换成自己训练的车检模型 model = YOLO("yolov8l.pt") # COCO中car=2, truck=7, bus=5 VEHICLE_CLASSES = [2, 7] def detect_vehicles(frame, conf_threshold=0.5): """ 检测画面中的车辆。 返回列表，每个元素为(x1, y1, x2, y2, score, cls) """ results = model(frame, classes=VEHICLE_CLASSES, conf=conf_threshold, verbose=False) boxes = [] for r in results: for box in r.boxes: x1, y1, x2, y2 = map(int, box.xyxy[0].tolist()) score = float(box.conf[0]) cls = int(box.cls[0]) boxes.append((x1, y1, x2, y2, score, cls)) return boxes

说明：classes=[2, 7]表示只保留COCO数据集中car和truck两个类别，这样可以直接过滤行人、骑行者等无关目标。如果你在真实场景中误检较多，建议采集现场数据后微调模型，或者增加一版专门针对车辆检测的训练数据。

4.3 帧率控制与性能考虑

实时视频分析最常见的性能瓶颈是单帧推理耗时。YOLOv8l模型在GPU上单帧推理约需要几十毫秒，在CPU上可能需要几百毫秒到数秒不等。因此需要通过帧interval来控制送入检测模型的帧率，而不是每帧都跑推理。

一般建议将检测帧率控制在5到10 FPS之间，也就是每0.1到0.2秒处理一帧。这个频率足以判断车辆停留状态，也能明显降低GPU和CPU压力。如果单路视频都压力大，可以换用YOLOv8s或YOLOv8n轻量模型。

5. 多目标跟踪与违停判定

5.1 为什么需要多目标跟踪

如果只是单帧检测，无法知道上一帧出现的那辆车和当前帧这辆车是不是同一辆。比如一辆出租车停在公交站，如果跟踪不稳定，系统可能会把它当成“一会儿出现、一会儿消失”的多辆车，导致停留时间计算错误。

多目标跟踪可以给每一辆车分配一个唯一的track_id。只要ID不丢失，就能维护每辆车的进入区域时间、当前停留时长和离开时间。成熟的跟踪算法包括ByteTrack、DeepSORT、StrongSORT等。本文先用一个简化版IOU跟踪器说明核心逻辑，实际项目建议直接使用ByteTrack获得更好的效果。

5.2 简化版IOU跟踪器实现

IOU跟踪的核心思路是：如果当前帧某个检测框与上一帧某个轨迹的检测框重叠比例较高，就认为是同一辆车。下面给出一个可运行的简化版本：

# 文件路径：modules/tracker.py import numpy as np def compute_iou(box1, box2): """ 计算两个边界框的IOU。 box格式：(x1, y1, x2, y2) """ x1 = max(box1[0], box2[0]) y1 = max(box1[1], box2[1]) x2 = min(box1[2], box2[2]) y2 = min(box1[3], box2[3]) inter_w = max(0, x2 - x1) inter_h = max(0, y2 - y1) inter_area = inter_w * inter_h area1 = (box1[2] - box1[0]) * (box1[3] - box1[1]) area2 = (box2[2] - box2[0]) * (box2[3] - box2[1]) union_area = area1 + area2 - inter_area if union_area == 0: return 0.0 return inter_area / union_area class IOUTracker: def __init__(self, iou_threshold=0.3, max_miss_frames=10): self.iou_threshold = iou_threshold self.max_miss_frames = max_miss_frames self.tracks = {} self.next_id = 1 def update(self, detections): """ 输入当前帧检测框列表，每个元素为(x1, y1, x2, y2, score, cls) 返回匹配后的轨迹列表，每个元素为(track_id, x1, y1, x2, y2, cls) """ matched_tracks = [] for det in detections: box = det[:4] best_track_id = None best_iou = 0.0 for track_id, track in self.tracks.items(): if track["miss_count"] > 0: continue iou = compute_iou(box, track["box"]) if iou > best_iou: best_iou = iou best_track_id = track_id if best_track_id is not None and best_iou >= self.iou_threshold: track = self.tracks[best_track_id] track["box"] = box track["miss_count"] = 0 track["cls"] = det[5] matched_tracks.append((best_track_id, *box, det[5])) else: track_id = self.next_id self.next_id += 1 self.tracks[track_id] = { "box": box, "miss_count": 0, "cls": det[5] } matched_tracks.append((track_id, *box, det[5])) for track_id, track in self.tracks.items(): if track_id not in [m[0] for m in matched_tracks]: track["miss_count"] += 1 expired = [tid for tid, t in self.tracks.items() if t["miss_count"] > self.max_miss_frames] for tid in expired: del self.tracks[tid] return matched_tracks

这个跟踪器只用了IOU匹配，优点是代码简单、容易理解，缺点是当车辆被遮挡、快速移动时ID容易丢失。实际项目可以换成ByteTrack，逻辑类似，但会加入卡尔曼滤波和更精细的匹配策略。

5.3 电子围栏ROI设计

公交站区域在视频画面里通常不是标准的矩形，用多边形ROI更贴近实际。可以先用图像标注工具（如LabelMe）或OpenCV的cv2.selectROI预先标定公交站四角坐标，然后保存到配置文件。

# 文件路径：config.py # 公交站区域多边形坐标，按顺序连接 BUS_STOP_ROI = [ (150, 320), (650, 300), (700, 520), (120, 540) ] # 违停判定阈值，单位秒 PARKING_THRESHOLD_SECONDS = 30 # 告警冷却时间，单位秒 ALARM_COOLDOWN_SECONDS = 300

判断车辆是否在ROI内，可以采用两种方式：一是判断车辆中心点是否落在多边形内，二是计算检测框与ROI的交叠面积比例。前者实现简单，后者更稳定。下面使用OpenCV的pointPolygonTest来实现中心点判断。

# 文件路径：modules/judge.py import cv2 import numpy as np def is_point_in_roi(point, roi_points): """判断点是否在多边形区域内""" pts = np.array(roi_points, dtype=np.int32) result = cv2.pointPolygonTest(pts, (point[0], point[1]), False) return result >= 0 def is_bbox_in_roi(bbox, roi_points): """判断检测框是否命中区域，要求中心点在区域内""" x1, y1, x2, y2 = bbox[:4] cx = (x1 + x2) / 2 cy = (y1 + y2) / 2 return is_point_in_roi((cx, cy), roi_points)

5.4 停留时间判定与报警消抖

停留时间判定不能只依赖单帧结果。模型偶尔会漏检或误检，如果一个车辆只在某几帧被检测到，不能直接认为它进入了公交站。更稳妥的方式是维护一个“进入候选状态”：连续N帧检测到车辆在ROI内，才正式记录进入时间。

下面是一个违停判定器的实现：

# 文件路径：modules/judge.py import time class ParkingJudge: def __init__(self, roi_points, threshold_seconds=30, confirm_frames=5): self.roi_points = roi_points self.threshold_seconds = threshold_seconds self.confirm_frames = confirm_frames # track_id -> {enter_time, confirm_count, last_frame_time, notified} self.vehicle_state = {} def update(self, tracks, current_time=None): """ 输入跟踪后的轨迹列表，每个元素为(track_id, x1, y1, x2, y2, cls) 返回需要告警的轨迹信息列表，每个元素为(track_id, enter_time, duration) """ if current_time is None: current_time = time.time() alarms = [] current_track_ids = set() for track in tracks: track_id = track[0] bbox = track[1:5] cls = track[5] # 只判断车辆类，公交车单独过滤 if cls not in [2, 7]: continue current_track_ids.add(track_id) in_roi = is_bbox_in_roi(bbox, self.roi_points) if track_id not in self.vehicle_state: self.vehicle_state[track_id] = { "enter_time": None, "confirm_count": 0, "last_in_roi": False, "notified": False } state = self.vehicle_state[track_id] if in_roi: if not state["last_in_roi"]: state["confirm_count"] += 1 if state["confirm_count"] >= self.confirm_frames: state["enter_time"] = current_time else: if state["enter_time"] is None: state["confirm_count"] += 1 if state["confirm_count"] >= self.confirm_frames: state["enter_time"] = current_time else: duration = current_time - state["enter_time"] if duration >= self.threshold_seconds and not state["notified"]: alarms.append((track_id, state["enter_time"], duration)) state["notified"] = True else: state["confirm_count"] = 0 state["enter_time"] = None state["notified"] = False state["last_in_roi"] = in_roi # 清理不存在的轨迹，防止内存膨胀 expired_ids = [tid for tid in self.vehicle_state if tid not in current_track_ids] for tid in expired_ids: del self.vehicle_state[tid] return alarms

这段代码的核心是“连续确认”和“一次性告警”。车辆进入ROI后需要连续多帧确认，避免单帧误检导致误报。告警触发后通过notified字段防止同一辆车重复报警。当车辆离开ROI后状态重置，这样车辆下一次进入时可以再次触发判定。

6. 车牌识别与证据链留存

6.1 车牌识别思路

当违停行为被判定后，下一步是识别车牌号码。实际项目中比较靠谱的做法是两级级联：第一步用目标检测模型定位画面中的车牌区域，第二步用OCR识别车牌字符。用YOLO训练一个“车牌检测”小模型是非常常见的方案，训练数据可以从公开车牌数据集或自采数据中准备。

在原型阶段，可以先使用PaddleOCR直接对车辆检测框区域进行文字识别，但要注意结果里可能混入车身上的其他文字。更稳妥的方式是先按车辆下半部分裁剪出可能的车牌区域，再进行OCR识别。

# 文件路径：modules/plate.py from paddleocr import PaddleOCR ocr = PaddleOCR(use_angle_cls=True, lang='ch') def recognize_plate(vehicle_bbox, frame): """ 简化版车牌识别。 实际项目中建议先用车牌检测模型定位车牌，再做OCR。 """ x1, y1, x2, y2 = vehicle_bbox[:4] # 车牌通常位于车辆下半部分，这里按比例截取 plate_area_h = int((y2 - y1) * 0.5) crop = frame[y2 - plate_area_h:y2, x1:x2] result = ocr.ocr(crop, cls=True) texts = [] if result and result[0]: for line in result[0]: texts.append(line[1][0]) return " ".join(texts)

需要提醒的是，PaddleOCR识别速度快慢与图片大小、是否使用GPU有关。生产环境建议将车牌检测和OCR识别放到独立服务中，避免阻塞主检测流程。

6.2 证据图片与视频留存

执法场景的证据链必须完整。一条违停记录通常需要保存以下内容：

• 车辆在公交站区域内停留的原始现场图片；
• 车牌区域的放大裁剪图；
• 从车辆进入到离开的关键视频片段；
• 摄像机编号、地理位置、时间戳等元数据。

现场图片可以直接用OpenCV保存：

# 文件路径：modules/evidence.py import os import cv2 from datetime import datetime def save_evidence(camera_id, frame, plate_crop, plate_text, track_id): """保存违停证据图片""" timestamp = datetime.now().strftime("%Y%m%d_%H%M%S") dir_path = os.path.join("evidences", camera_id) os.makedirs(dir_path, exist_ok=True) scene_path = os.path.join(dir_path, f"{timestamp}_{plate_text}_{track_id}_scene.jpg") plate_path = os.path.join(dir_path, f"{timestamp}_{plate_text}_{track_id}_plate.jpg") cv2.imwrite(scene_path, frame) cv2.imwrite(plate_path, plate_crop) return scene_path, plate_path

视频片段的截取一般用FFmpeg命令行完成，可以记录开始时间点，然后从视频文件或录像中截取前后10秒的片段。如果摄像头支持录像回放，这一步会和监控平台对接。

6.3 违停记录入库设计

结构化记录建议使用MySQL保存。下面是一张简化版的违停记录表：

CREATE TABLE violation_record ( id BIGINT PRIMARY KEY AUTO_INCREMENT, camera_id VARCHAR(64) NOT NULL COMMENT '摄像头编号', location_name VARCHAR(128) NOT NULL COMMENT '地点名称', plate_no VARCHAR(16) COMMENT '车牌号码', track_id BIGINT COMMENT '跟踪ID', vehicle_type VARCHAR(16) COMMENT '车辆类型', enter_time DATETIME NOT NULL COMMENT '进入公交站区域时间', duration_seconds INT NOT NULL COMMENT '停留时长秒数', scene_image_path VARCHAR(256) COMMENT '现场图片路径', plate_image_path VARCHAR(256) COMMENT '车牌图片路径', video_path VARCHAR(256) COMMENT '视频片段路径', status TINYINT DEFAULT 0 COMMENT '0待处理 1已处置', create_time DATETIME DEFAULT CURRENT_TIMESTAMP ) COMMENT='公交站违停记录表';

执行建表语句前，请先在测试环境验证，确认字段满足实际业务需要后再到生产库执行。涉及删改数据的操作，务必提前备份。

7. 告警推送与执法平台对接

7.1 多渠道告警推送

违停记录生成后，需要第一时间通知相关人员。当前最常见的告警渠道是企业微信、钉钉机器人Webhook。这类机器人配置简单，只需要一个Webhook地址就能发送文本和图片消息。

# 文件路径：modules/notifier.py import requests def send_webhook(webhook_url, title, content, image_url=None): """ 发送Markdown格式消息到企业微信或钉钉机器人 """ markdown_text = content if image_url: markdown_text += f"\n![现场图片]({image_url})" payload = { "msgtype": "markdown", "markdown": { "title": title, "text": markdown_text } } response = requests.post(webhook_url, json=payload, timeout=5) return response.status_code, response.text

调用示例：

send_webhook( webhook_url="https://qyapi.weixin.qq.com/cgi-bin/webhook/send?key=xxxx", title="公交站违停告警", content="**违停告警**\n地点：广州大道中公交站\n车牌：粤A12345\n停留时长：45秒\n请及时处理。", image_url="https://your-server.com/evidences/001_xxx_scene.jpg" )

注意：Webhook地址属于敏感配置，建议放在环境变量或配置中心中，不要硬编码到代码仓库里。

7.2 与执法平台的标准接口对接

除了消息推送，违停记录还需要同步到交通管理平台。通常由平台方提供标准的上报接口，例如：

POST /api/traffic/violations Content-Type: application/json Authorization: Bearer <token>

请求体示例：

{ "cameraId": "CAM001", "locationName": "广州大道中公交站", "plateNo": "粤A12345", "vehicleType": "car", "enterTime": "2025-01-01 08:30:00", "durationSeconds": 45, "sceneImageUrl": "https://your-server.com/evidences/CAM001/xxx_scene.jpg", "plateImageUrl": "https://your-server.com/evidences/CAM001/xxx_plate.jpg", "videoUrl": "https://your-server.com/evidences/CAM001/xxx.mp4" }

对接时要注意接口鉴权、幂等性和失败重试。比如平台接口偶发超时，如果直接丢弃记录，会导致数据丢失；建议在本地先保存记录，再通过异步任务同步到平台，并记录同步状态。

7.3 数据鉴权与安全边界

这类系统采集的是公共场所视频数据，涉及敏感个人信息，使用边界必须清晰。首先，系统只能用于合法授权的交通管理业务，接入的摄像头点位需要经过管理方同意。其次，告警图片和视频内容应当限制访问权限，不能任意扩散。最后，涉及个人信息的数据需要按照最小必要原则处理，比如只提取车牌号用于执法，不额外采集驾驶员人脸信息，或者对人脸区域进行打码处理。

8. 常见问题与排查思路

8.1 高频问题速查表

8.2 如何定位漏报与误报

排查漏报和误报，建议按照“数据链路”顺序逐层检查：

第一步检查检测层。将检测结果可视化，确认车辆是否被正确框出、类别是否正确。如果漏检，优先考虑模型问题或conf阈值过高。

第二步检查跟踪层。观察车辆在连续帧中的track_id是否稳定。如果ID频繁跳变，说明跟踪失效，停留时间计算也会出错，重点排查IOU阈值和miss帧数。

第三步检查判定层。查看车辆进入ROI时的中心点坐标，确认是否真的落在区域内。ROI标定不准确是误报漏报的重要原因。

第四步检查业务层。确认告警冷却时间、停留阈值等参数是否符合实际需求，尤其是“停留多久算违停”这类业务规则，需要和管理方确认清楚。

9. 最佳实践与工程建议

9.1 从试点到推广的节奏

这类AI识别系统不建议一上来就大规模上线。比较稳妥的做法是先选一个公交站作为试点，跑通“检测—跟踪—判定—取证—推送”完整链路，重点记录两类样本：误报样本和漏报样本。

试点阶段至少要运行一到两周，覆盖白天、夜晚、雨天等多个场景。根据真实场景数据调整ROI坐标、停留时长阈值、模型置信度等参数。当误报率和漏报率都达到可接受范围后，再逐步扩展到更多点位。

9.2 数据合规与隐私保护

视频分析系统必须重视数据合规。摄像头点位需要经过合法授权，采集到的视频流和证据图片要设置访问控制，不能暴露到公网。建议做以下几件事：

• 视频流、图片文件存储在内网，通过鉴权接口访问；
• 告警图片中的行人人脸区域做打码处理；
• 违停记录设置保留期限，到期自动清理；
• 系统操作日志完整记录，谁看了什么数据、什么时候看的都要可追溯。

9.3 性能优化与模型迭代

性能优化方面，常见手段包括：用NVIDIA TensorRT对检测模型加速、把视频拉流和模型推理放到独立的常驻进程、使用Redis缓存车辆轨迹状态、用消息队列实现告警模块解耦。如果摄像头路数较多，可以按点位拆分处理任务，独立部署服务实例。

模型迭代方面，建议持续采集违停场景数据，定期评估模型在真实场景中的表现。车牌识别模型和车辆检测模型都要建立评测集，每次更新模型前先在评测集上对比准确率，避免“更新后反而变差”的情况。

10. 总结与后续演进

本文从“的士、网约车违停霸占公交站”这一交通治理场景出发，详细拆解了一套公交站违停识别系统的完整实现方案。核心链路包括视频流接入、车辆检测、多目标跟踪、电子围栏判定、车牌识别、证据留存和告警推送。代码示例覆盖了从OpenCV拉流到YOLOv8检测、从简化IOU跟踪器到违停判定逻辑的主要环节，可以作为原型开发的起点。

下一步如果想把这个项目落地到真实环境，建议优先做两件事：一是采集目标公交站的真实视频数据，用于验证和调整参数；二是把车辆检测和车牌识别换成针对实际场景优化过的模型，并补充业务侧的证据链管理和执法平台对接。实际项目中，误报率控制、系统稳定性和数据合规往往比算法精度更影响最终效果，需要投入足够的精力去打磨。