做篮球馆会员管理系统这个项目，前后折腾了不少时间，踩过的坑也不少。最近整理代码的时候把整个思路重新梳理了一遍，里面有不少细节是当时翻资料、看文档、反复调试才搞明白的，现在写出来分享给大家。这套系统不算复杂，但足够真实，是一个实实在在落地运行过的项目，涉及会员信息管理、场地预订、消费结算、统计报表这些核心业务，技术栈是 Spring Boot 全家桶。
如果你正在做类似的管理系统，或者刚入行想找一个练手项目，又或者接手了场馆类业务系统不知道怎么拆分模块，这篇文章应该能帮到你。我会把设计思路、表结构、核心接口、踩坑经验都摊开来讲，不是教科书式的罗列，而是从实际运营角度出发，讲清楚每一个设计决定背后的原因。
以下内容基于我个人在项目中的实际开发经验总结，涉及的代码片段为简化后的示例，核心逻辑保持一致。
1. 项目背景与业务需求拆解
1.1 篮球馆日常运营的真实痛点
开始动手之前，我先在球馆待了两天，观察前台工作人员平时是怎么干活的。一个中小型篮球馆，日常业务其实非常琐碎：散客来打球，要登记手机号、算临时入场费用；老会员来订场，要在纸质的排班表上找空档，再用本子记录订场信息；会员卡充值、续费、余额查询这些操作，基本依赖微信转账记录加手工记账本。
我印象最深的是结账环节，晚上十点球场关门，前台开始对账，手机里的付款记录一条条翻，本子上的订场记录一条条比，碰到会员用余额付款的，还得翻会员档案确认扣了多少钱。整个过程两个多小时，经常对不上账，最后只能一笔笔人工核对。
从这些日常细节能提炼出几类核心需求：第一，会员信息要能统一管理，开卡、续费、余额变动、到期时间都得有据可查；第二，场地预订不能靠纸和笔，系统要能展示每个场地的占用情况，冲突了得提示；第三，消费结算要自动完成，余额扣款、订单记录、流水明细要形成闭环；第四，经营者要能看到营收、客流、会员增长这些经营数据，辅助决策。
1.2 系统能力边界与核心模块划分
理解了需求之后，系统边界就很清晰了。这个项目不需要做电商那种复杂的商品体系，也不需要做库存管理，核心就是围绕“会员”和“场地”这两条主线，把门店运营的关键环节串起来。
整个系统我划分成这几个模块：会员管理、场地管理、订场管理、消费结算、统计报表、系统管理。会员管理负责开卡、等级维护、续费、到期提醒；场地管理维护场地信息和价格策略，比如全场、半场、工作日价格和周末价格；订场管理处理场地预订、取消、改期；消费结算统一处理余额扣款、流水记录、退款；统计报表从订单和流水数据中聚合出每日营收、会员消费排行、场地利用率。
这里要特别说明一下为什么不把商品售卖、私教课约课这些功能塞进来。当时运营方也问过能不能顺便卖水、卖球衣，我明确拒绝了，一个系统一旦功能过多，开发周期和数据复杂度都会指数级上升。第一版最重要的是把会员信息和场地预订跑通，其他功能等稳定运行之后作为扩展模块再加不迟。
1.3 用户画像与权限设计
系统的使用者分为三种角色：前台收银、店长、系统管理员。前台负责日常开卡、收款、订场操作；店长关注经营数据，需要查看报表；管理员负责系统配置，比如场地价格设置、会员等级规则、账号分配。
权限设计这里有一个容易踩的坑，一开始我把权限粒度控制到按钮级别，结果反而给前端开发带来了很大的工作量。后来调整为角色加页面级别的粗粒度控制，菜单根据角色动态渲染，接口用拦截器校验角色标识，足够满足使用需求。权限做的太细，在业务人员只有十几个人的小场馆里就是过度设计。
2. 技术选型与项目架构设计
2.1 为什么选 Spring Boot 而不是其他框架
项目语言选型的时候其实考虑过几个方案，最终选定 Spring Boot，核心原因有三个。
第一是团队技术栈适配。后续维护这套系统的同事大多是 Java 出身，Spring Boot 是 JVM 生态中最主流的快速开发框架，资料多、问题排查方案成熟、招人也好招。如果选 Python 的 Django 或者 Flask，功能虽然也能实现，但后期的维护沟通成本会高不少。
第二是快速交付能力。Spring Boot 的自动配置特性省掉了一大堆 XML 配置工作，内嵌的 Web 容器让项目可以打包成 jar 直接跑起来，不需要单独部署 Tomcat。对于这种业务逻辑不算复杂的场馆管理系统，能显著缩短从代码到上线的周期。实际开发中，从搭建骨架到核心接口调通，我大概用了一周多的时间。
第三是生态配套完善。Spring Boot 和 MyBatis、Redis、Spring Security 这些组件都有成熟的整合方案，社区里能找到各种踩坑案例。开发过程中遇到问题，基本搜索一下就有现成的答案。
大小写说明：项目名称为 Spring Boot，提到这个名称时注意保持规范写法。
2.2 项目基础骨架搭建
技术选型定了之后，项目的基础架构用 Spring Initializr 快速生成，包含 Web、Validation、MyBatis-Plus 等依赖。我使用的是 Spring Boot 2.7.x 版本，这个版本既稳定又兼容后续升级，JDK 用的 1.8，这是很多企业还在用的 LTS 版本。
项目的包结构采用经典的分层设计：
com.example.basketball ├── controller # 接口层，接收请求和参数校验 ├── service # 业务层，核心业务逻辑 ├── mapper # 数据访问层，MyBatis-Plus 接口 ├── entity # 数据库实体映射 ├── dto # 数据传输对象，承载接口入参和返回 ├── vo # 视图对象，返回给前端的数据封装 ├── config # 配置类，如 MyBatis-Plus 分页插件、跨域配置 └── common # 通用类，统一返回结果、异常处理、工具类分层的价值在项目维护期才能体现出来。有一次需要调整会员到期时间的计算规则，我只需要改 service 层的逻辑，controller 和 mapper 完全不用动。如果当初图省事把业务代码堆在 controller 里，改起来就是牵一发而动全身。
2.3 核心依赖与工具组件
除了 Spring Boot 本身，我选了几个关键的配套组件：
MyBatis-Plus：数据访问层的增强工具，CRUD 操作基本不用手写 SQL，分页查会员列表只要一行代码。当时对比过 JPA 和 MyBatis-Plus，最终选择后者是因为它的 SQL 可控性更好，复杂的多表关联查询可以写 XML，不像 JPA 那样遇到复杂查询就比较别扭。
MySQL 8.0：数据存储的主力，这套系统的数据量级，单库单表完全够用，不需要上复杂的集群架构。
Redis：主要用来做缓存和分布式锁。会员信息、场地价格这类读多写少的数据缓存到 Redis 里，能显著降低数据库压力。订场地时的并发冲突问题也要靠 Redis 的分布式锁来保证。
Lombok：消除实体类里繁琐的 getter/setter 代码，让代码更简洁。
Hutool：工具类库，很多小功能比如生成随机数、日期计算，直接用它的封装方法，省了不少事。
配套组件选型上有一个原则：能不引入就不引入，避免过度设计。比如消息队列、分布式事务这些中间件，这套系统远远用不上，硬塞进来只会增加运维成本，没有任何实际收益。
3. 数据库设计与表关系梳理
3.1 核心数据实体
数据库设计是这套系统的地基，表结构没设计好，后面业务逻辑写起来会非常别扭。我梳理出来的核心实体有这些：会员、会员卡类型、场内场地、订场订单、消费流水。
会员和会员卡类型是一对多的关系，一个会员可能办过多张卡，比如先办了一张次卡，后来又升级成了年卡；订场订单和会员是多对一的关系，一个会员可以订多个场次；消费流水和订场订单是一对一的关系，每次扣费都会生成一条流水记录，退款时再生成一条对应的冲正记录。
这里说一个很重要的设计经验：会员信息、会员卡和订单信息不要塞在同一个表里。第一版图省事，我把会员卡信息直接放在会员表里，导致后来升级卡类型时，需要改会员表结构，还和历史数据兼容问题纠缠了很久。把会员基本信息、卡信息和订单信息拆开，后续扩展会灵活很多。
3.2 会员卡与会员信息表设计
会员表的字段设计上，除了基本个人信息，有几个字段是业务核心：
CREATE TABLE `member` ( `id` bigint(20) NOT NULL AUTO_INCREMENT, `card_no` varchar(32) NOT NULL COMMENT '会员卡号', `name` varchar(50) NOT NULL COMMENT '会员姓名', `phone` varchar(20) NOT NULL COMMENT '手机号', `card_type_id` bigint(20) NOT NULL COMMENT '会员卡类型ID', `balance` decimal(10,2) NOT NULL DEFAULT '0.00' COMMENT '账户余额', `total_recharge` decimal(10,2) NOT NULL DEFAULT '0.00' COMMENT '累计充值金额', `points` int(11) NOT NULL DEFAULT '0' COMMENT '积分', `start_time` datetime DEFAULT NULL COMMENT '开卡时间', `expire_time` datetime DEFAULT NULL COMMENT '到期时间', `status` tinyint(4) NOT NULL DEFAULT '1' COMMENT '状态：1正常 2冻结 3过期', `remark` varchar(255) DEFAULT NULL COMMENT '备注', `create_time` datetime NOT NULL COMMENT '创建时间', `update_time` datetime NOT NULL COMMENT '更新时间', PRIMARY KEY (`id`), UNIQUE KEY `uk_card_no` (`card_no`), KEY `idx_member_phone` (`phone`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='会员信息表';重点说一下expire_time这个字段。会员卡类型分次卡和时长卡，次卡用剩余次数控制，时长卡用到期时间控制。为了让逻辑统一，我设置了一张会员卡同时拥有“剩余次数”和“到期时间”两个维度的字段，不同类型的卡根据卡类型配置来决定校验哪个维度。
balance字段用decimal(10,2)，金额计算一定要用这个类型，不能用 float 或 double，否则会出现 0.1 加 0.2 不等于 0.3 这种精度问题。会员余额设计上只存当前剩余金额，不存冻结金额，因为业务场景里扣费是立即执行的，没有预授权这类流程，存冻结金额会增加不必要的复杂度。
3.3 订场订单表与消费流水表设计
订场订单表记录了每一次场地预订行为：
CREATE TABLE `booking_order` ( `id` bigint(20) NOT NULL AUTO_INCREMENT, `order_no` varchar(64) NOT NULL COMMENT '订单编号', `member_id` bigint(20) NOT NULL COMMENT '会员ID', `venue_id` bigint(20) NOT NULL COMMENT '场地ID', `booking_date` date NOT NULL COMMENT '预订日期', `start_time` varchar(20) NOT NULL COMMENT '开始时间 HH:mm', `end_time` varchar(20) NOT NULL COMMENT '结束时间 HH:mm', `payment_type` tinyint(4) NOT NULL COMMENT '支付方式：1余额 2微信 3现金', `amount` decimal(10,2) NOT NULL COMMENT '订单金额', `status` tinyint(4) NOT NULL COMMENT '状态：1已预订 2已完成 3已取消 4已退款', `create_time` datetime NOT NULL, PRIMARY KEY (`id`), UNIQUE KEY `uk_order_no` (`order_no`), KEY `idx_booking_venue_date` (`venue_id`, `booking_date`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='订场订单表';消费流水表的设计思想和订单表稍微不同，它更像是资金变动的审计日志，记录每一次余额变动的来龙去脉：
CREATE TABLE `consume_record` ( `id` bigint(20) NOT NULL AUTO_INCREMENT, `record_no` varchar(64) NOT NULL COMMENT '流水编号', `member_id` bigint(20) NOT NULL COMMENT '会员ID', `order_id` bigint(20) DEFAULT NULL COMMENT '关联订单ID', `change_type` tinyint(4) NOT NULL COMMENT '变动类型：1消费 2充值 3退款 4赠送', `change_amount` decimal(10,2) NOT NULL COMMENT '变动金额，正负表示增加或减少', `balance_before` decimal(10,2) NOT NULL COMMENT '变动前余额', `balance_after` decimal(10,2) NOT NULL COMMENT '变动后余额', `create_time` datetime NOT NULL, PRIMARY KEY (`id`), KEY `idx_record_member` (`member_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='消费流水表';流水表里的balance_before和balance_after字段，是我在开发中特别保留的。有些系统设计流水表只记录变动金额，不记录变动前后余额，这样遇到“这个会员的余额为什么对不上账”的问题时，根本无从排查。保留前后余额字段，每一笔资金变动都能从头到尾串起来，这是夜班对账时最有价值的设计。
3.4 索引设计与唯一约束
索引设计上，我遵循一个原则：小表全扫描无所谓，大表必须走索引。这套系统里会员表是核心大表，所以手机号、卡号都建了索引；订场订单表按场地和日期建了联合索引，查询某天某个场地是否被预订时效率很高。
唯一约束上，卡号和订单编号都设置了唯一索引。卡号是人工可读的编号，容易出现重复，数据库层面的唯一约束就是最后一道防线。订单编号也有同样的考量，通过唯一索引确保不会生成重复的单号。
会员卡号的生成规则是这样的：前缀DOOR加年月日加三位随机数，比如DOOR20250108001。订单编号用时间戳加上随机数。这种规则生成的编号可读性强，前台在系统里看到编号能直接判断出办理日期，方便沟通。
4. 会员管理模块的核心实现
4.1 开卡流程与身份校验逻辑
会员开卡是系统里最常用的功能，前台每天要操作几十次，所以流畅度很重要。开卡流程的业务逻辑是：前端提交手机号、姓名、卡类型、充值金额，后端先校验手机号是否已经注册过；校验通过后生成卡号，写入会员主表；若充值了金额，同时写入一张充值流水，并累加会员的total_recharge字段。
开卡时校验手机号这一步，是一个被很多人忽略的坑。如果同一个手机号被注册了两张会员卡，后续的消费记录要跑到哪张卡上，会造成很大的困扰。我一开始没有做这个校验，后来运营统计会员数据时发现同一个人有两个会员号，数据都乱了，才补上了手机号唯一校验。
等级计算规则：开卡时根据充值金额判断初始等级，规则配置在member_card_type表里，比如一次性充值 500 元到普通卡、1000 元到银卡、3000 元到金卡。卡等级的变化不一定要自动完成，续费时根据新的累计充值金额重新计算等级即可，这样逻辑清晰，也不容易出现自动升级导致等级混乱的问题。
4.2 会员续费与余额充值
续费是一个典型的金额变动场景，会同时影响会员的到期时间、余额、等级。会员拿着旧卡到前台，要求续费一年，前台的业务流程是：选择会员卡类型，选择续费时长，输入充值金额，点击确定。
这个流程看起来简单，后端逻辑其实要处理几个分支。如果会员卡是时长卡，续费后要更新到期时间。这里有一个关键判断——当前是否已过期。如果没过期，到期时间在当前到期时间基础上加时长；如果已过期，从当前时间开始加时长。这个规则如果没设计好，就会出现“过期三个月的会员续费，到期时间反而没过期时续费短”的不合理结果。
余额充值逻辑相对简单，校验充值金额大于 0，更新余额，写入充值流水，更新累计充值金额，然后重新计算等级。积分处理上，充值金额按照 1 比 1 的比例累计积分，积分可以在后台用来兑换小礼品，也可以抵扣部分订场费用。积分的扣减逻辑在消费时处理，订单结束时按照金额计算应得积分并累加。
注意：续费修改到期时间时，使用乐观锁校验
update_time字段。如果没有这个机制，两个前台同时为同一个会员操作续费，会出现一方操作的更新被覆盖，导致会员到账金额漏记。
4.3 会员到期判定与定时任务设计
会员到期判定这个需求，看似简单，实际实现有讲究。第一版我用了一个定时任务，每天凌晨扫描全体会员，把到期时间小于当前时间的status字段改成过期。后来运营反馈凌晨两三点会员收到过期短信通知，这个体验不是很好。
重新设计后改成了懒更新策略：不再每天批量扫描更新状态，而是每次查询会员信息时，动态判断expire_time是否小于当前时间，如果是，则返回的状态标记为过期。这个判断在查询接口中统一处理，前端展示和权限校验都基于这个即时结果。真正的状态更新还是交给定时任务去做，但频率从每天改成每小时一次，短信通知只对刚过期的会员发送。
这个设计的变化背后是一个经验：像“到期”这类状态，不要依赖定时任务去主动刷新，而是要在读取的关键路径上做即时判断。定时任务负责数据修正和通知触发，查询接口负责状态呈现，两者配合才能既便宜又能保证用户体验。
定时任务的实现用 Spring 自带的@Scheduled注解就够了，不需要引入 quartz 这类重量级框架。配置方式和核心逻辑如下：
@Component public class MemberExpireTask { @Scheduled(cron = "0 0 * * * ?") public void checkExpireMembers() { // 查询所有状态正常但到期时间小于当前时间的会员 LambdaQueryWrapper<Member> wrapper = new LambdaQueryWrapper<>(); wrapper.eq(Member::getStatus, 1) .lt(Member::getExpireTime, new Date()) .last("limit 500"); List<Member> expiredMembers = memberMapper.selectList(wrapper); for (Member member : expiredMembers) { member.setStatus(3); memberMapper.updateById(member); // 发送到期通知，这里调用消息服务 messageService.sendExpireNotice(member.getPhone(), member.getName()); } } }4.4 会员查询与列表导出
会员列表查询在后台管理页面里使用频率极高。前台输入手机号或者姓名，马上就能看到会员信息。这里的查询接口使用了 MyBatis-Plus 的分页插件，配合多条件组合查询，性能足够流畅。
列表页面显示会员卡号、姓名、手机号、卡类型、余额、到期时间、状态这几个字段。运营和前台经常需要把会员数据导出来做线下分析，所以接口里加了一个导出 Excel 的功能。当时我用的方式是使用更现代的 Excel 处理库，几行代码就能生成前端下载所需的文件。这个导出功能虽然技术含量不高，但在实际运营场景里非常实用。
数据导出有一个性能问题值得提醒：如果会员量超过十万，一次性查询全量数据再写入 Excel 会内存溢出。当前这套系统会员量还在十万以内，所以直接查询没问题，但如果后续数据量增长，需要改成分批流式查询再填充文档，否则很可能会被 OOM 困扰。
5. 订场与消费结算模块的实战实现
5.1 场地信息与价格策略设计
篮球馆一般有若干片全场，有些全场可以拆成两个半场分别出租。场地信息表的设计就要支持这种灵活性，核心字段有场地名称、场地类型、可容纳人数、场地状态、计费方式。
价格策略比较复杂，同一个场地，周一早上和周六晚上的价格可能完全不同。我把价格规则抽成了一张独立的价格配置表，字段包括场地 ID、适用星期、适用时段、价格。比如 A 场，周一至周五 10:00 到 18:00 是 100 元每小时，周六周日则是 200 元每小时。这种设计把价格规则数据和场地数据分开，运营人员可以在后台灵活调整，不用改代码。
订场页面加载时，前端会先请求获取场地列表和价格规则，然后渲染出一周七天的排班表。排班表上的每个格子代表一个场地在一个时间段的占用状态。这个数据来自一个专门为排班视图设计的查询接口，聚合了当日所有订场订单的状态。这个查询关联了场地表和订单表，按日期分组返回结果，性能在数据量不大时足够快。
5.2 订场流程与时间冲突校验
订场是这个系统业务逻辑最集中的地方，前端选了场地、日期、时间段，点击预订，后端要依次完成几个步骤：
- 校验会员状态和余额/剩余次数
- 校验场地状态是否可预订
- 校验时间段是否被占用
- 计算订单金额
- 创建订单并扣减余额/次数
- 生成消费流水
- 返回订场结果
时间冲突校验是核心中的核心。校验逻辑是判断新订单的时间段和同一场地已有订单是否重叠。比如 A 场 18:00 到 20:00 已经被预订，再来一个 19:00 到 21:00 的订单，必须被拒绝。
SQL 查询的写法是：
LambdaQueryWrapper<BookingOrder> wrapper = new LambdaQueryWrapper<>(); wrapper.eq(BookingOrder::getVenueId, venueId) .eq(BookingOrder::getBookingDate, bookingDate) .ne(BookingOrder::getStatus, 3) // 排除已取消 .and(w -> w .lt(BookingOrder::getStartTime, endTime) .gt(BookingOrder::getEndTime, startTime)); Integer count = bookingOrderMapper.selectCount(wrapper); if (count > 0) { throw new BusinessException("该时间段已被预订，请选择其他时间"); }这个查询的时间复杂度是 O(1)，借助idx_booking_venue_date索引，查询很快。但是，这个场景有一个并发问题：两个前台同时提交同一个场地的相同时间段，数据库层面两者都查到没有冲突，然后都执行插入，就会造成同一时间段被占用两次。
解决办法是用数据库的唯一索引配合状态字段来控制。或者更简单一点，在 Redis 中使用分布式锁，锁的 key 设计为book:场地ID:日期:时间段，这样同一场地的同一时间段，在同一时间只会有一个请求拿到锁执行创建订单。我在项目里使用了 Redis 的SETNX命令实现这个锁，核心逻辑是获取锁成功才执行订场操作，操作完成释放锁。这是场馆管理系统中最重要的并发控制点，绝对不能省。
5.3 余额扣款与消费流水生成
扣款流程在一个事务里完成，这是防止数据不一致的关键。我使用@Transactional注解包裹整个订场方法，包括校验、创建订单、扣余额、写流水、扣次数这样多个数据库操作。中间任何一步异常，所有操作自动回滚，不会出现订单创建了但余额没扣，或者余额扣了但流水没写的问题。
扣款逻辑有一个细节需要注意：更新余额时，使用 SQL 直接执行balance = balance - #{amount}而不是先查询余额再计算新值再更新。后一种方式在并发时会出现丢失更新问题，前一种方式由数据库保证原子性。更新语句要添加一个条件，校验扣款后的余额不能为负数，where balance >= #{amount}，这样能兜底防止余额被扣成负数。
@Transactional(rollbackFor = Exception.class) public BookingOrder createBooking(BookingRequest request) { Member member = memberMapper.selectById(request.getMemberId()); if (member == null || member.getStatus() != 1) { throw new BusinessException("会员不存在或已失效"); } // 校验余额是否足够 BigDecimal amount = calculateAmount(request); if (member.getBalance().compareTo(amount) < 0) { throw new BusinessException("余额不足，请先充值"); } // 创建订单 BookingOrder order = new BookingOrder(); order.setOrderNo(generateOrderNo()); order.setMemberId(member.getId()); order.setVenueId(request.getVenueId()); order.setBookingDate(request.getBookingDate()); order.setStartTime(request.getStartTime()); order.setEndTime(request.getEndTime()); order.setPaymentType(1); order.setAmount(amount); order.setStatus(1); bookingOrderMapper.insert(order); // 扣减余额 int rows = memberMapper.deductBalance(member.getId(), amount); if (rows == 0) { throw new BusinessException("余额扣减失败，请重试"); } // 写流水 ConsumeRecord record = new ConsumeRecord(); record.setRecordNo(generateRecordNo()); record.setMemberId(member.getId()); record.setOrderId(order.getId()); record.setChangeType(1); record.setChangeAmount(amount.negate()); record.setBalanceBefore(member.getBalance()); record.setBalanceAfter(member.getBalance().subtract(amount)); consumeRecordMapper.insert(record); return order; }5.4 取消订场与退款处理
取消订场也是高频操作，会员临时有事不来，前台需要取消订单并退款。取消的业务逻辑比创建简单，但有一个关键判断：场次是否已经开始。订场开始前取消，可以全额退款；开始后取消，不退款。这个规则由场馆方定的，不同场馆策略不一样，但代码里要做成可配置。
退款的实现是生成一条退款流水，变动金额为正数，字段change_type标记为退款。同时把订单状态从已预订改成已取消。退款流水同样记录变动前后余额，这样财务对账时，每一笔金额变动都能追溯到对应的订单。
字段payment_type如果是微信或现金支付，退款逻辑就不同了，需要走线下退款操作，系统里只标记退款状态，不调整会员余额。这个判断在取消接口里用分支处理，代码逻辑清晰，不容易出错。
5.5 积分累计与会员等级联动
每笔订场消费完成后，系统会按照消费金额计算积分，规则是消费 1 元累计 1 积分，积分在下一次充值时可以根据规则抵扣现金。积分处理放在订场成功之后异步执行，不阻塞主流程，避免订场接口响应时间过长。
积分累计用到了 Spring 的异步任务功能，开启@Async注解后，积分计算和更新被提交到线程池异步执行。这里有一个历史教训：一期开发时积分处理是同步的，会员订场下单要等积分更新完才返回，高峰期接口响应偶尔会突破 2 秒，后来改成异步才解决。
会员等级和积分的联动关系：等级决定了订场时的折扣率，比如银卡会员 95 折，金卡会员 9 折。订场时计算金额会先判断会员等级，再乘以折扣率，然后保留两位小数。这个计算逻辑里优惠后金额必须做四舍五入处理，如果直接截断会出现 0.01 元的差异，对账时很难排查。
6. 常见问题与实际踩坑记录
6.1 数据库时间字段导致的会员到期异常
有段时间运营反馈，部分年卡会员明明刚续费一年，系统却提示已经过期。排查后发现是时区问题。数据库连接串里没有配置时区参数，MySQL 默认用了系统时区，而服务器时区设置和本地时间有偏差，导致expire_time字段读出来比实际时间多了几个小时。
解决办法是在 JDBC 连接串里显式指定时区参数，同时在数据库连接配置里统一使用serverTimezone=Asia/Shanghai，问题瞬间解决。这类问题很隐蔽，测试时用的是本地环境，时区一致完全没事，一部署到云服务器就出错。经验是时区配置在项目初始化时就写死，别依赖环境默认值。
6.2 订场并发抢单导致的数据冲突
订场并发问题是我重点解决的问题。上线没多久，有一次周末黄金时段，两个前台同时操作订同一个场地，系统居然都返回订场成功。数据核对时发现一张场地同时段被录入了两个订单，需要手动人工处理。
前端时间冲突校验只是一层防护，真正可靠的是数据库和锁机制。我给订场操作加了 Redis 分布式锁，锁的粒度为场地+日期+开始时间+结束时间，两个相同请求只有一个能获得锁执行，另一个会提示当前时间段操作繁忙请稍后重试。同时，我在数据库层面额外加了一个隐藏字段作为乐观锁版本号，更新订单状态时校验版本号，进一步确保并发安全。
6.3 金额精度丢失的隐形 Bug
金额精度问题是所有涉及钱的项目绕不开的坑。一期代码里，会员余额和订单金额用的都是double类型，当时也没太在意。某天财务对账发现每天营收汇总总比实际到账少几分钱，查了几天才定位到是浮点运算精度问题。
所有金额字段改为decimal后，对账问题彻底消失。这个教训相当深刻，从那以后我立了一个规矩：任何涉及金额、积分这类精确数值的字段，一律使用decimal或整数类型，绝不允许使用浮点数。计算时也统一使用专门的金额计算类，避免直接使用浮点运算符。
6.4 会员状态变更不同步的体验问题
另一个被运营吐槽较多的问题是，会员在系统里办了续费，但手机端查余额时还是旧数据。原因是手机端接口从 Redis 缓存读取会员信息，续费后缓存没有及时更新。
解决办法是在所有涉及会员信息变更的接口中，显式删除该会员的缓存，让下一次请求重新加载数据库最新数据。后来用得顺手之后，我干脆在 Redis 里封装了一个工具类，每次更新数据库后调用它清理对应 key，避免漏删缓存导致数据不一致。
6.5 统计报表数据对不上账的排查思路
统计报表模块上线后，运营反馈每日营收数据和自己算的对不上。排查过程很有代表性。第一反应是 SQL 聚合逻辑写错了，查了半天聚合函数没有明显问题；后来又怀疑是不是有订单状态没有过滤，发现统计时把已取消的订单也算了进去。
这个问题让我意识到，统计报表设计时如果把“营收”和“到账金额”混为一谈就会出错。后来报表拆分成两个口径：按订单状态区分，已完成的订单才计入营收；已取消的订单单独统计为退款金额。同时对流水表做到账金额统计，两者对不上时就能迅速定位是哪个环节的数据有问题。
7. 权限管理、日志与系统配置
7.1 基于角色的人员权限控制
后台管理系统涉及前台和店长不同角色，权限控制的实现没有引入 Spring Security 全家桶，而是用的更轻量的方式——拦截器加角色标识。登录成功后生成 token，token 中携带用户角色信息，拦截器对请求路径做匹配，匹配到管理端接口时校验角色是否满足要求。
这种方式对这个小体量系统够用，而且代码容易理解。如果直接上 Spring Security，配置和自定义过滤器会带来额外的学习成本，对项目价值不大。权限这块的边界把握原则是：能用简单的方案解决就不引入复杂的框架。
7.2 操作日志与审计
会员充值和订场这类涉及资金的操作，必须有操作日志。这一点我在需求阶段就强烈坚持了。核心资金类操作记录操作人、操作时间、操作详情、变动前后数值。这些日志审计价值非常大，发生过一次纠纷，会员投诉说充值 1000 元没有到账，我通过日志查出是前台操作失误选错了卡类型，钱充到了另一张卡上，快速解决了问题。
日志记录的实现用 AOP 切面处理简单方便，在需要记录的方法上加上自定义注解，切面统一记录入参、出参、操作人。日志表不需要刻意做分表，一年几十万条数据，MySQL 单表足以支撑。
7.3 系统参数的配置化管理
场地价格、会员等级规则、退订时限、积分兑换比例这些参数，不能写死在代码里。我建了一张系统参数配置表，键值对的形式存储，后台管理界面提供维护入口。前台改价格、调整积分比例，不用发版重启，保存配置立刻生效。
配置项读取做了一层小缓存，启动或修改后加载到内存 Map 里，配置修改时刷新。这里要注意的是配置类的字段必须有默认值兜底，防止配置缺失时业务计算出错。
8. 系统部署与维护实践
8.1 部署架构与运行环境
这套系统最终部署在云服务器上，配置是 4 核 8G 内存，对于日常几十个并发请求的体量来说绰绰有余。运行环境包含一个 Nginx 做反向代理，一个 Spring Boot 应用进程，一个 MySQL 数据库，一个 Redis 实例。
部署方式选择了传统的 jar 加 systemd 服务管理，启动脚本和服务重启都托管给 systemd，崩溃自动拉起。构建产物是标准的可执行 jar，Maven 打包后直接传到服务器，操作流程简单。后续如果需要容器化改造，这套代码架构也能直接适配，不需要大改。
建议：首次部署后，立即启用数据库自动备份。曾经因为服务器磁盘损坏导致数据库数据丢失，恢复数据花了整整一个周末。从那之后，每天自动备份一份数据库文件，并保留最近七天的备份历史，才彻底安心。
8.2 接口性能与前端体验优化
订场列表页面初期加载慢，原因是排班视图每次都要联查所有场地一周的订单，数据量一大响应就慢。优化方案是订单列表查询改为按天查询，前端切换日期时只请求当天的数据，响应时间从 3 秒下降到 200 毫秒，体验提升很明显。
另一个优化点是场地价格规则加了 Redis 缓存，价格变更频率低，缓存后大大减少了数据库查询。这里的缓存策略不需要复杂的过期时间设计，配置变更时主动清理缓存即可，简单有效。
8.3 上线后的运营反馈与迭代记录
系统上线第一个月，运营反馈了不少改进建议，优先级最高的一批：会员到期前三天发短信提醒、充值赠送金额规则可配置、订场记录支持按月份导出。这几条都切中了场馆运营的真实痛点，不是无关紧要的锦上添花，而是直接影响客户续费和营收管理的功能。
迭代过程也让我总结出一个心得：和业务方保持高频沟通，不要让运营在系统上凑合用但心里抱怨。每次版本更新都去现场待半天，听前台实际操作中遇到什么问题，及时调整。技术做得再漂亮，如果业务人员用着别扭，一切等于零。
9. 一些实操心得与总结
这个项目整体做下来，最深刻的体会是一个字：稳。对于中小场馆的管理系统，技术上的炫技不是重点，数据准确、流程清晰、操作顺手才是核心。设计数据库阶段花的时间最值得，表结构设计合理了，后续加功能基本都是顺水推舟；表结构设计草率，后面每个功能都要在别扭的数据模型上打补丁。
最后分享一个小技巧，关于这个系统后续的扩展方向。如果球馆想要做私域运营，可以在这个系统基础上加一个会员小程序，让会员自助订场、查余额、在线充值。后端架构上，把现有接口整合成微信小程序可以调用的 HTTP API 即可，认证方式换成小程序登录，数据模型完全不用改动。小程序端的场馆预约体验比人工在前台操作高效得多，对球馆提升复购率帮助很明显。
如果你正在做类似的场馆管理系统，建议从会员和订单这两条主线先打通，把账算清楚，再考虑花哨的功能。数据基础打牢了，后面踩坑会少很多，这是我做完这个项目之后最大的心得。
