企业官网建设流程全解析

自习室预约这套题，说实话已经被做成“毕业设计常青树”了。但凡带点管理系统的课设、毕设，十有八九绕不开这个选题。我这次做的就是一个基于SpringBoot+Vue的MVC架构自习室管理和预约系统，技术栈落在Java+MySQL+MyBatis上，属于典型的全栈分离项目。整个系统拆成用户端和管理端两套界面，用户在手机上或者浏览器里能看到自习室列表、楼层分区、座位占用情况，选个座位预约一段时间；管理员在后台维护自习室、座位、预约规则，还能看统计报表。

这篇文章我就按自己做这个项目的完整过程来写，从需求拆解、技术选型、数据库设计，到后端接口、前端交互、部署运行，再到我实际踩过的坑，都会交代清楚。适合正在做课设/毕设、想复现一个完整前后端分离项目的同学参考，也适合想入门SpringBoot+Vue全栈开发的人照着搭一套练手。源码层面我会把关键代码片段贴出来，不是那种“只给目录不给细节”的分享。

1. 项目到底要解决什么问题

1.1 自习室预约的核心痛点

学校或者社会自习室的座位资源，看起来是“公共的”，但实际运营起来全是问题。最常见的场景就是考研季、期末周，座位严重不够用，第二天一早门口排队抢座，甚至有人拿书占座几天不来。反过来，非高峰期大量座位空着，资源闲置。自习室管理员也很头疼，纸质登记本翻起来麻烦，谁占着座位、什么时候走，完全靠人肉盯。

这个系统的核心价值就是把“座位状态数字化”。每一张座位在系统里都有明确状态：空闲、已预约、已签到、暂离、禁用。用户预约之前一眼看清哪些座位能用，预约之后到现场签到入座，离开时释放座位。管理员不用再跑现场，后台就能看到实时占用率，还能设置每个自习室的开放时段、预约时长上限。本质上这就是一个带时间维度的资源管理系统，和会议室预约、健身房场地预约的逻辑是相通的。

1.2 功能拆解与用户角色设计

用户角色我分成三类：普通学生用户、管理员、超级管理员。没有做“教师”角色，因为自习室场景里教师通常只参与审批或者设备管理，没必要为了凑功能硬加。

普通用户侧的关键功能：

• 注册登录、个人信息维护
• 查看自习室列表，按楼栋、区域筛选
• 查看每个自习室的座位图，区分不同座位状态
• 预约座位，选择日期和起止时间
• 签到入座、暂离、释放座位
• 查看自己的预约记录、违规记录

管理员侧的关键功能：

• 自习室管理：新增、编辑、启停用
• 座位管理：批量生成座位、设置座位类型（靠窗/普通/带电源）、禁用某个座位
• 预约规则管理：设置可预约天数、单次最长时长、签到时限
• 预约记录查询与统计，导出表格
• 用户管理：封禁、解封、重置密码

开发展示中最容易被问的就是“这个系统有什么亮点”。我当时给出来的方案是“座位状态实时同步+预约冲突兜底”。也就是用户在选座时看到的座位状态是准实时的，提交预约时后端再做一次防冲突校验，避免两个人同时锁到同一个座位。

2. 技术选型与架构设计思路

2.1 为什么是SpringBoot+Vue这套组合

先说后端。SpringBoot在这个场景里几乎是无可争议的选择，原因很简单：内嵌Tomcat，不需要额外部署Web容器；自动配置把大量样板代码省掉；生态成熟，社区资料多，遇到问题基本都能搜到答案。相比之下，如果再用传统的SSH（Spring+Struts+Hibernate）那一套，光是写各种XML配置就能劝退一堆初学者。

我用的版本组合比较稳：SpringBoot 2.7.x + JDK 1.8 + MySQL 5.7/8.0 + MyBatis 2.x。为什么要锁这个版本？因为SpringBoot 3.x强制要求JDK 17，而且部分老项目用的MyBatis、PageHelper插件在3.x下需要额外适配，如果你照着网上的教程抄作业，大概率会踩版本不一致的坑。所以我的建议是：除非你有明确理由，否则毕设/课设别追新版本。

前端选Vue就更好理解了。Vue 2.x + Element UI是当前中文社区里资料最多、最稳定的组合，Vue 3 + Element Plus虽然新，但有些组件用法变动比较大，网上的老旧教程容易误导。我这次用的是Vue 2.6 + Element UI 2.15，配合vue-router和axios，足够支撑这种后台管理+用户选座的场景。

2.2 MVC分层在后端怎么落地

标题里特意提到MVC，这个必须解释清楚。MVC本身是一个设计思想，不是一套固定框架。我后端的代码结构就是按照Controller、Service、Mapper（DAO）三个层次来的，Model用实体类和VO来表现。

典型的调用链路是这样的：

• 浏览器发起请求到Controller层
• Controller负责参数接收、简单校验，然后调用Service层
• Service层处理业务逻辑，比如校验预约冲突、计算座位状态
• Service调用Mapper接口，Mapper对应XML里的SQL
• MySQL返回结果，Mapper映射成实体类，经过Service组装成VO，最后由Controller返回JSON给前端

这样的分层好处很明显，至少有三点：

1. 各层职责单一，代码可读性好。别人拿到项目不需要翻完整套代码，只看Controller就知道系统提供了哪些接口。
2. Service层独立后，业务规则可以单独做单元测试。比如预约冲突检测这种核心逻辑，不依赖Controller和前端就能跑通。
3. 后期替换技术方案更方便。比如把MyBatis换成MyBatis-Plus，或者把MySQL换成PostgreSQL，底层影响可以被控制在Mapper层。

实体类这块我做了一个区分：数据库表对应的叫Entity，接口返回前端的叫VO，前端提交参数用DTO。之前的项目吃了不区分的亏，查了一个用户信息顺便把密码hash也返回了前端，虽然前端不显示，但这事很不专业。

2.3 前端Vue项目的目录组织

Vue项目不是简单的“一个页面一个组件”就完了。我按功能模块拆分成view（页面级组件）和component（可复用组件）两大类。

• src/api：axios请求封装，按模块拆分成user.js、seat.js、reservation.js
• src/router：路由配置文件，区分需要登录的页面和不需要登录的页面
• src/store：Vuex，存放用户登录信息、当前选中的自习室状态
• src/views：页面级组件，比如Login.vue、SeatMap.vue、Admin/ReservationManage.vue
• src/components：通用组件，比如座位格子SeatItem.vue、分页组件封装的PaginationTable.vue

实际开发中很多初学者会把所有逻辑全部塞进一个页面组件，几百行代码堆在一个Vue文件里，后面想改一个选座逻辑都要翻半天。我这次强行把座位图抽成了独立组件，状态由父页面传入，交互通过事件回调，这样座位图组件可以单独测试，也能复用到管理端的座位预览功能里。

3. 数据库设计：预约系统的命门

3.1 核心表结构设计

数据库设计是这种系统里最考验功力的部分。表设计不好，后面写业务代码就是连环坑。我规划了这几张核心表：

• sys_user：用户表，字段包括id、username、password、real_name、role、status、create_time
• study_room：自习室表，字段包括id、name、location、floor、open_time、close_time、status、capacity
• seat：座位表，字段包括id、room_id、seat_no、type、position_x、position_y、status
• reservation：预约记录表，字段包括id、user_id、seat_id、room_id、reserve_date、start_time、end_time、status
• violation_record：违规记录表，记录超时未签到、超时未释放等情况

用户表里role字段我直接用的字符串：USER、ADMIN、SUPER_ADMIN。也有人用int类型再在代码里映射枚举，我个人觉得字符串更直观，查数据库的时候一眼能看懂，也不容易被数字映射搞糊涂。

座位表里的position_x和position_y是干嘛的？这是为了前端渲染座位图准备的。每张座位在自习室的平面图里有一个坐标，前端拿到数据后可以直接按坐标渲染到对应位置，比后端拼接好HTML再返回强多了。当然，纯粹做简单系统也可以让前端写死布局，但那样教室里临时加把椅子就得改代码。

3.2 预约时间冲突的处理思路

预约系统的核心难点不是CRUD，而是“同一座位同一时间段不能被两个人预约”。这个冲突检测我一开始想用纯SQL来做，后来发现反而复杂，干脆在Service层加锁校验。

逻辑是：用户提交预约时，后端根据seat_id和reserve_date去查已经存在的预约记录，只要新预约的时间段和已有记录存在重叠，就拒绝。SQL大概是这样的：

<select id="selectConflict" resultType="java.lang.Integer"> SELECT COUNT(*) FROM reservation WHERE seat_id = #{seatId} AND reserve_date = #{reserveDate} AND status IN ('BOOKED', 'CHECKED_IN', 'AWAY') AND NOT ( #{newEndTime} &lt;= start_time OR #{newStartTime} &gt;= end_time ) </select>

这里的时间重叠判断就是两个区间的交集判断：新预约开始时间不早于已有记录的结束时间，或者新预约结束时间不晚于已有记录的开始时间，才算不冲突。反过来，只要两个时间段存在任何交叉区域，就说明有人占用了。

只做查询校验还不够。两个请求同时提交，理论上都能通过校验，然后都插入成功，这就产生了并发问题。解决办法一个是给座位加行锁，用SELECT ... FOR UPDATE把座位记录锁住再校验；另一个是对reservation表加唯一索引配合状态字段。我最终采用的是“事务+座位行锁”的方案，这也是商用系统中比较稳妥的做法。

3.3 索引设计

索引不是用来炫技的，而是要命中实际查询场景。这个系统里查询频率最高的场景就两个：

1. 用户查询自己某一时间段的预约记录
2. 按座位查询某个日期的预约占用情况

所以我在reservation表上建了两个复合索引：

• idx_user_time (user_id, reserve_date, start_time)
• idx_seat_time (seat_id, reserve_date, start_time)

建索引的理由很直接：预约记录表会越来越大，没有索引的话，WHERE user_id = ? AND reserve_date BETWEEN ? AND ?这种查询就是全表扫描，数据量到几万条之后响应时间会明显变差。加了复合索引后，查询可以走索引快速定位，排序也顺手能利用上索引。

再强调一个细节：不要给每个字段单独建索引，那样不但不加速，反而拖慢写入速度。MySQL的索引机制决定了复合索引的字段顺序也有讲究，最常用的等值条件字段放前面，范围条件字段放后面。

4. 后端核心实现与关键细节

4.1 登录认证与用户上下文

登录这块我用的方案是JWT（JSON Web Token）。跟Session那套比，JWT最大的好处是无状态，后端不用存储会话记录，横向扩展的时候不用做会话同步。对毕设项目来说，前端拿到token后存到localStorage里，每次请求在axios拦截器里带上Authorization头就行。

具体实现上，我用JWT生成token时把user_id作为payload核心字段。用户每次请求受保护接口时，后端拦截器解析token，拿到user_id后去redis（或者直接查数据库）取用户信息，放入ThreadLocal里作为本次请求的用户上下文。注意，我在这里没有用Spring Security，因为对自习室预约这种场景来说，Spring Security的学习成本和配置成本有点重。自己写一个HandlerInterceptor + 自定义注解@RequireRole，代码量不大，逻辑还更好懂。

自定义注解是这样一个思路：

@Target(ElementType.METHOD) @Retention(RetentionPolicy.RUNTIME) public @interface RequireRole { String value() default "USER"; }

在拦截器中，根据Controller方法上的注解判断当前用户是否拥有对应角色。管理端接口标记@RequireRole("ADMIN")，用户端接口标记@RequireRole("USER")，超级管理员两个角色都能访问。

4.2 预约与取消的核心业务逻辑

预约的核心逻辑我在Service里用事务包裹起来，大致流程是这样的：

1. 校验用户是否有预约权限（是否已被封禁、是否已经约了同一时段）
2. 锁定座位记录，SELECT ... FOR UPDATE
3. 查询冲突预约，判断时间段是否重叠
4. 插入一条预约记录，状态为BOOKED
5. 更新座位状态为OCCUPIED

为什么要先锁座位再查冲突？因为如果不锁，并发场景下两个人同时查到“无冲突”，然后都插入成功，就出现了超卖问题。锁座位虽然牺牲了一点并发量，但对于自习室这种场景完全没有压力，单把椅子一天最多也就被约几次，没有效能瓶颈。

取消预约的规则有个细节：距离预约开始时间不足30分钟，不允许用户在线取消，必须到现场找管理员操作。这个规则在管理端可以配置，但默认值我是直接写在Service层常量里。为了这个规则，我在事务里能直接判断当前时间是否满足条件，很快，也不用额外设计提醒表。

流程是：删除或标记预约记录为CANCELLED，同时释放座位状态。我选择的是保留预约记录、把状态改成CANCELLED，而不是物理删除。这样保留历史数据，后面做统计分析（比如“哪些座位最受欢迎”）才有数据可用。

4.3 MyBatis动态SQL与缓存配置

MyBatis在这个项目里承担所有数据库访问工作。我坦白说，一开始我也纠结要不要用MyBatis-Plus，因为它真的能省掉大量单表CRUD代码。后来考虑到很多课设答辩的老师要求“使用MyBatis实现”，所以我保留了原生MyBatis的XML写法，把多表查询和动态SQL都写清楚了。

动态SQL在预约记录查询里特别好用。管理端查询预约记录时，筛选条件可能是“按日期查”“按自习室查”“按用户姓名查”，也可能全部不选查全量。这种场景用动态SQL最合适：

<select id="selectReservationPage" resultType="com.example.entity.Reservation"> SELECT r.*, u.username, s.seat_no FROM reservation r LEFT JOIN sys_user u ON r.user_id = u.id LEFT JOIN seat s ON r.seat_id = s.id <where> <if test="roomId != null"> AND r.room_id = #{roomId} </if> <if test="reserveDate != null"> AND r.reserve_date = #{reserveDate} </if> <if test="status != null and status != ''"> AND r.status = #{status} </if> </where> ORDER BY r.reserve_date DESC, r.start_time DESC </select>

<where>标签会自动处理“第一个条件前面的AND会被去掉”的问题，不用自己手动拼接字符串，避免SQL注入的同时代码也干净很多。

MyBatis的二级缓存我也聊一下。默认情况下MyBatis的二级缓存是关闭的，我没有在全局开启，而是只对seat表的Mapper开了二级缓存。原因很简单：预约记录和用户表的实时性要求高，缓存命中率低，而且一旦数据变更还要考虑缓存刷新，容易脏读。座位表相对稳定，状态变更频率不高，开启二级缓存后可以少打几次数据库。不过要注意，现在很多项目直接用Spring Cache + Redis做缓存，MyBatis的二级缓存用得少了，因为多级缓存的一致性维护成本偏高。

4.4 管理端功能实现

管理端的核心功能是自习室和座位管理，我用了一个比较省事的思路：座位批量生成。

一个自习室可能有几十上百个座位，一个个人工录入不现实。我的方案是在新增自习室时，让管理员输入“行数”和“列数”，系统自动生成座位编号（例如A01、A02，B01、B02），并按照坐标规则写入seat表。这样既省了管理员的工作量，又保证了前端座位图的位置数据是完整的。

座位批量生成的核心代码大致是：

for (int row = 1; row <= rowCount; row++) { for (int col = 1; col <= colCount; col++) { Seat seat = new Seat(); seat.setRoomId(roomId); seat.setSeatNo(String.format("%s%02d", (char)('A' + row - 1), col)); seat.setPositionX(col); seat.setPositionY(row); seat.setStatus("FREE"); seatMapper.insert(seat); } }

管理端还有一个实用功能是今日统计。首页展示“今日预约数”“当前在场人数”“自习室占用率”。占用率的计算方式是：当前已占用座位数 / 总座位数，查询时先分组查每个自习室的座位总数，再查当前状态为OCCUPIED的座位数，两个数据在Service层合并成统计VO返回前端。

5. 前端页面与交互实现

5.1 Vue路由与页面结构

前端路由用的是Vue Router。路由设计上我分了两层：不需要登录就能访问的和必须登录才能访问的。

不需要登录的路由：

• /login：登录页
• /register：注册页

必须登录的路由放在/layout父路由的children里，因为这一部分页面都有共同的顶部导航和侧边栏布局。

{ path: '/layout', component: Layout, redirect: '/layout/home', children: [ { path: 'home', component: Home, meta: { title: '首页' } }, { path: 'rooms', component: RoomList, meta: { title: '自习室' } }, { path: 'seat-map', component: SeatMap, meta: { title: '选座' } }, { path: 'my-reservation', component: MyReservation, meta: { title: '我的预约' } } ] }

管理端路由单独建了一份，挂在/admin下面，比如/admin/room-manage、/admin/seat-manage、/admin/reservation-manage。这里要注意的是，前端路由的权限控制只是用户体验层面的，真正的权限校验必须依赖后端接口。前端不能访问的页面只是看不到入口，如果直接调后端接口没有权限，后端必须返回403。

路由守卫方面，我在router.beforeEach里检查本地有没有token：

router.beforeEach((to, from, next) => { const token = localStorage.getItem('token'); if (to.meta.requiresAuth && !token) { next('/login'); } else { next(); } });

5.2 座位选座交互

选座界面是整个前端最核心的交互页面，我在设计上参考了影院选座、演唱会选座那一套：一个平面图，座位格子一个个平铺在上面，用颜色区分状态。

座位状态的配色我定的是：

• 空闲：白色/浅灰色
• 已预约：黄色
• 已签到：绿色
• 暂离：橙色
• 禁用：深灰色打叉

用户点击一个空闲座位后，右侧弹出预约面板，选择日期和起止时间，点击确认后走预约接口。这个交互逻辑我封装在SeatMap.vue里，数据来源是后端接口返回的座位列表和座位状态列表。

这里有一个交互细节：用户选中座位后，要在前端本地标记“正在选中”状态，但这个状态不能和后端实时同步，等到真正提交时才返回给后端。所以为了防止两个用户同时选同一座位，前端显示的状态只能作为参考，后端提交时的冲突校验才是兜底。

座位图渲染的模板大概是：

<div v-for="seat in seatList" :key="seat.id" class="seat-item" :class="getSeatClass(seat)" :style="{ left: (seat.positionX - 1) * seatSize + 'px', top: (seat.positionY - 1) * seatSize + 'px' }" @click="handleSeatClick(seat)" > {{ seat.seatNo }} </div>

座位尺寸我固定用44px×44px，间距6px，这样一张A4纸宽度的屏幕能放下十几个座位，体验比较自然。如果自习室座位特别多，还可以在右侧加一个缩小比例的迷你地图用于快速定位。

5.3 Axios封装与权限控制

axios不能每个组件里单独引一遍，要统一封装。我在src/api/request.js里做了以下事情：

1. 创建axios实例，设置baseURL和timeout，baseURL指向后端接口地址，比如http://localhost:8080/api
2. 请求拦截器里从localStorage读取token，放到请求头
3. 响应拦截器里统一处理HTTP状态码：401跳转登录页，403提示无权限，500提示服务器错误
4. 把后端返回的业务状态码也做了统一处理，比如code=500的提示语统一用Element UI的Message组件展示

这种封装的好处是，后面如果后端接口地址变了，只需要改一个文件；如果后端的鉴权方式变了（比如改为请求参数携带token），也只需要改一个拦截器，组件里的业务代码完全不用动。

6. 从零到一：完整部署运行步骤

6.1 本地环境准备

先说一下我本地的环境：

• JDK 1.8（如果你是JDK 17，也可以跑SpringBoot 2.7，但部分老插件可能报错）
• Maven 3.6+
• MySQL 5.7或8.0
• Node.js 14+（Vue 2项目不建议用Node 18+，会有兼容问题）
• IDE：后端用IDEA，前端用VS Code

环境这块我吃过亏，尤其Node版本。Vue 2的老项目用Node 17+跑npm install经常报Error: error:0308010C:digital envelope routines::unsupported，这是因为新版Node的OpenSSL策略变了。解决办法要么把Node降级到14/16，要么在package.json的启动脚本里加一句NODE_OPTIONS=--openssl-legacy-provider。我更推荐前者，降级到Node 14一了百了。

6.2 数据库初始化

数据库这块，我用Navicat新建一个study_room_db数据库，字符集选utf8mb4（为什么不用utf8？因为utf8在MySQL里是utf8mb3，不支持emoji和一些特殊字符，虽然系统里不太用emoji，但保不准用户昵称里有特殊符号）。然后直接执行init.sql脚本，里面包含建表语句和初始数据。

初始数据至少要有：

• 一个超级管理员账号：admin/admin123
• 两个自习室数据
• 每个自习室对应的座位数据，我直接用批量插入SQL写死了
• 几条演示用的预约记录，方便前端展示效果

关于账号密码，我在user表里存的是MD5加密后的值。明说一句，MD5现在已经不够安全了，真正商用至少要用BCrypt。我这里图省事用了MD5，但代码里把加密算法抽成了工具类，想替换成BCrypt很容易。

6.3 后端启动

后端项目导入IDEA后，第一步修改application.yml里的数据库连接配置：

server: port: 8080 spring: datasource: url: jdbc:mysql://localhost:3306/study_room_db?useUnicode=true&characterEncoding=utf8mb4&useSSL=false&serverTimezone=Asia/Shanghai username: root password: 你的数据库密码 driver-class-name: com.mysql.cj.jdbc.Driver mybatis: mapper-locations: classpath:mapper/*.xml type-aliases-package: com.example.entity configuration: map-underscore-to-camel-case: true

map-underscore-to-camel-case这个配置一定要开启，否则数据库字段seat_no映射到Java属性seatNo会失败，查询结果全是null。这是个非常典型的新手问题，排错能排半天。

配置改完后，先启动MySQL，再运行StudyRoomApplication主类。后端启动后，浏览器直接访问http://localhost:8080/api/health，如果能返回正常结果，说明后端已经跑起来了。

6.4 前端启动

前端项目打开终端，按顺序执行：

npm install npm run dev

npm install如果速度慢，可以换成淘宝镜像源，先执行npm config set registry https://registry.npmmirror.com再装。启动后开发服务器默认跑在http://localhost:8081（我特意把端口改到8081，避免和后端8080混淆）。

Vue开发服务器的端口可以在vue.config.js里配置：

module.exports = { devServer: { port: 8081, proxy: { '/api': { target: 'http://localhost:8080', changeOrigin: true } } } }

这里用proxying而不是直接写死http://localhost:8080作为baseURL，是为了避免开发阶段的跨域问题。浏览器访问8081端口，请求通过Vue开发服务器转发到8080，同源策略就不会拦截了。如果不用proxy，要么后端配置CORS，要么前端调接口时直接带完整地址但会被浏览器拦截，所以这个配置很关键。

7. 常见问题与排查经验

7.1 端口占用与配置不一致

启动后端时最常遇到的报错就是：

Web server failed to start. Port 8080 was already in use.

端口被占用的原因五花八门，可能是你自己之前启动过一次没关掉，也可能是其他软件抢占了端口。排查方法：

• Windows下用netstat -ano | findstr 8080查看占用进程PID
• 用taskkill /PID 进程号 /F强制杀掉
• 或者在application.yml里换一个端口

但我更建议换端口而不是杀进程，因为杀掉的进程有可能是别人正在用的服务。比如你机器上已经跑了一个Tomcat在8080，你非要用8080，最好还是改自己的项目端口。

7.2 数据库连接失败排查

数据库相关的报错几乎占了新手问题的一半。常见的几个：

Communications link failure这个报错十有八九是数据库没启动，或者连接地址写错。先确认MySQL服务在系统服务列表里是“运行中”，然后在命令行用mysql -u root -p直接连一下，确认账号密码没问题。

Unknown database 'study_room_db'这个就是数据库没创建，或者名字写错了。去Navicat里看看库名是不是和url里的一致，注意大小写。

The server time zone value 'Öйú±ê׼ʱ¼ä' is unrecognized这个报错是因为MySQL时区设置问题，在url上加serverTimezone=Asia/Shanghai就能解决。如果还报错，就在MySQL的配置文件my.ini里加上default-time-zone = '+08:00'。

7.3 跨域问题

我用了devServer的proxy方案之后，开发阶段基本不会遇到跨域。但如果你把前端打包成静态文件在Nginx里部署，或者直接打开dist/index.html，跨域问题就会冒出来。

本地开发时如果不用proxy，就必须在后端加CORS配置。一个简单的做法是在Controller上或者全局配置类上加@CrossOrigin或CorsFilter。CORS配置时要指定允许的来源、方法和请求头，不能直接写*加允许所有请求头，那是懒人配置，不严谨。

前端部署时更推荐Nginx反向代理的方式，把/api/开头的请求转给后端服务。Nginx配置大致是：

location /api/ { proxy_pass http://127.0.0.1:8080; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; }

7.4 MyBatis相关坑

MyBatis使用中我踩过最深刻的坑就是“SQL没有问题，但查询结果全是null”。这个我在前面提过，就是map-underscore-to-camel-case没开启。如果你不喜欢全局开这个配置，也可以在XML里的resultMap里手动映射每一列，但是那样的代码量翻倍，不推荐。

另外一个坑是参数传递问题。当Mapper接口方法有两个或以上参数时，必须用@Param注解标注参数名，否则MyBatis不知道#{userId}对应哪个参数。我见过太多人写这样的代码然后报Parameter 'xxx' not found的错误。

还有MyBatis的<if>判断，字符串比较时写成<if test="status == 'BOOKED'">有时候不生效，原因在于MyBatis解析OGNL表达式时，单引号内的内容会被解析成字符而非字符串。正确写法是<if test='status == "BOOKED"'>，外层用单引号，内层用双引号。这个真是很阴间的细节。

7.5 预约并发冲突实战

最后说一个真实遇到过的业务问题。系统上线模拟压力测试时，两个用户同时点预约同一个座位，结果两个都成功了。我排查后发现，问题出在事务边界上：我第一次把座位状态校验放到了事务外，等事务内插入时才去更新座位，中间丢了一个校验窗口。

修正方案是在Service方法上加@Transactional，进入事务后先执行SELECT ... FOR UPDATE锁定该座位记录，再执行冲突查询和插入操作。加上行锁之后，模拟并发请求就不会再出现超卖场景了。

这个问题的通用排查思路就是：凡是涉及“资源唯一性”的业务（座位、库存、优惠券），都必须考虑并发。只有业务校验没有数据库锁或者唯一约束，迟早出问题。

8. 项目扩展与个人心得

做完这套系统，再回头去看，我会觉得技术栈本身并不复杂，真正花时间的其实是业务规则的设计和落地。预约时间冲突判断、签到时限、暂离时长限制，每一个规则边界都需要想清楚，否则上线之后运营人员会被各种边界case折磨。

很多人以为做一个管理系统就是增删改查，做完才发现，增删改查只是最外面一层皮，真正的核心在于“状态机怎么流转”“并发下如何保持一致”“用户体验怎么做得好”。如果你也正在做类似的系统，我的建议是先把业务流程图画明白，把每个状态之间的跳转条件和限制想清楚，再动手写代码。数据库设计可以花一整天反复推敲，这比代码写了一半再改表结构要划算得多。

这个项目后续可以扩展的方向也很多。比如加入一个基于WebSocket的实时座位状态推送，有人释放座位时其他在线用户立刻看到；或者引入Redis缓存热点数据，减轻数据库压力；再或者把前端升级成Vue 3 + TypeScript，代码的可维护性会再上一个台阶。但这些都是增量优化，核心骨架不变。

最后说一个实际开发里的细节：我在项目里对所有时间字段统一用了LocalDateTime而不是Date。这样在做时间段比较的时候比Date要顺手很多，也避免了时区偏移导致的坑。如果你正在选型阶段，一开始就统一用LocalDateTime，能省掉后面不少麻烦。