2. 前端与接口设计——Vue生态下的信息架构与交互策略
3. 从Centos部署到跨域问题：一趟完整的踩坑实录
4. 系统性能与安全加固——并发冲突、防刷与数据一致性
5. 复盘：智能停车系统的价值与扩展方向
6. 前端交付后的真实反馈：从“能用”到“好用”
7. 独立开发者视角：这套系统的商业价值与运维思考
8. 可复用模块提炼：从停车项目到任何SSM+Vue项目
1. 为什么选择SSM+Vue：传统项目里的务实选型
最初接到这个项目时，我的第一反应是：智能停车系统不是应该用微服务、容器编排那一套才够“智能”吗？但真正分析了需求之后，我的结论是——SSM（Spring + SpringMVC + MyBatis）搭配Vue，反而是这类业务系统性价比最高的组合。
先说说这套系统解决什么问题。智能停车系统的核心不是停车本身，而是车位资源的动态分配与计费管理。一个典型的场景是：车主进入停车场，系统识别车牌，引导到空闲车位；车主办完事出场，系统计算时长，自动扣费或抬杆放行。这背后涉及车牌识别、车位状态实时更新、订单生成、会员余额变动、高峰期并发抢位等多重业务逻辑。对于这种强事务、强数据结构约束、并发量可控的业务场景，SSM的经典MVC分层和MyBatis的细粒度SQL控制，反而是最可控的选择。
我的技术选型思路很简单：
| 层级 | 选型 | 理由 |
|---|---|---|
| 后端基础框架 | Spring + SpringMVC | 依赖注入与事务管理成熟稳定，资料多、排查方便 |
| 持久层 | MyBatis | SQL可控性极强，适合停车场这种多表关联复杂的计费查询 |
| 前端 | Vue 2 + Element-UI | 组件化开发效率高，后台管理界面快速成型 |
| 数据库 | MySQL 5.7 + InnoDB | 支持行级锁，适合订单并发场景 |
| 车牌识别 | 开源OCR接口（HTTP调用） | 降低硬件成本，普通摄像头即可完成识别 |
注意一个关键选择：我这里刻意没有用MyBatis-Plus。虽然是智力劳动，但在计费、出入场这类高频写操作上，我习惯自己掌控SQL语句，自带的分页和条件构造器在复杂查询中反而会变成黑盒。
从我的实操经验看，很多人在这个项目上栽跟头，不是因为框架不够先进，而是因为根基没打牢就开始堆功能。SSM虽然“老”，但它逼迫你理清Controller层该干什么、Service层该干什么、Mapper层该干什么，这种清晰的边界感正是业务系统最需要的。
这套系统的定位也明确：不是给大型商业停车集团做的云端SaaS平台，而是给一个单停车场（几百个车位规模）、或一个小型物业公司自营管理的系统。所以不需要分布式事务、不需要消息队列，一台4核8G的云服务器完全可以扛住单场高峰时段的全部请求。
如果你正在纠结毕业设计或自研项目选什么技术栈，我的建议是：先评估系统日均请求量和事务复杂度，再决定要不要上微服务。智能停车系统这种业务，SSM+Vue足够扎实，而且面试官/验收老师看到你能把事务边界、SQL性能、并发调优讲清楚，比一个流水线生成的分布式项目更有说服力。
2. 核心模块拆解：智能体现在这五个功能点上
“智能”这个词被用滥了，但智能停车系统的“智能”是有具体落点的。沿着车主的完整使用路径（入场 → 寻位 → 计费 → 出场），我拆出了五个核心模块，每个模块都对应明确的业务逻辑和数据表设计。
2.1 车牌识别与无感入场
入场口架设一个普通高清摄像头，拍下车牌照片后调用车牌识别接口，返回车牌号。系统拿到车牌号先做两件事：
- 判断是否为月租车/固定车：如果是年卡/月卡车，且账户状态正常，直接抬杆放行，记录入场时间。
- 判断是否为临时车：临时车也放行，但生成一条未完结的停车记录，同时抓拍入场照片，方便出场时核对。
这里有一个非常容易踩坑的点：车牌识别是异步的，但抬杆判断是实时的。也就是说，摄像头拍到车牌后，识别接口可能要1~2秒才能返回结果，而车辆的入场体验要求这个时间尽量短。我的做法是采用异步线程池处理识别请求，主线程超时10秒内完成判断；识别失败时，降级为手动取票入场模式，通过后台录入车牌。这种降级设计是实际运营中必备的，不能省。
// 车牌识别异步调用核心逻辑（伪代码参考） public void handleEntry(VehicleEntryDTO dto) { // 1. 先落库入场记录，拿到recordId Long recordId = entryRecordMapper.insert(dto.buildRecord()); // 2. 提交异步识别任务 plateRecognitionService.asyncRecognize(dto.getImageUrl(), result -> { if (result.isRecognized()) { entryRecordMapper.updatePlateNumber(recordId, result.getPlateNumber()); // 3. 查询用户是否月租车，决定是否抬杆 Member member = memberMapper.selectByPlate(result.getPlateNumber()); gateService.openGate(member != null && member.isActive()); } else { // 降级：通知人工介入 notifyManualReview(recordId); } }); }2.2 车位状态监测与空闲车位引导
停车场内每隔两个车位安装一个地磁感应器，或者利用原有摄像头做视频检测，判断车位上是否有车。状态实时同步到系统，车位状态分为空闲/占用/预订/故障四种。
前端大屏（大屏展示页）通过WebSocket实时订阅车位状态，一旦有变化，立即刷新大屏上的车位分布图。车主的手机端则显示“剩余车位数”和“推荐停车区域”——推荐逻辑很简单：优先推荐离入口最近且同一区域内连续空闲车位数量最多的区域，减少车主在库内绕行的时间。
这个模块的核心技术点在状态不一致问题上。比如车主开车压过检测器但没停进去，地磁会先触发“占用”，然后车又走了，又恢复“空闲”。如果同步不及时，大屏上就会出现闪烁。我在这里做了一层缓冲：状态变更需要在连续两个上报周期内保持一致才更新，避免瞬态抖动。
2.3 计时计费与优惠规则引擎
计费是整个系统里最容易出业务Bug的地方。停车场的计费规则远比一般人想象的复杂：
- 前15分钟免费（临停常见），超过后按小时计费，不足1小时按1小时算
- 夜间时段（22:00-06:00）封顶收费
- 月租车固定费用，不按次计费
- 会员折扣（充值赠送余额、折扣费率）
- 商场消费满额免费2小时（需要对接商场小票核销系统）
我设计了一张billing_rule表，用JSON字段存储规则表达式，计费引擎统一解释执行。这么做的好处是，新增一种“节假日折扣”之类的规则时，不需要改代码、重新发版，只需要在后台配置规则。
{ "ruleName": "临时车普通计费", "freeMinutes": 15, "basePricePerHour": 5.0, "nightCapEnabled": true, "nightCapStart": "22:00", "nightCapEnd": "06:00", "maxNightFee": 15.0, "discountRules": [ { "type": "member", "rate": 0.85 }, { "type": "coupon", "code": "MALL_FREE_2H", "freeMinutes": 120 } ] }2.4 会员体系与余额扣费
会员模块其实就是一个轻量级的账户体系：手机号注册、车牌绑定、余额充值、扣费记录、发票申请。扣费的时机我做了两个版本的对比——出场时一次性扣，还是预冻结金额。
最终我采用出场时结算扣费，因为停车时长是不确定的，预冻结反而会造成不必要的资金占用。扣费操作放在数据库事务里，使用乐观锁（version字段）防止并发扣费导致余额变负数。
UPDATE member_account SET balance = balance - #{deductionAmount}, version = version + 1 WHERE member_id = #{memberId} AND balance >= #{deductionAmount} AND version = #{oldVersion}这条SQL同时完成了余额校验和扣款，只要影响行数为1，则扣费成功。如果不是1，说明并发冲突，重新查询账户余额再执行一次，且最多重试3次。
2.5 报表统计与运营决策
系统内置三种核心报表：营收日报/月报（按收费场景、支付渠道、时段三个维度分组统计）、车位利用率统计（每时刻在库车辆数 / 总车位数）、车辆进出频次分析（识别高频临停车，转化为月租车转化目标）。
这些报表是物业方真正会用的功能。实际操作中，比较难的不是SQL本身，而是统计数据量增长之后，报表查询会不会拖垮业务库。我对日报统计做了预聚合：夜间闲时跑定时任务，把当天数据按维度汇总到统计表，白天查询只读汇总表。针对超过三个月的历史报表，则引导用户下载离线Excel，数据库只保留近三个月的明细。
3. 数据库建模与事务边界：一张订单表背后的设计取舍
很多新手在做数据库设计时，习惯把所有业务都进“订单表”，结果一张表几十个字段，既有车牌又有金额还有优惠券信息，后期维护起来非常痛苦。我这个项目的核心表设计是拆分账单与流水分账的思路。
3.1 核心表结构一览
| 表名 | 核心字段 | 作用 |
|---|---|---|
member | id, phone, plate_number, balance, member_type, version | 会员与账户 |
parking_record | id, plate_number, entry_time, exit_time, entry_image, exit_image, status | 每一次出入场的完整记录 |
billing_order | id, record_id, total_amount, discount_amount, payable_amount, status | 一条停车记录对应的结算单 |
billing_flow | id, order_id, type, amount, create_time | 每一笔资金的流向明细（充值/扣款/退款） |
parking_space | id, area_no, space_no, status, sensor_status | 车位基础信息与状态 |
space_status_log | id, space_id, old_status, new_status, change_time | 车位状态变更历史，用于审计与统计 |
我特别建议单独建billing_flow流水表，它的价值体现在两个场景：第一，会员充值时，出现金额对不上，可以通过流水表回溯每一笔变动；第二，财务审计时，总账必须 = 所有流水之和，这是一条不可妥协的对账原则。
3.2 事务边界设计：什么必须在一个事务里
我遇到过的最严重的Bug是：出场时扣了用户的钱，但停车记录的状态没有更新成功，结果用户下次入场被拦截在门外，后台一对账发现资金和记录不一致。
排查之后发现罪魁祸首就是事务边界没划对。更新记录状态、生成账单、扣会员余额这三个操作必须放在同一个事务里，要么全部成功，要么全部回滚。Spring的@Transactional注解虽然方便，但它默认只对RuntimeException回滚，对检查异常是不回滚的，这个细节很多人不知道。
@Transactional(rollbackFor = Exception.class) public ExitResult handleExit(ExitRequest request) { // 1. 更新停车记录，写入出场时间 // 2. 计算费用，生成账单 // 3. 扣费（会员走余额，临停走扫码支付回调） // 4. 标记订单为已完成 return buildResult(); }另一个经验是：不要把第三方接口调用放进本地事务里。比如调用支付回调、短信通知、车牌识别请求，这些外部调用一旦放进事务，会长时间持有数据库连接，在高并发下直接打爆连接池。我的处理方式是事务内只做数据变更，事务提交后通过事件监听器异步执行外部通知。
3.3 索引设计与慢查询治理
一张parking_record表在高频进出场场景下，一天能产生几千条记录，一个月下来就是十几万条。如果不加索引，出场时按车牌查询未完结记录，全表扫描会越来越慢，直到用户堵在出口。
我的索引设计原则很简单：
- 所有外键字段建索引（
member_id、space_id） - 高频查询条件建联合索引（
plate_number + status + entry_time DESC） - 账单表按
create_time建索引，支撑日报统计 - 凡是用到
ORDER BY或GROUP BY的字段也要考虑索引
实操中还发现一个坑：MySQL在WHERE条件里对字段做函数操作会导致索引失效。比如统计某天的订单，有人写WHERE DATE(create_time) = '2024-01-01'，这个查询完全走不了索引，数据量大时慢到怀疑人生。正确写法是WHERE create_time >= '2024-01-01 00:00:00' AND create_time < '2024-01-02 00:00:00'，走范围索引，速度会有几十倍的差距。
4. 前端与接口设计：Vue生态下的信息架构与交互策略
前端的核心任务是两套界面：车主移动端（H5）+ 后台管理端（Web）。我没有做独立APP，因为停车场这种低频场景，用户不愿下载APP，H5扫码即用才是合理的交互路径。
4.1 端侧功能和页面结构
| 端 | 页面 | 核心能力 |
|---|---|---|
| 车主H5 | 首页、缴费、绑定车牌、充值、发票、停车记录 | 查费、缴费、绑定车辆、充值免排队 |
| 后台管理 | 实时大屏、车位管理、订单管理、会员管理、计费规则管理、报表 | 运营监控与业务管理 |
| 岗亭端 | 入场/出场操作台 | 人工干预、异常放行、收费确认 |
Vue Router做的路由守卫一定要用上，后台管理页全部拦截未登录用户，路由跳转前先判断Token是否存在，不存在则重定向到登录页。这个做过一遍就知道，如果不做全局拦截，开发时自己直接改URL跳过登录，上线之后用户也能跳过，这是安全隐患。
4.2 跨域问题与代理配置
本地开发时，前端axios请求后端接口，必然遇到跨域问题。我在两个环境分别做了处理：
- 开发环境：Vue CLI的
devServer配置代理，所有/api前缀请求转发到http://localhost:8080，绕开跨域。 - 生产环境：后端反向代理统一入口，前端请求同域路径，不存在跨域。如果前后端分离部署在不同域名，则后端必须配置
CORS跨域过滤器，但不能用allowCredentials=true加*这种通配写法，这是Spring官方明确不建议的，实际生产也容易被攻击。
开发时踩过的最无解的一个坑是：前端请求正常发出，后端也收到了，但浏览器控制台报跨域错误。排查了一圈，是因为后端Response Header里的Access-Control-Allow-Origin值写错了，被设置成了“请求实时的Origin”，而不是“配置的固定白名单”。这个问题在CORS过滤器自定义实现里很常见，建议直接使用SpringMVC提供的CorsRegistry，不要自己造轮子。
4.3 状态同步：WebSocket还是轮询
车位大屏需要实时数据，我对比了两种方案：
- 短轮询：每10秒拉一次接口，实现简单，但体验一般，大屏数字跳跃有延迟感。
- WebSocket：后端在车位状态变化时主动推送，延迟控制在1秒内，体验顺滑。
因为单停车场规模不大，我最后用了WebSocket。但要注意的是，WebSocket连接在服务端重启时会全部断掉，前端需要注册onclose事件，重连并刷新一次数据。我一共做了三层兜底：应用启动时主动拉取全量数据、收到推送时增量更新、断线重连时再拉一次全量快照。
前端交互的一个小细节，很多设计师会忽略：车主的缴费按钮要足够大，因为在出口网络可能不稳定，用户一拍车就必须掏出手机完成支付，任何多余的跳转和验证都是在制造拥堵。我的缴费页面做了极简优化——车牌号自动带入，只需要点击确认支付，支付完成后调用出场接口自动抬杆。
5. 从Centos部署到跨域问题：一趟完整的踩坑实录
这一部分是我最想分享的，因为几乎每个坑都浪费过我至少半天的时间，这篇文章把排查思路完整讲清楚，希望能帮你少走弯路。
5.1 部署环境的完整准备
生产环境我选择了CentOS 7系统 + JDK 8 + Tomcat 8.5 + MySQL 5.7。因为这是一个传统的SSM项目，采用的是war包部署到Tomcat的方式。整个部署流程我走通一遍后，整理成了脚本，后面每次发布只需要执行一条命令。
# 一键部署脚本核心流程（参考） mvn clean package -DskipTests scp target/parking-system.war root@your-server:/opt/tomcat/webapps/ ssh root@your-server "systemctl restart tomcat"这里有一个非常反直觉的坑：很多人以为项目增大之后，部署慢是因为代码编译，实际上大部分时间耗在静态资源上。Vue构建出来的JS文件动辄几兆，而Tomcat默认的HTTP传输没有启用压缩，传到服务器上再加载到浏览器，首屏时间长得离谱。后来我配置了Tomcat的压缩传输：
<Connector port="8080" protocol="HTTP/1.1" compression="on" compressionMinSize="1024" compressibleMimeType="text/html,text/xml,text/plain,text/css,application/javascript,application/json"/>就这一个配置，首屏加载时间从8秒降到了2秒。
5.2 数据库时区引起的计费错误
上线后第一周就收到一个诡异反馈：部分订单计费时间凭空多出了14个小时。一开始以为是计费引擎逻辑问题，排查入出场时间，发现入场时间正确、出场时间也正确，但计算时长却差了14小时。
后来发现根因在MySQL连接时区配置。jdbc.url里没有指定serverTimezone，服务器默认时区是UTC（协调世界时），而应用服务器是东八区。JDBC驱动读取数据库时间时按UTC解释，插入应用里的日治时间差异就整整偏了一个时区。我重新启用的配置是这样的：
jdbc.url=jdbc:mysql://localhost:3306/parking?useUnicode=true&characterEncoding=utf8&useSSL=false&serverTimezone=Asia/Shanghai这个坑属于经典的“环境时区不一致”，特别容易在容器化部署里爆发。如果你在某云上用默认系统时区，大概率就是UTC，建议从第一天就在所有相关配置里写死Asia/Shanghai，不要在代码里用new Date()直接存时间戳。
5.3 Nginx反向代理与动态资源缓存策略
前端打包后的index.html和后端接口，我统一用Nginx反向代理。但出现了一个性能问题：前端每次发版后，用户刷新页面加载的仍然是旧版JS，因为浏览器把整个index.html缓存了。
解决方案比较经典：
index.html设置Cache-Control: no-cache，每次都向服务器校验文件是否更新- 静态资源（JS、CSS、图片）设置
Cache-Control: max-age=long并加上文件名hash
Vue CLI打包产物本身就带哈希后缀，所以只需要在Nginx里对/index.html单独禁用缓存即可。操作下来，发版之后用户强刷一次就能加载最新版本，之后再刷新都走本地缓存，性能与更新频率兼得。
5.4 高并发入场时段：数据库连接池被打满
项目运行到第二个月，早高峰入场高峰期偶发接口超时。查看日志发现大量Connection is not available, request timed out异常——连接池被耗尽了。
排查发现，Tomcat默认连接池最大连接数是100，而早高峰几百辆车同时入场，每辆车入场要完成“插入记录 + 车牌识别回调更新 + 会员查询”等多步数据库操作，连接占用时间被拉长。我把最大连接数调整到200，同时给车牌识别回调的更新逻辑增加了连接释放的幂等性保护，确保每次请求都在finally里返回连接。
我做了一个基准压测：200并发下连接池排队的P95延迟从3400ms降到180ms。这里值得强调一个信条——数据库连接池不是越大越好，每增加一个连接，数据库端就多一个线程上下文切换的开销，真实情况通常是100~200这个区间比较合适，配合连接池的空闲超时配置，才能保证峰值期稳定性。
6. 系统性能与安全加固：并发冲突、防刷与数据一致性
功能全部跑通之后，我花了将近一半的时间在性能和安全上。这一段内容是“能跑的项目”和“能上线的项目”之间最大的差距。
6.1 并发场景的幂等保护
如果说整个项目里让我最担心的事，那就是同一个车位被两个车主同时预订，或者同一个订单被重复缴费。这类并发问题不能靠前端按钮置灰来解决，后端必须有幂等保护。
我设计了三种层次的幂等方案：
| 方案 | 适用场景 | 实现方式 |
|---|---|---|
| 乐观锁Version | 账户余额扣减、库存扣减（车位） | 更新时校验版本号 |
| 数据库唯一约束 | 订单幂等 | 预生成唯一订单号，插入时靠唯一索引去重 |
| 状态位校验 | 订单状态流转 | 逻辑删除/状态变更时先判断当前状态是否合法 |
以出场缴费为例，流程中多次调用支付回调（微信/支付宝回调最少送达一次，这是常态）。如果回调处理不是幂等的，用户就会出现“扣了两次款”的严重事故。我在支付回调里先查billing_order的状态，只有“待支付”才执行记账流程，而且整个记账流程放在一个数据库事务里。如果状态已经是“已支付”，直接返回成功，不再重复扣款。
6.2 前端防刷与接口限流
停车缴费、验证码发送这类接口，如果不做防护，很容易被脚本薅羊毛。比如短信验证码接口被刷，一条短信几分钱，被刷几千条也是不小的损失。我的处理是TokenBucket限流 + IP黑名单双管齐下。
// 基于Guava RateLimiter的接口限流示例（思路参考） private RateLimiter smsLimiter = RateLimiter.create(5.0); // 每秒5个令牌 @RequestMapping("/sendSmsCode") public Result sendSmsCode(@RequestParam String phone) { if (!smsLimiter.tryAcquire()) { return Result.error("请求过于频繁，请稍后再试"); } // 正常业务逻辑... }在网关层，我加了一层按IP维度的接口频率统计，同IP同一分钟内超过阈值的请求直接拒绝。针对停车场场景，我专门对“扫码支付”接口的同一个订单号绑定了短时间窗口去重，彻底堵住了重复支付和并发支付的漏洞。
6.3 登录态安全与权限控制
管理系统如果只有简单的管理员账号密码，那离被入侵也不远了。我做了几层安全控制：
- 管理员密码采用加盐哈希存储，不能明文入库
- 登录成功后签发Token，并设置过期时间（默认8小时），用户长时间不操作需要重新登录
- 后台按钮级权限：资产管理员、收费员、运维管理员各自有不同菜单权限，避免误操作或越权
Token方案我采用的是无状态JWT——验签无需查库，但带来的问题是无法主动踢人下线。对于这个项目规模来说，用JWT配合Redis黑名单是兼顾体验与安全的成熟方案。如果某个管理员账号被盗，运营侧可以立即把该账号加入黑名单，强制失效。
6.4 数据备份与容灾演练
数据库是他们最核心的资产，每天凌晨的定时备份是必需品。我写了两个备份脚本：
- 每日全量备份：凌晨利用mysqldump全量备份到异盘目录，保留7天
- 实时Binlog同步：通过Binlog监听主库变化，同步到备份库，实现分钟级容灾
实测恢复演练很有必要，我做过一次全量恢复测试，发现如果不提前演练，真到故障时可能连恢复流程都不清楚，或者备份文件本身有损坏。这个经验推荐给所有自己维护数据库的人。
7. 复盘：智能停车系统的价值与扩展方向
项目交付之后，我沉淀了一份完整的复盘文档。核心观点是：判断一个系统做得好不好的标准，不是技术新不新，而是它在真实环境中扛不扛得住运营的折腾。
这套SSM+Vue的智能停车系统，在单停车场日流量2000车次以内的场景下，表现非常稳定。但我也清楚它的能力边界，所以下面的扩展方向是我如果再来一遍，会重点考虑的设计。
7.1 多停车场架构扩展
目前系统是单停车场版本，如果物业方扩张到多个停车场，就需要在数据库层面引入parking_lot维度，所有的表增加这个字段，并将会员账户体系升级为跨场通用。这里最有挑战的是跨场月卡通用与出场结算——车在A场入场，B场出口扫码时，系统要能查到在A场的入场记录并完成计费，这需要所有记录表支持跨场查询，索引设计也要做一次升级。
7.2 预约车位的进阶玩法
预约功能在医院的停车场景里价值很大。实现预约后，核心变化是车位状态从“空闲/占用”变为“已预约”，预约时段内其他车辆不能占用。同时需要设计超时释放策略：预约车辆迟到超过15分钟自动释放车位，并可能收取少量爽约金。
预约功能的难点不在技术，而在业务规则的制定。我建议预约规则配置化，不要写死在代码里，因为不同场所的容忍度完全不同。
7.3 数据可视化与智能化升级
现在的报表已经解决了“数据有没有”的问题，下一步是“数据怎么用”。基于积累的进出场数据，可以做：
- 预测未来一小时的车位占用率，提前引导车辆分流到低峰区域
- 识别“僵尸车”（长期未出场车辆），自动提醒运营人员
- 会员流失预警：针对连续30天未产生停车记录的月租用户推送续费提醒
这些都属于数据应用，技术上并不复杂，但带来的运营收益比很多花哨的功能更实在。
8. 前端交付后的真实反馈：从“能用”到“好用”
系统上线三个月后，我做了一次用户回访。最让我意外的不是功能Bug，而是用户使用的行为模式和我想象的完全不同。这里挑两条最典型的反馈，很有参考价值。
第一条：车主在出口扫缴费二维码时，很多人的手机网络信号很差，页面打开要好几秒。虽然我在前端做了极简页面，但默认加载的还是完整的SPA应用，首屏几百KB的JS对弱网用户太不友好了。优化方案是把缴费页独立成纯静态的单HTML页，不做任何框架依赖，只保留“查询车牌-展示费用-拉起支付”三个功能。改造后，弱网下首屏时间从4秒降到1秒。
第二条：后台管理端的收费员岗位，大多数操作电脑都比较旧，Chrome版本也低。Vue 2 + Element-UI在低版本浏览器下其实兼容性还可以，但WebSocket在某些老旧浏览器上不稳定。我加了sockjs的降级方案，WebSocket不可用时自动回退到轮询。
这些反馈给我的启发是：技术体验好不好，不取决于技术栈的新旧，而是取决于对真实用户环境的尊重。前端“能用”和“好用”之间，隔着的就是对网络条件、终端环境、使用习惯的细致考量。
9. 独立开发者视角：这套系统的商业价值与运维思考
如果你把这件事当成一门小生意来看，很有参考价值。抛开技术层面，这套系统的商业价值体现在三个点：帮物业降本、帮车主增效、帮运营方获客。
9.1 成本与收益核算参考
以我给某中型停车场做的模拟测算为例：
| 项目 | 情况 |
|---|---|
| 硬件成本（摄像头、地磁、道闸） | 约2~4万元（运营方可分阶段铺设） |
| 系统部署成本（服务器、域名、带宽） | 每年约2000~4000元 |
| 人工成本节省 | 减少一个岗亭收费员，一年省约5~7万人工成本 |
| 车主逃费漏费减少 | 每月挽回约500~2000元（视停车场管理情况） |
| 广告与增值服务 | 会员充值沉淀资金、车险/洗车广告位等 |
对物业来说，这套系统的投资回收期通常不超过半年。对独立开发者来说，这类系统还有一个很现实的优势：它是有明确交付价值和业务闭环的项目，能快速建立起你和客户之间的信任，方便后续的维护续费和其他软件合作。
9.2 长期运维必须想清楚的三件事
系统交付只是开始，真正的精力投入在运维上。想长期维护好一套自研系统，这三件事必须提前想清楚：
- 数据库备份要自动化且可验证。别等出事才发现备份文件是坏的。
- 留好后门可观测手段。线上出了问题，无法远程看日志排查，基本就只能干瞪眼。建议接入统一日志平台，并保留一键获取线程快照和JVM监控的能力。
- 接口文档要维护。前后端分离后，接口字段随便改，但又没人维护文档，三个月后再接手的人会非常痛苦。把Mock接口数据和字段定义固化到文档工具里，能避免很多坑。
9.3 需求变更管理
系统上线后，客户一定会源源不断提出新需求。我统计了一下，后期60%的需求都是“加个字段”“加个导出”“加个统计维度”这类小改动。这类需求虽然不大，但最考验系统设计的扩展性，比如规则引擎是否真正配置化、报表查询是否抗得住新增维度。
所以我在开发时坚持一个原则：凡是业务上可能变化的东西，全部参数化、配置化，不写死。计费规则、优惠组合、停车费用封顶逻辑、免费时段等都用表或JSON存起来。项目开发初期的确多花了一点时间，但每次客户提修改需求时，我只需要在后台改一条配置，那种轻松感是值得的。
10. 可复用模块提炼：从停车项目到任何SSM+Vue项目
写到最后，我想分享一个个人心得：SSM+Vue这套组合虽然“传统”，但它沉淀下来的工程模式，放在任何中小型业务系统里都是通用的。这个项目做完后，我整理了四个可复用模块，下面按价值从高到低列一下。
10.1 通用权限管理模块
基于SpringMVC拦截器 + JWT的登录鉴权模块，大概300行代码，可以换肤到任何管理后台系统。核心逻辑就三块：登录认证、菜单权限加载、接口访问控制。
提示：权限控制的粒度不要太细到按钮级，否则维护成本极高。绝大多数中小型系统做到“菜单级”就够了，按钮级权限只给财务或管理员这类敏感角色单独用。
10.2 可配置规则引擎
就是前面提到的billing_ruleJSON配置引擎。把这个模式一般化，可以应用到很多需要灵活计费/折扣/风控规则的场景。比如电商的运费模板、预约系统的取消规则、会员积分规则，底层逻辑都是“规则字段 + 解释器”。
10.3 日志链路追踪工具
我在项目中实现了一套简单的TraceId透传方案：请求进入Controller时生成UUID写入ThreadLocal，所有后续日志都带上这个ID，并用拦截器在服务间调用的HTTP Header中透传。排查线上问题时可以按TraceId把所有相关日志拉出来，效率提升非常明显。
10.4 数据指标口径统一
项目里遇到了“运营看的营收和财务看的营收对不上”的经典问题。根因是两边的统计口径不同——运营看的是“支付成功的订单”，财务看的是“已结算且未退款的订单”。后来我在系统里定义了一套标准的指标口径文档，并让所有报表SQL都依赖统一的视图而不是各写各的查询，问题就解决了。这也算给所有数据类项目的一个友情建议。
写在项目交付之后
整套系统从需求梳理、数据库设计、前后端开发、部署上线到持续迭代，大概花了100多天时间，基本都是晚上和周末在做。回头看，最值钱的不是代码本身，而是完整经历了一款商业软件从0到1的全过程——包括和客户的沟通、和真实并发过招、和运营数据博弈。
如果你正在准备做类似项目，我的建议是：不要只看框架的先进性，把注意力放在事务边界、并发幂等、SQL索引、部署时区、缓存策略这些细节上。这些才是决定系统能不能真正跑起来的关键。
最后再分享一个我个人的习惯：项目里所有关键SQL和配置，我都写了注释说明“为什么这么写”。三个月后回看代码，你会感谢当时的自己。
