大学时候做毕业设计，我在"会议室预约"和"宿舍报修"之间纠结了很久。最后选了SSM + 微信小程序的会议室预约系统，这个决定后来证明是相当值的：题目不算烂大街到毫无新意，但业务逻辑足够清晰，答辩时能讲的东西非常多，而且最后改成自己简历里的项目经历也顺理成章。这篇文章我把从选题、数据库设计、后端接口到小程序前端的整个实现过程，以及调试阶段踩过的那些坑都写出来。如果你正在选毕设题目，或者拿到一套SSM小程序源码却不知道怎么跑通、怎么讲清楚，这文应该能省你不少事。
1. 为什么"SSM + 微信小程序"是会议室预约毕设的稳妥答案
1.1 会议室预约的业务场景比你想象的更适合做毕设
很多同学选毕业设计题目，一上来就想要"高大上"：人工智能、推荐算法、区块链。结果往往是查了两个星期文献，发现自己连业务模型都抽象不出来。会议室预约这题目的好，在于它的核心矛盾非常具体——"同一间会议室在同一时间段不能被两个人占用"。这一个冲突规则，就支撑起了整个系统的数据表设计、接口设计和页面交互，不需要你去编造需求，业务天然成立。
再往深了想，会议室预约其实是一个典型的资源预约模型：用户查看资源、选择时间段、提交申请、管理员审批、只能查看自己的预约历史。把这个模型换皮成机房预约、实验室预约、面试间预约，就是另一套毕设。如果是本科毕设，这属于"业务清晰、亮点可做、工作量可控"的黄金区间，你不用为了凑字数硬造功能，数据库几张表就足以说明问题。
小程序端的价值在场景上也有天然加成：审批流程通常是领导在手机上批，而不是坐在电脑前开OA。小程序天然支持移动端，演示的时候老师扫码也好、用开发工具打开也好，都比在教室电脑上配环境顺滑得多。
1.2 为什么后端选SSM而不是Spring Boot
我知道你要问：现在企业里都用Spring Boot，为什么还写SSM？
这里分的两种情况说。如果你的毕设是导师指定用SSM，那不用纠结，直接做。如果学校没限定，SSM依然是很多计算机学院课程设计的主流选择，因为教学内容就是用Spring + SpringMVC + MyBatis讲框架原理。SSM最大的优势在于"框架边界清晰"：Spring管Bean、SpringMVC管请求、MyBatis管数据库，你可以在答辩时讲清楚每一个请求进来的处理链路，这是Spring Boot自动配置很难讲出来的深度。
另一个现实原因是，SSM项目的配置过程本身就是考点。数据源配置、包扫描、Mapper映射、视图解析器，每一步都是白纸黑字写出来的，答辩老师随便问到你都能接上话。Spring Boot一个注解全自动搞定，你反而没什么可讲的。所以如果你的方向是要在答辩中展示扎实基础，SSM是一个更稳的选择。
当然，我也得说实话，SSM配置出错概率高，启动失败时排查日志相对麻烦。这篇文章后面第3章我会把重点配置都贴出来，你照着搭就能少折腾两三天。
1.3 为什么前端选小程序而不是网页
这个是我实际做完后的真实体会。小程序作为毕业设计前端，有一个网页端完全比不了的好处：它自带一套完整的页面容器、导航栏、滚动容器和基础组件。你不需要像Vue那样折腾路由、处理浏览器兼容性，重点是业务本身。
小程序还有一个加分点：原生组件与API能实现一些网页不好做的交互。比如预约时选时间，用picker组件就能直接弹起手机自带的时间滚动选择器；查看审批消息，可以用subscribeMessage做模板消息通知。这些在答辩演示时都很直观，老师确实能看到"这是一个完整可用的移动应用"。
不过小程序也有它烦人的一面：真机预览需要配置合法域名，本地调试要用IP地址，顶部导航栏的高度在刘海屏和普通屏上还不一样。这些坑我在第5、6章会集中整理，提前知道了能省很多时间。
2. 数据库设计与预约冲突检测，整个项目的灵魂
2.1 三张核心表的设计思路
会议室预约系统的数据模型，不要一上来就建七八张表。先想清楚最小可行模型：有用户、有会议室、有预约记录，就够了。我的表结构设计如下：
- 用户表
user：用户信息与权限位，字段包括id, username, password, real_name, phone, role。其中role用整数区分：1为普通员工，2为管理员。密码不建议明文存，用MD5加密存储，答辨时还能顺便讲一讲"密码不应该明文存储"的考量。 - 会议室表
room：id, name, location, capacity, equipments, image, status。equipments用逗号拼接的字符串保存，如"投影仪,视频会议,白板"，前端拿到后拆分显示即可。status表示会议室是否可用，如果临时装修可以停用。 - 预约记录表
reservation：id, order_no, room_id, user_id, topic, date, start_time, end_time,status, remark, create_time。order_no是预约单号，拿去展示在列表里，看起来更正式。
除此之外可以加一张banner表放轮播图，字段就是id, image_url, link_room_id, sort。会议室的图片也好、轮播图也好，数据库里存的是图片的相对路径或完整URL，前端通过后端接口拿。
这个表的数量对于本科毕设来说刚刚好：不多不少，每张表都有存在意义，答辨时讲数据表设计能讲够五分钟。
2.2 时间冲突检测：不要在Java里逐条对比
预约系统最容易写垃圾的地方就是冲突检测。很多同学的思路是：查出这个会议室当天的所有预约记录，然后在Java里遍历比较时间是否有重叠。这在小数据量下没问题，但只要预约记录一多，查询数据、内存遍历、逐一判断，代码难看且效率极低。而且面试官或者答辨老师一旦问"如果存在并发预约，你怎么保证不会冲突"，这个方案就露馅了。
正确做法是让数据库完成区间重叠判断，一条SQL搞定：
SELECT COUNT(*) FROM reservation WHERE room_id = #{roomId} AND date = #{date} AND status IN ('APPROVED', 'PENDING') AND ((#{startTime} < end_time) AND (#{endTime} > start_time))这里的关键是区间重叠的判定条件：新预约开始时间小于已有预约的结束时间，同时新预约的结束时间大于已有预约的开始时间。只有两个条件同时成立，时间段才会相交。这个判断很多人一时转不过弯，你可以画一个时间轴就明白了——所有重叠情况都逃不开这个公式。
还要注意一个细节，status字段要过滤掉已取消和已拒绝的记录。如果状态为"已拒绝"的时间段依然占用，就会导致一个被拒绝的申请把时间段卡死，别人没法预约。这个我是确实踩过的，后来才发现是状态没过滤干净。
2.3 状态字段：预约流程的关键
预约记录的状态，我设计了五个值，全部用字符串存：
| 状态值 | 含义 | 说明 |
|---|---|---|
| PENDING | 待审批 | 管理员还没处理，此时时间段应占用，防止重复申请 |
| APPROVED | 已通过 | 预约生效，会议按时进行 |
| REJECTED | 已拒绝 | 管理员驳回，也就释放了时间段 |
| CANCELLED | 已取消 | 申请人主动取消，释放时间段 |
| FINISHED | 已完成 | 会议时间结束后的终态，一般由定时任务或管理员标记 |
这五个状态其实不需要说得太复杂，你只需要把握一个原则：是否占用时间段的只有 PENDING 和 APPROVED。比如用户提交申请后、管理员审批前，这中间的时间段就应该显示为"已预约"，否则两个人都提交了申请，管理员批了第一个后还得手动处理第二个。设计合理的话，第二个人的申请在提交时就会被冲突检测拦下来。
另外建议数据库里reservation表的room_id和date加一个联合索引，查询冲突时能走索引，虽然是毕设数据量不大，但这是一个"性能意识"的加分点。
3. 后端SSM分层实现与高频注解逐一拆解
3.1 SSM项目结构长什么样
拿到一个SSM项目源码，别急着运行，先看包结构。标准做法是全部按三层架构分包：
src/main/java/com/example/meeting/ ├── controller/ # 控制层，接收HTTP请求 │ ├── UserController.java │ ├── RoomController.java │ └── ReservationController.java ├── service/ # 业务层，处理核心逻辑 │ ├── ReservationService.java │ └── impl/ │ └── ReservationServiceImpl.java ├── mapper/ # MyBatis的数据访问接口 │ ├── UserMapper.java │ └── ReservationMapper.java ├── pojo/ # 实体类与请求参数对象 │ ├── User.java │ ├── Room.java │ ├── Reservation.java │ └── Result.java └── config/ # 跨域、拦截器配置 ├── CorsConfig.java └── LoginInterceptor.javaresources 下面放的是Spring和MyBatis的配置文件，以及mapper包对应的XML文件：
src/main/resources/ ├── applicationContext.xml # Spring核心配置：数据源、事务、扫描 ├── springmvc.xml # SpringMVC配置：注解驱动、拦截器 ├── mybatis-config.xml # MyBatis配置：驼峰映射、别名 ├── jdbc.properties # 数据库连接参数 └── mapper/ ├── UserMapper.xml ├── RoomMapper.xml └── ReservationMapper.xml为什么要分这么多层？用一个实际例子说：用户提交预约申请时，Controller只做参数接收，调用Service接口，ServiceImpl处理冲突检测、单号生成、落库操作。这样各层各司其职，答辨时你可以把请求从头到尾的完整生命周期讲出来，这就是加分项。
3.2 SSM常用注解的职责边界
SSM的常用注解如果你是面试或者答辩前突击，做到"看到注解能说出职责"就够了。下面是这个项目里会高频出现的一组：
| 注解 | 使用位置 | 作用 |
|---|---|---|
@Controller | 控制器类上 | 声明该类是SpringMVC控制器 |
@RestController | 控制器类上 | @Controller+@ResponseBody，接口直接返回JSON |
@RequestMapping | 类或方法上 | 映射请求URL，可指定GET/POST |
@ResponseBody | 方法上 | 把返回对象序列化为JSON写入响应体 |
@Autowired | 字段或构造器 | 按类型自动注入Spring容器中的Bean |
@Service | Service实现类 | 声明业务层组件 |
@Repository | Mapper接口写不写都行 | 声明数据访问层组件 |
@RequestParam | 控制器参数 | 绑定请求参数，可设置required |
@PathVariable | 控制器参数 | 绑定URL中的路径参数，如/room/{id} |
@RequestBody | 控制器参数 | 把JSON请求体反序列化为Java对象 |
这个项目里统一返回JSON，所以控制器全部用@RestController。实体类上的@JsonProperty偶尔也会用到，用来解决字段名映射问题。
3.3 统一返回格式与登录Token方案
小程序端请求接口时最怕什么？最怕后端返回的数据没有一个统一格式，每个接口都长不一样，前端写起来就是灾难。所以第一步先写一个Result类：
public class Result<T> { private Integer code; // 200成功，500失败，401未登录 private String message; private T data; public static <T> Result<T> success(T data) { Result<T> r = new Result<>(); r.code = 200; r.message = "操作成功"; r.data = data; return r; } public static <T> Result<T> error(String message) { Result<T> r = new Result<>(); r.code = 500; r.message = message; return r; } }登录方案上，一开始我习惯用Session，但小程序端没有Cookie机制，维护Session很不顺手。后来改成Token方案：用户登录成功后，服务端生成一个UUID作为Token，存到内存Map里，同时返回给前端。前端每次请求在Header里带token，后端通过一个SpringMVC拦截器统一校验。
当然这个方案只是朴素版的Token，不用引入JWT，毕设完全够用。答辨时如果老师追问安全性，你可以说"实际企业级项目中会用Redis存储并设置过期时间，本项目是简化方案"——既展示了知识面，又坦承了项目边界。
需要判断输入字符串是否只包含字母和数字这类简单的后端校验，可以用一个工具方法，项目里我当时写的是：
public static boolean isLetterOrDigit(String str) { return str != null && str.matches("[a-zA-Z0-9]+"); }4. 小程序端的页面实现：轮播图、列表加载、日历预约
4.1 首页轮播图与会议室列表
小程序首页的骨架其实很固定：顶部轮播图 + 下面的会议室列表。轮播图直接用官方swiper组件，不需要任何第三方库。关键代码大概长这样：
<swiper class="banner" autoplay interval="4000" circular indicator-dots> <swiper-item wx:for="{{banners}}" wx:key="id"> <image src="{{item.imageUrl}}" mode="aspectFill" bindtap="onBannerTap">const app = getApp(); Page({ data: { banners: [], rooms: [] }, onLoad() { this.loadBanners(); this.loadRooms(); }, loadBanners() { wx.request({ url: app.globalData.baseUrl + '/banner/list', success: (res) => { if (res.data.code === 200) { this.setData({ banners: res.data.data }); } } }); } });这里有一个我确确实实踩过并且很典型的坑：轮播图图片用的是后端存储的相对路径，比如/upload/banner1.jpg，在小程序里直接image组件是不认的，必须拼成完整的http://服务器IP:8080/upload/banner1.jpg。这个我在第5章的"轮播图显示不出来"会详细说。
4.2 列表加载更多的分页实现
会议室列表如果一次全查出来，图片一多页面就会卡。所以列表要分页加载，后端接口接收page和size参数：
@RestController @RequestMapping("/room") public class RoomController { @Autowired private RoomService roomService; @RequestMapping("/list") public Result<PageResult<Room>> list(@RequestParam(defaultValue = "1") int page, @RequestParam(defaultValue = "10") int size) { return Result.success(roomService.getRoomsByPage(page, size)); } }服务端返回的PageResult至少包含total, list, page, size四个字段，小程序端在页面滚动到底部时自动加载下一页：
// pages/index/index.js Page({ data: { rooms: [], page: 1, size: 10, hasMore: true, loading: false }, onReachBottom() { if (this.data.hasMore && !this.data.loading) { this.loadRooms(); } }, loadRooms() { this.setData({ loading: true }); wx.request({ url: app.globalData.baseUrl + '/room/list', data: { page: this.data.page, size: this.data.size }, success: (res) => { if (res.data.code === 200) { const list = res.data.data.list; this.setData({ rooms: this.data.rooms.concat(list), page: this.data.page + 1, hasMore: this.data.rooms.length + list.length < res.data.data.total }); } }, complete: () => this.setData({ loading: false }) }); } });loading这个锁变量很重要。没有它，滚动到底部时onReachBottom可能会连续触发两次，造成重复请求，数据重复追加。加了锁之后，第一次请求没返回前，第二次触发直接 return。页面顶部通常还有一个下拉刷新的操作，用enablePullDownRefresh配合onPullDownRefresh重置page = 1再重新加载即可。
分页时后端也别偷懒，排序最好按capacity DESC或者创建时间倒序，否则分页边界处数据容易出现视觉上的跳动。可以在PageResult里顺带把total返回，便于前端判断hasMore。
4.3 预约表单与时间选择
小程序端选会议室、选日期、选时间段的部分，看起来简单，交互细节其实不少。最佳组合是：
- 会议室单选，采用
radio-group或点击卡片选中，选中后卡片有一个高亮边框。热词里提到"微信小程序单选框"，源码里用的是<radio-group>包裹<radio>，value对应会议室ID。 - 日期用
picker mode="date"，用户直接弹起系统日期选择器。 - 开始时间和结束时间用两个
picker mode="time"，一个选开始，一个选结束。
<picker mode="date" value="{{date}}" bindchange="onDateChange"> <view class="picker-value">{{date || '请选择日期'}}</view> </picker> <picker mode="time" value="{{startTime}}" bindchange="onStartTimeChange"> <view class="picker-value">{{startTime || '开始时间'}}</view> </picker> <picker mode="time" value="{{endTime}}" bindchange="onEndTimeChange"> <view class="picker-value">{{endTime || '结束时间'}}</view> </picker>注意picker的value属性如果是空字符串，在iOS和Android上行为不一致。稳妥做法是给一个默认值，比如日期默认今天，开始时间默认"09:00"，结束时间默认"10:00"。提交时前端也要做一次校验，结束时间必须晚于开始时间，并且不能把开始时间填到晚上8点以后。这层校验在后端ReservationService里还要再写一遍，双重校验是一个好习惯。后端主要校验逻辑写在Service里而不是Controller里，这样复用性更强。
还有一个小细节：顶部导航栏的高度问题在热词里反复出现，实际原因是小程序页面的头部由"导航栏 + 胶囊按钮"组成。自定义导航栏时需要动态计算高度：
const menuButton = wx.getMenuButtonBoundingClientRect(); const navBarHeight = (menuButton.top + menuButton.height) * 2;这段代码放到app.js的globalData里，页面直接取用，就不用每个页面重复写了。
5. 联调阶段踩过的坑，按出现频率排序
5.1 请求地址在真机上全部失败
这是所有做小程序后端的同学都会撞上的一面墙：开发者工具里一切正常，一预览到真机，所有请求全部报request:fail。原因不用多想，你大概率在代码里写了http://localhost:8080。
真机上 localhost 指向的是手机自己，不是你的电脑IP。解决方法是把请求地址改成你电脑在局域网里的IP，比如http://192.168.1.101:8080。然后在微信开发者工具的"详情 - 本地设置"里勾选"不校验合法域名、web-view（业务域名）、TLS版本以及HTTPS证书"。注意这只是本地调试的开关，如果要上传体验版，就必须配一个备案过的HTTPS域名。所以如果你准备在答辩现场用真机演示，最好先确认现场WiFi下电脑和手机在同一个局域网。
排查这类问题有一个很好用的技巧：打开微信开发者工具的Network面板查看请求状态。如果请求都发不出去，先看URL是否可达；如果返回401，再检查token是否带上。用工具面板一步步确认，远比重启大法管用。
5.2 后端跨域与Session失效
小程序端本质上也是一个浏览器环境，发请求时存在跨域问题。如果后端不放开跨域限制，浏览器会直接拦截响应。SSM中加一个跨域配置类即可：
@Configuration public class CorsConfig implements WebMvcConfigurer { @Override public void addCorsMappings(CorsRegistry registry) { registry.addMapping("/**") .allowedOriginPatterns("*") .allowedMethods("GET", "POST", "PUT", "DELETE", "OPTIONS") .allowedHeaders("*") .allowCredentials(true); } }这里有一个关键点：如果你在后端设置了allowCredentials(true)，那么allowedOrigins不能写成*，需要用allowedOriginPatterns("*")才能配合credentials一起生效。这个坑花了我整整一个晚上才排查明白。
跨域配置好之后，接口能通但登录状态又出问题了。用Token方案就不会受Session的牵制，前端每次请求都要在header里带上Authorization: token值。所以写一个统一的request封装方法，每个接口都从wx.getStorageSync('token')拿token，几行代码就能杜绝忘带token的尴尬。
5.3 轮播图显示不出来的真实原因
不得不单独说说轮播图，因为这是热词里被反复搜的痛点。显示不出来通常有四种原因，按排查顺序排列：
- 图片URL是相对路径：数据库存了
/upload/banner1.jpg，小程序image组件直接当成相对路径解析，当然加载不出来。解决：前端拼接baseUrl + '/upload/banner1.jpg'。 - HTTP请求被拦：非HTTPS图片在部分真机环境可能被默认策略拦掉，开发者工具里无所谓，真机如果出现图片挂了，看控制台有没有
blocked关键字。 - 服务器防火墙没放行端口：8080端口只在本机开放，真机访问被拒。在服务器安全组里放行对应端口，这是部署云服务器时最常见的遗漏。
- 图片格式问题：后端上传的图片如果是BMP或者超大尺寸的PNG，
mode="aspectFill"有时候展示异常。统一转成JPG，压缩到500KB以内，轮播图和列表图都会流畅很多。
轮播图点击还要带上跳转逻辑，比如点击某一张图跳转到对应会议室详情页。这也是很自然的扩展点：后端banner表里加一个room_id字段，前端bindtap事件解析><configuration> <settings> <setting name="mapUnderscoreToCamelCase" value="true"/> </settings> </configuration>
否则start_time查出来就是start_time，Java 实体类的startTime字段里全是 null。这个问题很隐蔽，接口状态码是200，但数据全空，非常让人头疼。
5.5 日程提醒，监听用户离开小程序
小程序onHide和onShow这两个生命周期方法，在实际项目里很实用。比如用户正在填写预约表单，中途切到微信回了个消息再回来，表单内容还在但你希望页面能刷新一下时间；或者用户预约成功后，你希望在他下次进入小程序时提醒他"今天有一场会议"。做法是在onShow里检查本地存储的预约列表，判断有没有今天要开的会，有就弹一个模态框提示。
监听预约状态变化的时机通常是这几个：用户提交申请、管理员审批通过或驳回、用户取消。前端在onShow里重新拉取一次"我的预约"列表，状态自然就更新了。这就是热词里"微信小程序如何监听用户离开小程序"的最典型应用。
6. 源码目录、本地运行与把项目改造成你自己的毕设
6.1 拿到源码后怎么跑起来
一套完整的SSM + 小程序源码，拿到的第一件事不是看代码，而是理清结构。正常的项目包应该是两个工程：后端meeting-server（Java + Maven + SSM）和前端meeting-miniapp（微信小程序工程）。我按标准流程走一遍，你照着操作基本不会出问题：
- 本地装好 JDK 1.8、Maven 3.6、MySQL 5.7+、Tomcat 8.5。
- 用 Navicat 或命令行执行
sql/meeting.sql初始化数据库。 - 打开
src/main/resources/jdbc.properties，把数据库账号密码改成你自己的。 - 用 IDEA 导入后端 Maven 工程，等待依赖下载完成，配置好本地的 Tomcat。
- 启动 Tomcat，浏览器访问
http://localhost:8080/api/room/list，能返回JSON就说明后端通了。 - 微信开发者工具导入
miniapp目录，AppID 可以选择测试号。 - 在
miniapp/app.js里把baseUrl改成http://localhost:8080，注意开发者工具里勾选"不校验合法域名"。 - 编译运行小程序，完成登录后就能看到首页轮播图和会议室列表。
如果Java工程启动时报数据源错误，八成是数据库没初始化或者jdbc.properties配置不对。如果页面请求404，先看URL路径和Controller里的@RequestMapping是否匹配。
6.2 如何避免答辩时"一看就是抄的"
每年毕设答辩最尴尬的场景，就是老师打开你的项目，发现数据库表名、包名、甚至页面标题都和隔壁同学一模一样。拿到源码之后，至少要完成下面四件事，才能把"别人写的项目"变成"你的项目"：
- 全局替换包名和工程名：
com.example.meeting改成你学号相关的或者自己的域名倒写。IDEA里右键 - Refactor - Rename可以一键改，别手动一个个文件改。 - 改数据库表前缀和字段补充：比如所有表加一个
create_time、update_time字段，或者给用户表加上department部门字段，这样数据库设计部分你能多讲出一个"部门维度"的统计功能。 - 增加一个自己真正理解的功能：比如"我的会议日程"页，把当前用户本周所有已通过的预约按时间轴排布。需要两张表的联查，还要处理排序，工作量不大但答辨时你能讲出设计意图。
- 准备一份口述文档：把"项目背景、技术选型、数据库设计、核心逻辑、演示路径、改进方向"六大块写满两页A4纸，对着镜子讲三遍。技术可以简单，但表达一定要熟练。
6.3 后续扩展方向，从毕设到项目经验
做完核心功能之后，如果你还想在这个项目上加一点亮点，下面这几个方向是我实测成本低、收益高的：
- 会议室设备预约联动：在会议室预约的同时勾选需要的设备，后端单独建一张
room_equipment关联表。优点是能讲出"多对多关系"的数据建模能力。 - Redis缓存热点会议室：如果某个会议室特别抢手，可以用 Redis 对它的空闲时间段做缓存。不过SSM项目里引Redis需要额外配置，看你自己时间是否充裕。
- 采用定时任务关闭过期预约：用Spring的
@Scheduled注解，每小时把结束时间小于当前时间的APPROVED状态改成FINISHED。这个亮点不大但很实用。 - 转发分享会议室：会议室详情页加一个分享按钮，借助小程序的
onShareAppMessage，整个过程几分钟就能搞定。
这些扩展方向不用一次性全做，挑一个你最感兴趣的，做到能讲明白的程度就足够了。答辨老师问"项目有什么改进空间"时，你可以从容地列举出两三个方向——这比项目本身多两个功能还加分。
最后说一点个人体会：做完这个SSM会议室预约小程序之后，我最明显的感觉是，SSM项目的时间黑洞永远在配置文件和联调阶段，业务代码其实写起来非常快。如果你卡在一个奇怪的报错上超过两个小时，不要硬刚，先打开开发者工具的Network面板看看请求状态，再看后端日志的堆栈信息，绝大部分问题都能定位出来。这套"先看请求、再看日志"的排查习惯，比任何框架知识都值钱。希望这篇记录能帮你把项目跑通，也祝你答辩顺利。
