企业官网建设流程全解析

去年前段时间，我帮一个朋友所在的园区做模拟项目X，需求正好是"公园游玩场地预约管理 + 设施维护 + 游客统计"这一套组合。做之前我以为就是个普通的CRUD，后来才发现预约冲突、维护工单流转、统计口径这些东西，每一块都有坑。今天不聊空话，直接把整个系统的业务拆解、表结构设计、核心接口逻辑和踩坑经验一次性讲透，适合正在做类似课设、毕设或者刚接手Spring Boot项目的开发者参考。

1. 从需求到系统边界：这套系统到底在管什么

拿到"公园游玩场地预约管理系统公园设施维护游客统计"这个标题时，第一步不是急着建项目，而是要把业务边界画清楚。很多人在起步阶段就栽了跟头——以为预约、维护、统计是三个独立模块，结果数据库表设计各干各的，后面写统计SQL时发现数据根本对不上。

1.1 三块业务的内在关联

先说清楚这三者的关系：游客预约场地是核心业务，产生订单数据；设施维护保证场地可用性，维护中的场地不能开放预约；游客统计则反过来依赖预约和入园记录，分析公园运营情况。看到这里你就明白了，这三块不是并列关系，而是"预约是主流程、维护是状态约束、统计是上层分析"的紧凑链路。

举个例子，一个篮球场如果处在"维修中"状态，用户在预约时段选择时就不应该看到这个场地，已经预约的用户也需要收到通知。而在统计端，这个场地在维修期间不应该产生新的订单量数据。这些跨模块约束，只有在一开始就把字段设计统一，才能在后端代码里干净地落地。

1.2 技术选型与项目基础结构

技术栈用的是Java Spring Boot 2.x + MyBatis Plus + MySQL + Redis，比较常规，易于部署。

选型背后的理由：

• Spring Boot负责整体业务分层，Controller管理请求入口，Service层承载预约、维护、统计的核心业务逻辑，Mapper层对接数据库。
• MyBatis Plus简化单表CRUD，让团队不用写大量重复XML，但对需要控制SQL执行计划的复杂统计自己写XML。
• Redis缓存场地状态和热门时段，提升并发下的读写性能。
• MySQL承担持久化，五张核心业务表加上三张配置表，量级不大，但索引设计要提前想清楚。

实际开发的包结构大致如下：

com.park.demo ├── controller ├── service ├── mapper ├── entity ├── dto ├── config └── common

不需要导太多第三方依赖，JWT做登录态，Swagger做接口调试，定时任务用Spring自带的@Scheduled就足够，避免项目一开始就引入复杂框架导致成本失控。

1.3 核心表结构与字段设计的取舍

数据表不需要贪多，核心就是这几张：

• 场地表（venue），存场地名称、位置、容纳人数、开放时段、状态。
• 预约订单表（booking_order），存用户、场地、日期、开始时间、结束时间、状态、支付金额。
• 设施维护表（maintenance），存维护类型、上报人、处理人、状态、维护开始结束时间。
• 游客统计表（visitor_statistics），存日期、场地id、预约量、实到量、最大承载量。
• 用户表（sys_user），区分管理员、普通游客。

其中最容易出错的是预约订单表的时间字段设计。我的建议是：不要只存"日期"和"时段"两个字符串，后端要在接口层做时间戳校验。例如用户下单时提交的时段是"10:00-12:00"，系统在写入数据库时，要能计算出这一个时段的实际开始和结束时间戳，这样才能应对复杂的冲突检测需求。

一个细节是MySQL里的datetime类型本身不存储时区，如果你的服务器和数据库时区配置不一致，写进去的数据在统计时会出现"原地上午十点，查出来变成下午三点"的情况。所以在JDBC连接串里一定要设置serverTimezone=Asia/Shanghai。

2. 场地预约模块：冲突检测与会话级重复下单处理

预约是整个系统里最需要严谨处理的模块。如果预约逻辑写不好，一场球赛会有两个队伍同时订到同一块场地，或者用户疯狂点提交按钮生成几十条重复订单。这块内容，值得花大力气拆解。

2.1 可预约时段与冲突检测方案

我们需要先定义规则：公园里每个场地以半小时为最小预约单元，比如篮球场上午8点到晚上22点，一共28个可预约时段。查询可用场地时，前端传日期和起始时间，后端拿到时间范围后，去查有没有已占用的订单记录。

核心冲突检测SQL用MyBatis Plus构造即可，条件大致是这样：

LambdaQueryWrapper<BookingOrder> wrapper = new LambdaQueryWrapper<>(); wrapper.eq(BookingOrder::getVenueId, venueId); wrapper.eq(BookingOrder::getBookingDate, bookingDate); wrapper.eq(BookingOrder::getStatus, "已支付"); wrapper.apply("(start_time < {1} AND end_time > {0})", startTime, endTime);

这里的关键在于区间重叠判断：新预约的"开始时间"要小于已有订单的"结束时间"，且新预约的"结束时间"要大于已有订单的"开始时间"，两个条件同时满足才说明时间重叠。

真实开发中还有一个问题：用户选择的开始时间和场地模板里的开放时间不一致。我的处理是在前端做一次下拉选择，直接让用户选模板中定义好的时段，后端只做校验，不做模糊匹配，从源头减少非法数据。

2.2 重复下单与Redis分布式锁

即使做了冲突检测，仍然有可能出现同一时刻两人抢同一场地的极端情况。原因很简单：A请求检测时没有记录，正准备插入；B请求同时检测，也没有记录，也准备插入。这时候数据库的行锁或表锁能兜底，但用户体验上可能出现等了半天插入失败。

我在项目里直接在"进行中订单"的状态上加了Redis锁。当用户提交预约时，先尝试获取锁：

boolean acquired = redisTemplate.opsForValue() .setIfAbsent("lock:booking:" + venueId + ":" + bookingTimeRange, "1", 10, TimeUnit.SECONDS);

获取成功才允许继续查询和插入订单，获取失败则直接返回给用户"该时段正在被抢占，请稍后再试"。

锁的超时时间设为了10秒，这个值不需要太长，因为订单插入操作本身通常在毫秒级完成。太大会造成无效阻塞，太小则容易在业务还没来得及释放锁时就自动过期。

更为重要的是，支付状态的确认。我这里简化了流程：用户提交后订单状态是"待支付"，支付模拟接口回调成功后改为"已支付"。释放锁的时机是状态变更结束后，而不仅仅是插入后。

2.3 超过预约时间未到的处理机制

高频踩坑点在"用户约了场地但没来"。预约系统如果完全不处理爽约请求，会导致场地白白空着。处理方式是引入"可取消时间规则"：预约开始前2小时内，用户可以自助取消，平台退回费用；少于2小时内的取消操作，不允许执行，视为爽约。

代码实现上，取消接口在传入订单号后，要先判断当前时间是否小于"预约开始时间减2小时"。如果满足，订单状态改成"已取消"，释放场地的占用量。否则返回错误码提示"已过最晚取消时间"。

在定时任务上，我另外写了一个Job，每天凌晨把状态为"待支付"且创建时间超过30分钟的订单自动置为"已关闭"。这个逻辑必须在系统刚上线时就要想好，否则以后维护订单数据时会有大量历史脏数据。

3. 设施维护模块：工单流转与场地联动解耦

设施维护模块看起来只是简单记录维修记录，实际上和预约模块有着紧密联动。一开始我把维护的状态写在场地表里，导致的问题就是：场地表需要频繁修改，且维护历史无法追溯。后来换了设计思路，把维护记录独立成表，场地状态通过"视图"或"条件判断"来关联，才理顺了关系。

3.1 报修入口与工单状态设计

公园游客或管理人员发现设施损坏，在App端或后台提交报修。工单领域模型包含报修类型、上报人、场地、损坏照片、描述、状态、处理人、维护开始时间、结束时间、维护结论。

工单的状态流转我用了一个常见状态机：待审核 -> 已派单 -> 维护中 -> 已完成；中间还包含"已驳回"。关键点是每一次状态变更都要求记录时间点和操作人，防止后续扯皮。比如伪造数据时看不出这个场地到底什么时候修的，有了操作时间字段，才能对得上。

实际执行时，状态流转的合法性校验很重要。我见过有的系统在Controller里直接setStatus，导致用户可以通过接口把"待审核"直接改成"维护中"，绕过派单流程。正确做法是放在Service层做状态迁移校验，只允许符合规则的状态更新操作。

3.2 维护与预约的滚动联动

公园某个场地进入"维护中"状态后，该场地应该立刻停止接收新预约。这里我采用的是"软联动"方案：预约订单查询时，不删除维护记录，只把场地表的状态临时置为"不可预约"。

这样处理的好处是，维护完成后场地自动恢复可用，如果中间有预约冲突可以直接追溯维护记录。另外，已经预约并支付了费用的订单，如果撞上了紧急维修时间段，用户端需要收到变化通知。我在系统里给这类订单加了一个"平台取消"状态，并通过WebSocket推送告知用户，退款操作则走另一个补偿接口。

3.3 定期巡检计划调度

公园设施不能等着坏才修。我在系统中加入了"设施巡检计划"的概念，范围可以按月生成：每个月初为所有场地生成一条待巡检记录，管理人员按计划逐项填写设施状态，如"完好、需保养、需维修、损坏停用"。

这个功能不复杂，但很能体现系统设计是否完整。它对游客统计模块也很重要——当一个场地处于"损坏停用"状态时，统计模块要能看到该场地的停用天数，计算出"实际可用率"这个运营指标。我在代码中通过维护记录的时长自动计算该指标，减少了人工报表统计的工作量。

4. 游客统计模块：预约数据到可视化看板的最后一公里

很多项目在统计模块上都栽在同一个地方："统计口径"不一致。运营人员说的"今日游客量"，和开发人员写的SQL算出来的"今日预约量"，完全是两个概念。这块做之前，建议先和业务方把名词定义统一。

4.1 统计指标的维度与口径定义

在我的设计里，核心指标分了几个层级：

• 预约量：当天所有场地成功支付订单的总数。
• 到场量：用户入园时生成一条"入园记录"数，独立于预约订单。
• 流失率：预约但未到场的订单数除以预约总数。
• 场地使用率：场地被占用的总时长除以场地可预约总时长。

针对维度，按天统计可看趋势，按场地统计可对比不同场地热度，按时段统计可看高峰时段。统计模块的数据来源于预约订单表中的状态确认时间，而非创建时间。为什么要这样做？因为用户可能在晚上预约第二天下午的时段，如果按创建时间统计会把订单算到前一天，导致数据漂移，这是很常见的数据质量问题。

4.2 基于SQL的聚合查询优化

写统计接口时，最高效的方式是让MySQL直接聚合，而不是Java内存中做运算。比如按日统计到场量：

SELECT date(visit_time) as visit_date, count(*) FROM visit_record WHERE visit_time >= #{startTime} AND visit_time < #{endTime} GROUP BY date(visit_time)

注意一个性能细节：如果visit_time列没有索引，这张表在写入量大后会变得非常慢。给visit_time和venue_id建组合索引后，整个查询从全表扫描降到索引扫描。

对于每天凌晨的汇总数据，我更推荐定时任务把明细表预聚合到visitor_statistics表，报表查询直接读预聚合结果，避免每次都跑大查询。我设计里每天晚上凌晨1点跑一次汇总，把前一天的预约量和到场量算好写入统计表。这样线上看板查询时毫秒级返回。

4.3 前端看板展示与导出

后端提供统一的数据接口，返回按日期排列的统计数组，前端用ECharts绘制折线图和饼图。项目里做的是"今日看板"和"月度趋势看板"。今日看板显示当日预约量、在场人数、场地占用率；月度趋势分别显示每日到场量和每日预约量的折线对比。

考虑到公园管理方经常需要汇报工作，统计模块还需要支持导出Excel。我采用的是后端POI生成文件流，前端用window.open直接下载。文件内容包含按照场地分组的预约明细，方便运营人员二次处理。

5. 工程交付时容易忽略的配置与上线准备

很多项目卡在"代码写得差不多但跑不起来"这个阶段。这些坑，百分之八十都不是业务逻辑问题，而是配置和环境问题。

5.1 MyBatis Plus扫描路径与分页插件的坑

MyBatis Plus有一个非常典型的配置错误：@MapperScan注解扫描的包路径和Mapper文件里定义的包路径不一致，导致明明代码看起来没问题，启动却报找不到Bean。我的项目里统一在启动类上加了@MapperScan，且明确指向com.park.demo.mapper，避免泛扫整个包。

分页插件也是个重点。如果你用了MyBatis Plus自带的Page对象，却不加MybatisPlusInterceptor的配置，分页请求会查出来全表数据，前端表现就是明明一页十条却有几十条数据。配置如下：

@Bean public MybatisPlusInterceptor mybatisPlusInterceptor() { MybatisPlusInterceptor interceptor = new MybatisPlusInterceptor(); interceptor.addInnerInterceptor(new PaginationInnerInterceptor(DbType.MYSQL)); return interceptor; }

这个配置没有启用，我在项目里调试了将近一个下午才发现控制台输出的是全量SQL，教训相当深刻。

5.2 定时任务与系统时区

统计模块的定时汇总任务依赖时区，如果服务器是UTC时间，MySQL存的是本地时间，那么定时任务在启动时计算"昨天"的边界就会出现偏低偏高的偏差。统一方案是在JDBC连接参数里加serverTimezone=Asia/Shanghai，并在Spring Boot配置里写明spring.jackson.time-zone=GMT+8。

另一个容易被忽视的是定时任务的重复执行。单机部署时@Scheduled默认只执行一次，但如果未来系统扩展到多节点部署，同一时刻所有节点都会触发汇总任务，导致统计翻倍。建议在任务入口加一个分布式锁或者通过数据库任务表状态位控制，只有抢到锁的节点才允许执行。

5.3 接口安全与鉴权细化

预约、取消、支付等写操作接口，必须有登录态校验。我用JWT做了简单的Token鉴权，拦截器里放行登录和场地查询等只读接口，其他预约、维护、统计导出接口一律校验Token。角色和权限控制用Spring Security也能实现，但如果项目没有太复杂的权限矩阵，轻量拦截器比引入安全框架更快速可控。

有一点我建议单独处理：用户取消预约和平台强制取消这两个接口，返回给前端的信息必须不同。用户主动取消需要在业务上释放锁定的时段；平台强制取消则会触发退款事务。如果都走一个接口，很容易导致用户支付金额不一致的bug。

6. 这套系统的运维视角与扩展空间

系统上线之后，我最大的感受是：预约系统真正费劲的不是开发，而是后期的数据治理和边缘情况应对。这里分享一些运维视角的观察，给准备做类似项目的同学一个参考。

预约模块要防"黄牛占位"，比如同一用户批量注册账号抢热门时段。我虽然没有做特别严格的实名认证，但在订单表中增加了同一手机号当天最多预约两次的校验规则，靠业务规则简单缓解这个问题。

设施维护模块的价值随着系统运行时间增长而增加。当维护记录积累到一个季度厚度后，管理者能清楚地看到哪个场地的故障率最高、哪个设施的维修周期最短、哪类报修最容易反复出现。这就是数据驱动运维决策的雏形，别因为它是后台功能就忽视设计。

至于游客统计模块，远期可以考虑引入手持闸机数据接入，把预约数据、实到数据、安防闸机数据合成一个数据中台。一旦能把"预约量"和"真实到场量"打通，公园的运营调度、人员排班、设施投放这些更深层的决策都有了数据支撑。

从工程上来讲，Spring Boot项目做到这个程度，已经能把一个"管理系统类"的项目撑得相当完整：有核心业务事务、有分布式锁、有定时任务、有数据统计、有权限校验。如果再往上加微服务和消息队列，反而容易把复杂度带到和学习阶段不匹配的高度。先把单机架构下的事务边界、时间边界、状态边界理干净，再考虑分布式，这条路对大多数开发者来说性价比最高。

最后补一条个人经验：做这类系统，别一上来就写代码。花两小时把"用户-场地-订单-维护-统计"这五张表的字段和状态流转捋清楚，比多写一千行业务代码有用得多。编码层面的Bug好查，设计层面的漏洞往往会拖到联调阶段才暴露，那时候改动的成本已经翻了几倍。希望这篇拆解对你有实际帮助。