智慧停车产品线 · 全栈交付

项目背景

公司在运营一套智慧停车 SaaS：车场方用它管车位与收费，车主用它缴费与找车位，保安用它在岗亭处理进出场 与异常放行。业务本身不复杂，复杂的是同一件事要在四种端上自洽——后台改一个计费规则，小程序、岗亭、 财务报表都得跟着对。

业务闭环

角色	在系统里做的事
车主	找附近车场、临停缴费、买包月/短租、租车位、预约、开电子发票
保安	岗亭看实时视频、登记进出场、异常放行、抬落杆
车场运营	配置车场与通道、计费规则、包月套餐、车位与共享规则、看报表与对账
平台运营	多车场/多租户管理、权限下发、支付通道与分账配置

「车位」是贯穿整条线的核心对象：临停占用它、月卡绑定它、共享出租它、托管代运营它。系统里同一个车位 在不同业务下有不同的状态与计费方式，但没有第二份车位数据。

我在其中的角色

全栈开发，团队共同交付这条线，我负责的部分是：

• 后端：包月续费、车位管理费、临停开关、缴费记录聚合、支付回调顺延等接口
• 小程序：业主端首页与附近车场、包月车选场与续费、车辆认证、登录态统一；保安端部分页面
• 管理后台：云岗亭视频与抬落杆权限、通道通知、包月开卡、欠费合并补缴
• 横切：支付通道改造、包体优化、跨租户与跨用户的数据校验

具体推进

支付链路统一

停车业务的缴费入口有六七个：临停出场、待支付订单、包月续费、车位租赁签约、车位管理费、预约。原先它们 各自跳转拉卡拉收银台小程序，链路长、失败率高、回调口径不一。

团队把这些入口统一改造成「小程序内直接拉起微信支付」的主扫模式。我负责的入口在后端同时处理：

• 回调时按业务类型顺延有效期（续费不是从今天算，而是从原到期日算）
• 支付状态查询按实际下单通道调用，避免拉卡拉与微信两条通道混查
• 零元订单与并发下单用分布式锁控制，防止重复开卡

新旧两条通道在页面级并存过一段时间，按车场灰度切换——出问题可以单个车场回退，而不是整站回滚。

计费与账务

临停按阶梯时长计费，包月/短租按有效期计费，共享车位按分成结算，托管车位另走分账。四条计费口径最终都 落到同一张订单与流水上：车场要看收入、平台要看分账、车主要看缴费记录，三者必须能对上同一笔钱。

我参与的部分集中在「有效期」这一层：开卡、续费、补缴、退款都要算对起止时间，后台配置的规则与小程序 展示的口径必须来自同一个接口。

小程序体验与工程约束

业主端有 390 个页面、5 个分包。我重构了停车首页与附近车场推荐，重做包月车的选场与续费交互，并把 「登录态失效」从各页面的零散判断收敛成统一的处理路径。

真机调试时遇到主包超限（2306 KB > 2048 KB）。把 1152 KB 的静态资源迁到 OSS，走统一前缀引用， 再压缩各分包与 tabBar 图标，问题解决——并把「新增图片一律放 OSS」写进了团队规范。

云岗亭

岗亭是这条线上最接近硬件的一段：保安在移动端看实时视频（WebRTC 主通道，MJPEG over WebSocket 备通道）、 处理进场登记与异常放行、抬落杆。团队先做出了整块功能，我补上了视频与抬落杆的细分权限（此前是整块开放）， 以及车辆进出场的实时通知与通道记录的合并展示。

技术亮点

• 一套业务四种端：后台、业主端、保安端、服务端共用同一套状态定义，靠接口契约而非文档对齐
• 支付改造可回滚：新旧两条通道在页面级并存，按车场灰度切换
• 工程约束前置：包体、签名、鉴权这些「非功能」问题写成规范，而不是每次踩坑再修
• 数据只有一份：车位、订单、流水在三类角色之间共享，报表与小程序读的是同一份数据

团队与分工

这条线由后端、前端、测试与产品共同交付。团队负责的部分包括车场与通道建模、计费规则引擎、报表与对账、 支付网关接入、保安端与云岗亭整体功能；我负责上面「我在其中的角色」列出的接口、页面与横切改造。简历里 写项目价值是为了说明这条线解决了什么问题，不表示每一行代码都出自我手。