2. 前端与接口设计——Vue生态下的信息架构与交互策略3. 从Centos部署到跨域问题一趟完整的踩坑实录4. 系统性能与安全加固——并发冲突、防刷与数据一致性5. 复盘智能停车系统的价值与扩展方向6. 前端交付后的真实反馈从“能用”到“好用”7. 独立开发者视角这套系统的商业价值与运维思考8. 可复用模块提炼从停车项目到任何SSMVue项目1. 为什么选择SSMVue传统项目里的务实选型最初接到这个项目时我的第一反应是智能停车系统不是应该用微服务、容器编排那一套才够“智能”吗但真正分析了需求之后我的结论是——SSMSpring SpringMVC MyBatis搭配Vue反而是这类业务系统性价比最高的组合。先说说这套系统解决什么问题。智能停车系统的核心不是停车本身而是车位资源的动态分配与计费管理。一个典型的场景是车主进入停车场系统识别车牌引导到空闲车位车主办完事出场系统计算时长自动扣费或抬杆放行。这背后涉及车牌识别、车位状态实时更新、订单生成、会员余额变动、高峰期并发抢位等多重业务逻辑。对于这种强事务、强数据结构约束、并发量可控的业务场景SSM的经典MVC分层和MyBatis的细粒度SQL控制反而是最可控的选择。我的技术选型思路很简单层级选型理由后端基础框架Spring SpringMVC依赖注入与事务管理成熟稳定资料多、排查方便持久层MyBatisSQL可控性极强适合停车场这种多表关联复杂的计费查询前端Vue 2 Element-UI组件化开发效率高后台管理界面快速成型数据库MySQL 5.7 InnoDB支持行级锁适合订单并发场景车牌识别开源OCR接口HTTP调用降低硬件成本普通摄像头即可完成识别注意一个关键选择我这里刻意没有用MyBatis-Plus。虽然是智力劳动但在计费、出入场这类高频写操作上我习惯自己掌控SQL语句自带的分页和条件构造器在复杂查询中反而会变成黑盒。从我的实操经验看很多人在这个项目上栽跟头不是因为框架不够先进而是因为根基没打牢就开始堆功能。SSM虽然“老”但它逼迫你理清Controller层该干什么、Service层该干什么、Mapper层该干什么这种清晰的边界感正是业务系统最需要的。这套系统的定位也明确不是给大型商业停车集团做的云端SaaS平台而是给一个单停车场几百个车位规模、或一个小型物业公司自营管理的系统。所以不需要分布式事务、不需要消息队列一台4核8G的云服务器完全可以扛住单场高峰时段的全部请求。如果你正在纠结毕业设计或自研项目选什么技术栈我的建议是先评估系统日均请求量和事务复杂度再决定要不要上微服务。智能停车系统这种业务SSMVue足够扎实而且面试官/验收老师看到你能把事务边界、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 核心表结构一览表名核心字段作用memberid, phone, plate_number, balance, member_type, version会员与账户parking_recordid, plate_number, entry_time, exit_time, entry_image, exit_image, status每一次出入场的完整记录billing_orderid, record_id, total_amount, discount_amount, payable_amount, status一条停车记录对应的结算单billing_flowid, order_id, type, amount, create_time每一笔资金的流向明细充值/扣款/退款parking_spaceid, area_no, space_no, status, sensor_status车位基础信息与状态space_status_logid, 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因为停车场这种低频场景用户不愿下载APPH5扫码即用才是合理的交互路径。4.1 端侧功能和页面结构端页面核心能力车主H5首页、缴费、绑定车牌、充值、发票、停车记录查费、缴费、绑定车辆、充值免排队后台管理实时大屏、车位管理、订单管理、会员管理、计费规则管理、报表运营监控与业务管理岗亭端入场/出场操作台人工干预、异常放行、收费确认Vue Router做的路由守卫一定要用上后台管理页全部拦截未登录用户路由跳转前先判断Token是否存在不存在则重定向到登录页。这个做过一遍就知道如果不做全局拦截开发时自己直接改URL跳过登录上线之后用户也能跳过这是安全隐患。4.2 跨域问题与代理配置本地开发时前端axios请求后端接口必然遇到跨域问题。我在两个环境分别做了处理开发环境Vue CLI的devServer配置代理所有/api前缀请求转发到http://localhost:8080绕开跨域。生产环境后端反向代理统一入口前端请求同域路径不存在跨域。如果前后端分离部署在不同域名则后端必须配置CORS跨域过滤器但不能用allowCredentialstrue加*这种通配写法这是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 rootyour-server:/opt/tomcat/webapps/ ssh rootyour-server systemctl restart tomcat这里有一个非常反直觉的坑很多人以为项目增大之后部署慢是因为代码编译实际上大部分时间耗在静态资源上。Vue构建出来的JS文件动辄几兆而Tomcat默认的HTTP传输没有启用压缩传到服务器上再加载到浏览器首屏时间长得离谱。后来我配置了Tomcat的压缩传输Connector port8080 protocolHTTP/1.1 compressionon compressionMinSize1024 compressibleMimeTypetext/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.urljdbc:mysql://localhost:3306/parking?useUnicodetruecharacterEncodingutf8useSSLfalseserverTimezoneAsia/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-agelong并加上文件名hashVue 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. 复盘智能停车系统的价值与扩展方向项目交付之后我沉淀了一份完整的复盘文档。核心观点是判断一个系统做得好不好的标准不是技术新不新而是它在真实环境中扛不扛得住运营的折腾。这套SSMVue的智能停车系统在单停车场日流量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. 可复用模块提炼从停车项目到任何SSMVue项目写到最后我想分享一个个人心得SSMVue这套组合虽然“传统”但它沉淀下来的工程模式放在任何中小型业务系统里都是通用的。这个项目做完后我整理了四个可复用模块下面按价值从高到低列一下。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和配置我都写了注释说明“为什么这么写”。三个月后回看代码你会感谢当时的自己。
