超级简历WonderCV商场停车场管理系统，这名字看着像毕业设计，其实背后牵连的问题还真不少。我当时接手这个项目时，需求很简单：用Java后端技术栈，实现商场停车场的车辆进出管理、车位管理、收费结算和基础的数据统计，要能跑、要稳定、要有完整文档。SpringBoot整合SSM是我最终的选择，原因也很实在——SpringBoot负责自动配置和项目骨架，SpringMVC处理请求分发，MyBatis专注SQL映射，这套组合在Java后端领域已经高度成熟，从Controller到Service再到Mapper，层层清晰，出了问题网上随便就能搜到解决方案，部署也不需要额外安装复杂的中间件。这篇文章不打算讲什么高深原理，就把这个系统的需求定位、表结构、核心业务逻辑，还有我实际开发中踩过的坑，从头到尾认真捋一遍，给后面要做类似项目或者想了解停车场管理系统整体设计的朋友一个直接能用的参考。
1. 需求定位与技术选型：为什么是SpringBoot+SSM
1.1 商场停车场景的核心诉求
开发任何一个系统，第一步一定是搞清楚业务场景到底要解决什么问题。商场停车场和路边停车场、小区地下车库最大的区别在于：车流量大且集中，周末和节假日会频繁出现满场排队，用户对出场效率极其敏感；管理方则关心两个数字——停车费收入和车位周转率。围绕这两个指标，系统必须具备几个核心能力：
- 车辆进来能快速登记，车位数和状态实时可见，满位时能提前提示，避免车辆开到入口才发现没有位置。
- 车辆要出去时能快速结算费用，收费规则清晰透明，最好支持多档计费，比如免费时长、首小时高峰价、超时阶梯价、每日封顶。
- 所有进出记录可追溯，账目要和收费报表对得上，方便财务对账。
- 管理员能配置收费规则、管理车位信息，而不是改个价格还要动数据库。
这是一套完整的闭环：车辆入场产生记录，记录绑定车位状态，出场时基于时长计算费用，费用落到报表，报表反过来支撑管理决策。弄清楚这个闭环，后面写代码的边界就清楚了。我在做需求分析时只用了一页纸画流程图就把核心逻辑定下来了，后期开发的返工成本很低。
1.2 技术栈搭配的选择逻辑
技术选型没有绝对的"最好"，只有"最合适"。这个项目我最终定了四个关键选型：SpringBoot做项目基座、SpringMVC做Web层、MyBatis做持久层、MySQL做存储。
为什么用SpringBoot而不是传统SSM的XML全家桶？核心原因是配置成本。传统SSM需要手写数据源配置、事务管理器、扫描注解等一堆XML，SpringBoot直接把常用配置都变成了自动装配，内嵌Tomcat，打一个JAR包就能跑。这不是偷懒，是效率。框架的作用是屏蔽繁琐，让开发者专注于业务代码，尤其是这种规模的项目，完全没必要一上来就搞分布式微服务那套。
为什么用MyBatis而不是JPA？停车场管理系统的SQL复杂度不低，车辆入场要条件更新车位状态，计费查询要按时间段分组统计，报表要按天/周/月聚合，MyBatis允许你用原生SQL精确控制每一条语句，resultMap还能处理复杂的字段映射，这在JPA的自动SQL里反而是个麻烦。SpringMVC的定位更不用多说，它就是Spring家族里处理HTTP请求的标准方案，和SpringBoot无缝衔接。
前端方面，后台管理界面我用了Layui配合原生HTML页面。Layui上手快、组件齐全，表格、表单、弹窗都有现成封装，适合快速搭建管理后台，同时不需要引入Node构建链路，维护成本低。移动端扫码入场那一块直接用HTML5页面调后端接口，保证基本可用性。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 系统架构与功能模块划分
2.1 分层架构设计
整个系统延续了经典的三层架构：Controller层接收请求、做参数校验、返回统一结果封装；Service层承载业务逻辑；Mapper层负责数据库交互。严格分层带来的收益是，出问题的时候定位非常快——前端报接口错误，先查Controller；业务逻辑结果不对，只看Service；SQL执行效率低，直接看Mapper。互不干扰。
项目结构上，我按功能和分包两层来组织。顶层按技术角色分包，便于一眼看清层级关系；包内再按业务模块组织ServiceImpl，避免上百个Service类堆在一起。一个典型的Controller方法只做三件事：接收参数、取当前登录用户上下文、调用Service后把结果传给Result对象直接返回。
RESTful接口设计上，统一使用JSON作为数据交换格式，接口路径围绕资源命名，比如/api/parking/record/entry表示入场、/api/parking/record/exit表示出场。返回结构封装成统一结果类，里面包含状态码、消息和数据三个字段，前端不管调用哪个接口，解析模式都是一样的，联调阶段省了很多沟通成本。
2.2 功能模块清单
在功能拆解上，我把系统切成了六个模块，每个模块都有明确的职责边界：
- 管理员认证模块：负责登录、注销和会话校验，是所有操作的安全门槛。
- 车位管理模块：维护车位基础信息，包括编号、区域、类型，同时实时跟踪车位的占用状态。
- 车辆入场模块：录入车牌号后查询空闲车位，分配车位并生成入场记录。
- 车辆出场模块：根据车牌号查询在场记录，计算停车时长和费用，完成结算后释放车位。
- 收费配置模块：设置计费规则参数，这部分做成可配置，运营人员能自己调整价格体系。
- 数据统计模块：展示累计收入、在停车辆数、今日进出流量等核心指标，图表化呈现。
这个模块拆分遵循了一个原则：高内聚低耦合。车位状态的变更只发生在入场和出场两个动作里，收费规则只被出场和报表引用，每个模块都能独立调整而不用带着其他模块一起改。另外我还预留了会员模块的扩展空间，首版没做，但表结构和接口设计上留了字段，后续接月卡年卡不用动主业务逻辑。
3. 数据库设计与关键表结构
3.1 核心表盘点
数据库设计是整个项目的基石，表关系理不顺，后期全是补丁。我最终设计了四张核心表加两张辅助表，覆盖了系统的全部业务数据。
管理员表负责保存系统登录账号和密码。密码存储上没有明文保存，用了MD5加盐的方式，虽然现在的安全标准更推荐BCrypt，但MD5加盐在本地部署和毕业设计场景里足够，而且可以避免引入额外加密依赖。
车位表维护停车场所有车位的位置和状态，关键字段包括车位编号、所属区域、车位类型和当前状态。区域和类型这两个字段属于基础维度数据，已经考虑到商场停车场会有普通车位、充电桩车位和无障碍车位的不同需求。
停车记录表是业务的核心，每辆车入场就生成一条记录，标记状态为在场；出场时更新该记录的出场时间和收费金额，标记状态为已出场。把入场和出场合并成一张表，是因为统计报表需要关联查询同一辆车每次停留的完整时长，分两张表会增加关联复杂度。
收费配置表存的是计费规则参数，包括免费时长、首小时费用、超时小时费用和每日封顶金额。我特别把收费参数从代码里抽出来放进数据库，这样调整收费策略时不需要重新编译部署，直接在后台管理页面改配置就能生效。
3.2 字段类型与约束的关键细节
字段类型选择上有很多容易踩的坑。金额字段我统一用了DECIMAL(10,2)，坚决不用FLOAT或DOUBLE，因为二进制浮点数在累计计算时会产生精度误差，在我后续写计费逻辑时会造成对不上账这种大麻烦。时间字段全部使用DATETIME类型，没有用TIMESTAMP，这样可以避免2038年问题，虽然实际影响不大，但图个安心。
这里有一个设计上的关键细节：停车记录表里有一个status字段，0表示车辆在场，1表示已出场，2表示异常终止。为什么要加异常状态？因为实际运营中存在车辆先入场但没有正常出场就离场的情况，比如场内挪车、设备断电等，有了异常状态，报表统计时就可以识别这些不完整的记录，保证收入数据的准确性。
数据库层面我还加了几个必要的索引：停车记录表上车牌号和状态字段建了组合索引，因为出场查询和报表统计都是基于"状态+时间"条件去定位记录的；入场时间字段单独建索引，方便按时间段聚合统计。索引不是越多越好，覆盖高频查询即可，否则写入性能会下降。
4. 核心功能的落地实现
4.1 车辆入场业务流程的实现
车辆入场在业务上是这样走通的：前端页面输入车牌号后点击入场，后端拿到车牌号先做合法性校验，再查询当前是否存在空闲车位，如果有空闲就分配一个车位，生成一条在场记录，同时把车位状态更新为占用。这三个操作必须保证原子性，任何一个环节失败都不能留下脏数据。
我的Service层实现思路是在方法上添加事务注解，保证"查询空闲车位—插入记录—更新车位状态"打包为一次原子操作。这里有一个很典型的并发问题：两台车同时入场，都查到了同一个空闲车位，如果各自执行插入和更新就会撞车。解决方式不是用分布式锁这种重型武器，而是利用数据库的条件更新特性，执行UPDATE parking_space SET status = 1 WHERE id = ? AND status = 0，如果更新影响行数为0，就说明这个车位被另一个请求先占用了，直接返回车位已满的提示。
入场时间生成上需要注意时区问题，我在服务端统一使用LocalDateTime获取当前时间，避免客户端时区不一致造成的误差。入场记录生成后返回车牌号和车位号给前端展示，这就算完成了入场流程。为了防止用户输入车牌时误带空格，我在Controller参数绑定后统一做了一次去除空白字符的处理，这种小细节不处理，后续按车牌查询时就会留下隐形的脏数据。
4.2 计费逻辑与出场结算的完整实现
出场结算的关键在计费逻辑。我的收费规则设计为：入场前30分钟免费，超时后首小时收费5元，首小时之后的每个自然小时加收2元，24小时内封顶30元。这里要注意的是超时部分不足一小时的按一小时算，这是停车场行业常见的计费方式，代码里要用向上取整处理。
核心计费方法我用一个独立的方法来实现，传入入场时间和出场时间，返回应收金额。实现逻辑分三步：第一步计算总时长并判断是否在免费时段内；第二步如果超过免费时段，先计算首小时费用；第三步计算超出的时间按小时向上取整累加费用，如果超过封顶金额则取封顶值。
开发中容易出问题的点是超时分钟数的计算。如果直接用(总分钟数 - 60) / 60取整，那停车70分钟会被算成只超出10分钟，按0小时收费，这就有漏洞了。正确的做法是(总分钟数 - 60 + 59) / 60，用这个公式实现向上取整。我在写代码时特别加了这个处理，并做了几组边界值测试。
金额结算上，用户选择"确认出场"后，系统会把计费结果展示给用户，确认支付后执行"更新记录为已出场-记录实收金额-释放车位状态"三个操作。这三步同样放在一个事务里，避免出现收了钱但车位没释放的情况。
4.3 停车时长计算与跨天处理
停车时长计算这个环节，表面看就是一个时间减法，实际处理起来要考虑的边界条件不少。入场和出场可能跨越自然日，尤其是商场停车场，很多车是前一天晚上停进来第二天中午开走，时长必须完整计算。
我的实现方式是直接用Duration.between(entryTime, exitTime)获取两个时间点之间的Duration对象，然后转换成分钟数。跨天完全不用额外处理，因为Duration是从时间戳维度计算真实间隔的，不是简单拿"日期减日期"。这一点比很多同学用LocalDate直接相减的做法要稳妥得多，那种写法会把当天停车但没跨天的情况算成0天，计费就全乱了。
跨天场景下还有一个隐含问题：日报统计入场的车辆和在场车辆时，如果一辆车是昨晚入场、今天出场，那它今天出场的费用应该算今天收入还是昨天收入？我的规则是以出场时间归属收入日期，这样对账逻辑最简单，也符合实际场景——钱是出场那一刻收到手里的。
4.4 车位实时状态管理的线程安全问题
车位状态是系统里并发访问最频繁的数据。入场会从空闲改占用，出场从占用改空闲。如果不做控制，在高并发场景下可能出现两个请求同时查到车位空闲、同时分配同一个车位，这在真实运营里就是事故。
我处理的方式结合了两层机制。第一层是乐观锁思想，用一个条件更新语句保证"只有当前状态是空闲时才能改为占用"，通过数据库的行锁天然避免并发覆盖；第二层是重试机制，如果条件更新失败，Service层捕获后重新查询车位分配，最多重试三次。这套机制在500并发压测时没有出现同抢情况。
车位状态展示给管理员的实时性也很重要。后台管理页面每隔5秒轮询一次接口获取所有车位的状态总览，每次轮询只查询车位表，查询量很小，对数据库压力几乎可以忽略。这个方案虽然不算高大上，但足够可靠，而且实现成本极低。我在接口上加了简单的ETag缓存头，车位无变动时响应体不重复下发，进一步降低了带宽开销。
4.5 登录认证与权限控制
登录认证模块看起来简单，但它涉及整个系统的安全边界。管理员登录成功后，我给每个会话签发了一个Token，后续所有请求的Header里带上这个Token，服务端通过拦截器统一校验。
技术实现上我用拦截器注册WebMvcConfigurer接口，在拦截器中检查请求路径是否在白名单内，不在白名单的请求先校验Token存在性和有效性，校验通过后把用户信息写入请求上下文，Service层就能通过上下文拿到当前操作人。
权限控制这里做的是角色级别控制，预留了超级管理员和普通管理员两种角色。超级管理员可以操作所有接口和配置收费规则，普通管理员只能执行入场出场这些日常操作。授权逻辑我用一个简单的注解+拦截器实现，在需要限制的Controller方法上标注解，拦截器通过反射检查注解并比对当前角色。这个小方案的扩展性比细粒度权限框架轻量得多，对当前项目完全够用。
5. 开发过程中的常见问题与排查技巧
5.1 环境与部署层面的踩坑
第一个坑是端口被占用。SpringBoot默认8080端口，开发机上如果已经跑着其他服务，启动直接报Port already in use。排查方式很简单，命令行执行端口占用查询，认出占用进程，之后要么改SpringBoot的端口配置，要么处理掉占用进程。我当时的做法是在application.yml里把端口改成8088，一劳永逸。
第二个坑是数据源配置错误。SpringBoot和数据库之间如果时区没配对，连接会挂上但查询时间会差8个小时。这个错位表现在入场时间记录和实际时间不符，排查花了不少时间。解决方式是在JDBC连接URL上显式指定serverTimezone=Asia/Shanghai，同时在MySQL服务端层面也确认时区配置一致。
第三个坑是打JAR包后运行找不到主类。这个多半是Maven打包插件配置不对，或者主类路径识别异常。确认spring-boot-maven-plugin的版本和SpringBoot版本兼容，然后显式在plugin配置中声明主类全路径，问题就解掉了。部署时我习惯用java -jar方式，脚本里加个--server.port参数，运维灵活度高。
5.2 业务逻辑层面的隐藏隐患
计费边界问题上面提过，这里再说一个更隐蔽的：跨天时长的统计口径。如果只是简单把两个时间戳相减就算时长，在涉及编程时区偏移的服务器上结果会有偏差。我的自查方法是写了一个单元测试，故意传入场时间为昨天的23点50分、出场时间为今天的0点20分，断言时长为30分钟，这类测试极大减少了业务逻辑上的隐性错误。
还有一个MyBatis动态SQL的坑。报表模块需要按传入的时间范围组合条件查询，我一开始直接在<if>标签里判断参数是否为空，结果传入空字符串时SQL走了异常分支，统计结果全部为0。排查后加上对所有日期参数的非空和格式双重校验，才能保证动态SQL按预期拼接。经验就是，动态SQL越灵活越要谨慎，每个分支组合都要覆盖测试。
5.3 前后端联调与兼容性问题
前后端联调阶段最常碰到的是日期格式问题。后端实体类用LocalDateTime，默认序列化成"2024-01-01T12:00:00"这种带字母的格式，前端展示和表单回填都对不上。我用一个全局的Jackson配置统一了日期序列化格式，在配置类里明确输出yyyy-MM-dd HH:mm:ss，同时在前端拿到时间字符串后做一次解析再展示，两侧口径就一致了。
跨域问题也在联调期冒出来。前端调试页面跑在某个开发端口，后端接口在另一个端口，浏览器默认拦截跨域请求。我在后端配置了全局CORS策略，允许指定来源跨域，并且放行自定义请求头。这个方法比前端代理配置更直接，花了两分钟配置一劳永逸。需要注意生产环境一定要把允许的来源收紧成具体域名，而不是用*无条件放行，否则有安全风险。
6. 我的实操经验总结与扩展建议
整个项目做下来，最深的感受是业务理解先行、代码实现靠后。我一开始直接扑进代码，入场出场录数据写得很顺手，但到汇总报表环节才发现统计口径不一致，入场次数和出场次数对不上数。回头重新梳理业务、调整表结构，白白返工了两天。现在做项目我都先画清楚业务流程图和状态流转图，确认无误再动手，这个习惯让后续开发效率提升非常明显。
收费金额计算坚持用BigDecimal，这是我在实际开发中反复确认的底线。用浮点数计算金额，小数据量测试看不出来，一旦累计到上万条停车记录，差额就出来了，到时候对账都是噩梦。BigDecimal的构造方式也有讲究，直接用字符串构造避免double转BigDecimal的精度损失。
文档和调试过程记录这块，我建议养成边开发边记录的习惯。调试文档不止是给别人看的，更是给自己留的排查手册。我在文档里详细记录了每个接口的请求参数和返回示例，还把调试时遇到的环境变量、配置文件差异写进去，整个过程后期碰到相似Bug直接翻文档就能定位，省了大量重复排查时间。
如果后续要把系统往智能化方向扩展，有一些很自然的演进路径：引入车牌识别摄像头，入场出场完全免停车操作；接入在线支付，出场时自动扣款推送账单；增加会员系统，月卡次卡和积分抵扣都基于现有收费配置扩展；部署到大屏设备展示车位地图和实时引导信息。这些扩展方向的底层数据模型都已经在当前表结构中预留了扩展空间，不会推倒重来。
我对这个项目的评价是：它并不复杂，但足够完整。从登录鉴权到业务闭环再到统计报表，每个环节都有值得打磨的细节，非常适合用来完整走一遍Java Web项目的开发流程。做这类系统，最忌讳的就是只满足于"把功能跑通"，多想想边界条件、并发场景、数据一致性，做出来的东西才敢说真正可用。