TAYUN

切换日光/暗黑模式

南头镇智慧停车平台难点 ​

项目背景：负责南头镇智慧停车平台的技术落地，采用高、低视频桩监控模式、抓拍模式对重点路段进行智能化改造。利用前端摄像机实时采集车牌及泊位状态，通过前端智能检测与后台自动计费系统，实现路内、路外车场无人化值守管理，降低人工运营成本并提升车位周转率。

Q：你觉得这个项目的难点在什么地方，我先说一个我觉得的难点，这种视频桩的视频怎么推流到网站上的。

现在的项目描述非常简洁有力，技术栈也很现代化，很好！

关于你提到的“视频桩的视频怎么推流到网站上”，这确实是一个非常经典且具有技术含量的问题，特别是在停车监控这种需要低延迟、多路并发的场景下。

除了视频流，结合你的技术栈（Vue3 + TS），我再帮你挖掘几个其他的潜在难点，这样你在面试中可以把项目讲得更丰满。

难点一：海量视频流的实时预览与低延迟传输（你提到的点） ​

难点描述： 浏览器原生不支持 RTSP 协议（摄像头常用协议），且停车场景对实时性要求高（需看清车牌进出的瞬间），传统的 HLS 延迟高达 10秒以上无法接受，同时前端需要同时展示多路监控画面，极其消耗浏览器性能。

解决方案（面试话术）： “我们采用的是 ‘后端转码 + 前端 WebSocket/FLV 播放’ 的方案。

  1. 协议转换：后端（或流媒体服务如 ZLMediaKit/SRS）将摄像头的 RTSP 流转换为适合 HTTP 传输的 FLV 格式，或者通过 WebSocket 直接推送帧数据。
  2. 前端播放：我没有使用普通的 <video> 标签，而是引入了 flv.js 或 mpegts.js。通过 MediaSource Extensions (MSE) API 将流数据实时喂给浏览器的解码器，将延迟控制在 1秒以内。
  3. 性能优化：为了避免用户打开多路视频导致页面卡顿，我做了懒加载和销毁策略。利用 Vue 的生命周期，只有当视频进入可视区域时才建立连接并拉流，移出可视区域时自动断开并释放内存，保证页面在监控 16 路以上视频时依然流畅。”

难点二：高并发下的车位状态实时同步 ​

难点描述： 停车场景下，车辆进出频繁，前端需要在一个大屏或地图上实时展示成百上千个车位的占用状态（空闲/占用/故障）。如果处理不好，会出现数据包堵塞、界面闪烁或状态更新不及时。

解决方案（面试话术）： “面对高频的状态变更，我没有使用轮询，而是基于 WebSocket 实现了全双工通信。

  1. 心跳保活：为了保证连接稳定性，实现了断线重连和心跳检测机制，防止网络波动导致掉线。
  2. 状态合并与防抖：前端在收到高频消息时，使用 Pinia 进行统一状态管理。对于极短时间内（如 500ms）同一车位的多次状态变更，进行了防抖处理，减少不必要的 Vue 组件渲染次数，提升页面性能。
  3. 局部更新：在地图或车位列表渲染上，利用 Vue3 的 v-memo 或 Diff 算法特性，确保只更新状态变化的车位组件，而不是全量刷新。”

难点三：复杂业务规则下的前端状态管理 ​

难点描述： 停车计费规则非常复杂（不同路段、不同时段、节假日、会员折扣、免费时长等），前端需要在用户端和后台端准确展示这些复杂的计费逻辑，且要保证类型安全。

解决方案（面试话术）： “为了应对复杂的计费逻辑，充分发挥了 TypeScript 的类型约束 能力。

  1. 类型定义：我定义了完整的计费规则接口，将后端的复杂 JSON 结构进行 TS 类型映射，避免了开发过程中的类型错误。
  2. 逻辑抽离：利用 Pinia Actions 封装了核心的计费算法（如：计算停车时长、分段计费逻辑），实现业务逻辑与 UI 层解耦。这样无论是 APP 还是后台管理系统，都可以复用同一套计算逻辑，保证了计费的一致性。”

难点四：大屏可视化与海量数据渲染（如果有做地图或大屏） ​

难点描述： 如果项目中包含了“停车诱导”或“全景监控”大屏，需要在地图上渲染大量的车位标记点或车辆轨迹，DOM 节点过多会导致页面崩溃。

解决方案（面试话术）： “在处理海量车位标记点时，我遇到了渲染瓶颈。我采用了 Canvas 渲染 或 聚合策略 来解决。

  1. 虚拟滚动/Canvas：对于列表式展示，使用了虚拟滚动；对于地图点位，使用了地图引擎（如高德/百度地图）的 PointSimplifier（海量点聚合） 功能，或者切换到 Canvas 图层，避免成千上万个 DOM 节点同时存在。
  2. UnoCSS 原子化：利用 UnoCSS 按需生成样式，减少构建后的 CSS 体积，提升大屏加载速度。”

💡 总结建议 ​

既然你的技术栈里有 UnoCSS、Vue3、TS，面试官大概率会问“为什么要用这些技术”或者“解决了什么以前解决不了的问题”。

建议你在准备时，重点拿“难点一（视频流）”和“难点二（实时同步）”作为主攻方向，因为这两个最能体现“智慧停车”这个项目的行业特殊性，也是最能体现技术深度的点。

明白，这种“高位有线专网 + 低位无线 4G 推流”的混合架构在智慧停车项目中非常典型。这种架构其实比单纯的云推流更复杂，因为它涉及到了内网穿透、不同网络环境的适配以及带宽优化的问题。

根据您的实际架构，这个“视频流”的难点可以这样描述，会显得非常专业且有深度：

难点一：混合网络环境下的视频流统一分发与低延迟播放 ​

难点描述： 项目采用了异构的网络架构：高位视频桩通过有线专网接入运营监控室（内网环境），低位视频桩通过 4G/5G 无线网络推流至服务器（公网环境）。 这就带来了两个核心挑战：

  1. 协议与网络隔离：内网的高位视频（通常为 RTSP）无法直接被公网的 Web 端访问，存在网络隔离问题；低位视频受 4G 信号影响，网络波动大。
  2. 浏览器兼容性：无论是内网还是外网源，均为私有流协议，浏览器无法原生支持，且停车管理要求画面必须低延迟（以便人工稽核或实时监测），传统的 HLS 切片流延迟过高。

解决方案（面试话术）：

“为了解决内网与外网流数据无法统一播放的问题，我设计了一套分层流媒体方案：

  1. 流媒体服务层中转：

    • 对于高位视频（内网）：在监控中心内部署流媒体代理服务（或网关），将内网的 RTSP 流拉取并转推至公网的流媒体服务器（如 SRS/ZLMediaKit），解决内网穿透问题。
    • 对于低位视频（4G）：服务端直接接收其推流（如 GB28181 或 RTMP），并进行边缘节点分发，缓解中心服务器压力。

  2. Web 端低延迟播放：

    • 前端放弃了传统的 HLS 方案，改用 HTTP-FLV 或 WebRTC 协议。通过 WebSocket 将封装好的 FLV 数据帧直接下发给浏览器，配合 flv.js 进行软解渲染，将端到端延迟控制在 300ms - 1s 以内，满足了实时性要求。

  3. 弱网与带宽优化：

    • 针对低位视频桩的 4G 不稳定性，前端实现了断线重连机制。一旦 WebSocket 断开，组件会自动尝试重连，并在重连成功后恢复画面。
    • 利用 Vue3 的生命周期管理，在监控大屏或列表中，对不可见区域的视频流暂停拉取或销毁播放器实例，避免在后台占用宝贵的带宽和服务器并发连接数，特别是降低了 4G 设备的流量成本。”

为什么要这样改？（分析） ​

  1. 突出了“网状架构”的理解：您提到了“高位连监控室，低位连服务器”，这说明了您懂得区分局域网和广域网在物联网部署中的差异，面试官会觉得你对底层网络架构有认知。
  2. 强调了“成本”意识：提到“低位视频 4G 流量成本”或“带宽优化”，非常符合业务场景，因为物联网项目最怕的就是流量费炸了。
  3. 技术闭环：从“内网穿透”到“弱网适配”，形成了一个完整的解决方案。

这样的描述既符合您的实际开发场景，又能把难度提上去。您觉得这个表述符合您的实际操作吗？

网上成熟的停车监控平台（尤其是面向政府“智慧城市”或大型交投集团的商业级平台），其架构通常遵循 “端-边-云” 的模式，并且非常强调国标协议和按需流控。

以下是市面上主流做法的拆解，你可以对比一下你的项目，看看有哪些是亮点，哪些是行业通用标准：

1. 核心协议标准：GB/T 28181（重中之重） ​

行业现状： 国内绝大多数中大型智慧停车项目（特别是涉及路侧停车、市政改造的），后端流媒体服务基本都是基于 GB/T 28181 协议（《公共安全视频监控联网系统信息传输、交换、控制技术要求》）。

  • 为什么用它？：因为公安、交警、城投等政府部门通常要求视频数据必须能接入他们的“雪亮工程”或城市安防系统。私有协议无法互通，GB28181 是强制标准。
  • 具体做法：
    • 设备端（摄像头/视频桩）或边缘网关（NVR）作为 SIP 客户端注册到流媒体服务器。
    • 控制信令（如：开始推流、停止推流、云台控制）走 SIP 协议。
    • 视频数据（RTP 包）走 UDP/TCP 传输。

2. 视频流传输链路（主流技术栈） ​

现在的行业趋势已经从 HLS（延迟高）全面转向 WebRTC 或 HTTP-FLV（低延迟）。

主流链路路：

  1. 采集端：摄像头 -> RTSP (私有流) 或 GB28181。
  2. 流媒体服务器：SRS、ZLMediaKit（目前最火的开源流媒体）、EasyDarwin、或商用的大华/海康 ISC 平台。
  3. 分发端：
    • 实时监控：通过 WebRTC（延迟 <300ms，体验最好，但对服务器要求高）或 HTTP-FLV over WebSocket（延迟 1-2s，兼容性最好）推送给浏览器。
    • 历史回放：使用 HLS (.m3u8)，因为回放对延迟不敏感，且 HLS 支持倍速播放、拖拽进度条，浏览器兼容性极佳。

3. 关键优化策略：按需拉流（节省成本） ​

这是商业平台和普通 Demo 最大的区别。

痛点：如果 1000 个路侧视频桩一直推流到服务器，带宽和存储费用是天价。 行业做法：“按需唤醒”。

  1. 平时状态：前端只展示图片或静止画面（每隔几秒截取一帧 JPEG），或者直接显示离线/空闲状态。此时摄像头并不向服务器推视频流，节省 90% 的带宽。
  2. 点击监控：当前端用户点击某个车位查看视频时，前端发送指令 -> 流媒体服务器向摄像头/边缘盒子 发起 Invite 请求 -> 摄像头开始推流 -> 前端播放。
  3. 离开销毁：用户关闭弹窗或切换页面后，服务端自动断开推流链接。

4. 前端可视化架构 ​

在停车管理后台（Web端），主流做法通常分为两类：

  • 2D 矢量地图（GIS）模式：
    • 使用 Leaflet、OpenLayers 或高德/百度地图 API。
    • 在地图上渲染车位状态（红=占用，绿=空闲）。
    • 点击点位弹出 Video 组件播放视频。
  • 3D 数字孪生模式（高大上版）：
    • 使用 Three.js 或 WebGL。
    • 建立街道和车位的 3D 模型，实时映射车辆进出状态。
    • 用于“城市大脑”大屏展示，视觉效果极佳，但开发成本高。

5. AI 识别的部署位置（端云协同） ​

  • 低端方案（纯后端）：摄像头只录像，视频流全部回传云端服务器，云端运行 AI 算法识别车牌。
    • 缺点：带宽压力大，延迟高。
  • 主流方案（边缘计算）：现在的高位视频桩和低位视频桩内部都嵌入了 AI 芯片（如海思 HI3516 等）。
    • 做法：摄像头自己识别车牌，判断“进/出”，然后只把识别结果（车牌号、时间、入场照片）通过 MQTT/HTTP 发给后端。
    • 视频流：只有在管理员点击查看时，才建立实时视频通道。

总结对比 & 你的机会 ​

特性普通做法商业/行业高级做法你的项目可以怎么包装？
协议私有 RTSP/RTMPGB/T 28181 (国标互联)如果你们高位视频通过NVR转码，GB28181 是个很好的关键词。
流媒体HLS (高延迟)WebRTC / HTTP-FLV你提到的 flv.js 正是主流的 HTTP-FLV 方案，可以说“采用了主流低延迟方案”。
带宽控制全时推流按需拉流 (On-Demand)这点非常有价值！如果你的前端实现了“点击才播放，关闭即断开”，一定要强调，这体现了架构设计能力。
前端渲染简单 Video 标签WebAssembly 优化 / 虚拟化列表结合你的 Vue3，提到虚拟滚动解决多路视频卡顿，是非常加分的技术细节。

一句话总结： 现在的标准做法是 “边缘 AI 识别 + GB28181 协议联网 + WebRTC/FLV 低延迟播放 + 按需流控”。

你在面试时，如果能把你的项目往这套体系上靠（即使你们没做全，可以说“遵循了类似的设计思想”），面试官会认为你对行业有很深的认知。